DApps - Децентралізовані додатки

Reading time: 4 minutes

{{#include ../../banners/hacktricks-training.md}}

Що таке DApp?

DApp - це децентралізований додаток, який працює в мережі рівноправних учасників, а не розміщується на централізованому сервері. DApps зазвичай створюються на блокчейн-технології, що має забезпечити прозорість, безпеку та незмінність даних.

Архітектура Web3 DApp

Згідно з цією статтею, існує 3 різні типи архітектури Web3 DApps:

DApps без API

Ці DApps створюються на основі блокчейну і не покладаються на жодні централізовані API або бекенди. Ви можете вважати, що блокчейн є фактичним бекендом додатку. Вони повністю децентралізовані і можуть бути доступні безпосередньо через блокчейн.

Щоб взаємодіяти з блокчейном, клієнт зазвичай використовує гаманець. Гаманець підписує транзакції та надсилає їх до блокчейну. Клієнт також може використовувати вузол для читання даних з блокчейну.

DApps з API

Ці DApps створюються на основі блокчейну, але також покладаються на централізовані API, зазвичай для збору інформації. Вони в основному децентралізовані, оскільки, навіть якщо вони покладаються на централізований API, основна функціональність DApp все ще знаходиться на блокчейні. Зв'язок клієнта з блокчейном зазвичай здійснюється через гаманець.

Добрим прикладом цього типу DApp є додаток для карбування NFT. Сервер дозволяє завантажувати зображення, але карбування виконується клієнтом через гаманець.

DApps повного масштабу

Ці DApps створюються на основі блокчейну, але також покладаються на централізовані API та бекенд-сервери. Вони можуть бути частково децентралізованими, оскільки клієнт може виконувати операції на блокчейні, використовуючи гаманець. Однак зазвичай бекенд також може виконувати операції на блокчейні.

Добрим прикладом цього типу DApp є кросчейн-міст, де потрібен офчейн-компонент для взаємодії з обома смарт-контрактами в різних блокчейнах для виконання передачі активів.

Вразливості Web2

Вразливості Web2 все ще впливають на ці види додатків, хоча їхній вплив може варіюватися:

• Вразливості на стороні клієнта мають підвищений вплив, оскільки в Web3 DApps клієнт зазвичай є тим, хто виконує операції на блокчейні через гаманець. Це означає, що атаки, такі як XSS, які здатні виконувати JS-код на стороні клієнта або які змінюють вміст сторінки, можуть мати більший вплив, оскільки вони можуть взаємодіяти з гаманцем і переконати користувача виконати небажані операції на блокчейні.
• Зверніть увагу, що зазвичай навіть у цих видах додатків клієнт все ще може переглядати операції перед їх підписанням за допомогою гаманця. Однак, якщо зловмисник здатний змінити вміст сторінки, він може переконати користувача підписати транзакцію, яка виконає небажану операцію на блокчейні.
• Вразливості на стороні сервера все ще присутні в DApps, які покладаються на бекенд-сервер. Вплив цих вразливостей залежатиме від архітектури DApp. Однак вони все ще можуть бути дуже проблематичними, оскільки зловмисник може знайти в бекенді ключі компанії для доступу до фондів смарт-контрактів або може виконати захоплення облікового запису, що може дозволити їм вкрасти кошти або NFT у користувачів.

Звичайно, якщо DApp не використовує бекенд або бекенд, що використовується, пропонує лише дані публічної мережі або статичні сторінки, поверхня атаки DApp зменшується.

Поверхня атаки Web3

Навіть якщо загалом DApp має зменшену поверхню атаки, оскільки на блокчейні завжди виконуються кілька перевірок безпеки, все ще існують деякі вектори атаки, які можуть бути використані зловмисником.

Можливо, вразливості web3 DApps можна згрупувати в такі категорії:

• Неправильне оброблення транзакцій в ланцюзі: неправильно відформатовані або необмежені API транзакцій, відсутність логіки очікування відповіді та підтвердження блоку, витік чутливих даних та неналежне оброблення невдалих, скасованих або внутрішньо типізованих транзакцій, що дозволяє ін'єкції шкідливих даних.

• Атаки на бекенд, що керуються смарт-контрактами: зберігання або синхронізація чутливих даних між контрактами та базами даних без валідації, неперевірені події або адреси контрактів, а також вразливості контрактів, які можуть отруїти логіку бекенду.

• Помилкові операції з криптоактивами: неправильна обробка різних типів токенів (рідний vs. ERC-20), ігнорування десяткової точності, невдалі перекази або внутрішні транзакції, а також прийом фальшивих, дефляційних, ребейз або токенів, схильних до слипових, без валідації, що дозволяє ін'єкції корисного навантаження через метадані токенів.

Деякі приклади з цієї статті:

Витрачання коштів: Примушення бекенду виконувати транзакції

У сценарії Витрачені криптовалюти на газ через необмежений API зловмисник може примусити бекенд викликати функції смарт-контракту, які споживатимуть газ. Зловмисник, просто надіславши номер рахунку ETH і без обмежень, примусить бекенд викликати смарт-контракт для його реєстрації, що споживатиме газ.

DoS: Поганий час обробки транзакцій

У сценарії Поганий час обробки транзакцій призводить до DoS пояснюється, що оскільки бекенд залишає HTTP-запит відкритим, поки транзакція не буде виконана, користувач може легко надіслати кілька HTTP-запитів до бекенду, що споживатиме всі ресурси бекенду і призведе до DoS.

Десинхронізація Бекенд<-->Блокчейн - Умова гонки

У сценарії Поганий час обробки транзакцій призводить до умови гонки пояснюється, що в грі користувач міг надіслати запит на виведення до бекенду, який надішле користувачу його монети, але поки транзакція все ще оброблялася, користувач зміг використати ці монети для покупки предметів у грі, отримуючи їх безкоштовно.

Іншим прикладом може бути можливість використати ті ж монети для покупки різних предметів, оскільки бекенд негайно надає предмет користувачу, не чекаючи підтвердження транзакції, а отже, не чекаючи, поки баланс користувача в блокчейні зменшиться.

Валідація адреси смарт-контракту

У сценарії Бекенд моста не має валідації адреси смарт-контракту пояснюється, як бекенд перевіряв адресу смарт-контракту, тому зловмисник міг розгорнути фальшивий смарт-контракт, покласти на нього кошти, надіслати транзакцію до бекенду, і бекенд подумає, що користувач надіслав кошти до реального смарт-контракту і надасть користувачу токени.

Неправильне оброблення класів активів

У сценарії Неправильне оброблення класів активів пояснюється, що бекенд переплутав шахрайський NFT за адресою з 1 MATIC, що дозволило зловмиснику надіслати сотні шахрайських NFT на адресу і отримати 1 MATIC від платформи за кожен з них.

Посилання

• https://www.certik.com/resources/blog/web2-meets-web3-hacking-decentralized-applications

{{#include ../../banners/hacktricks-training.md}}