смартконтракти中的 атака на відмову в обслуговуванні

атака на відмову в обслуговуванні(DoS)може призвести до того, що смартконтракти не зможуть нормально працювати протягом певного часу або навіть назавжди. Основні причини включають:

1. Логіка контракту має недоліки. Наприклад, деякі реалізації public функцій не враховують обчислювальну складність, що може перевищити обмеження Gas, що призводить до невдачі транзакції.

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

3. Людські фактори, такі як втрата приватного ключа власником контракту, призводять до неможливості оновлення критичного стану системи.

Нижче наведено аналіз вразливостей атаки на відмову в обслуговуванні на конкретних прикладах.

1. Циклічний перебір великої структури даних, яку можна змінювати зовні

Ось простий контракт для "розподілу дивідендів" зареєстрованим користувачам:

Статус контракту містить список зареєстрованих користувачів та відображення балансу рахунків. Користувачі можуть зареєструватися та ініціалізувати через register_account().

Менеджер через distribute_token() розподіляє дивіденди користувачам, перебираючи масив registered та переказуючи кожному користувачу вказану кількість токенів.

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

Рекомендоване рішення:

• обмежити розмір структури даних, щоб забезпечити, що навіть при досягненні максимального значення не перевищено обмеження Gas
• Використання режиму виведення коштів, спочатку облік, користувач самостійно повертає винагороду через withdraw

!

2. Залежність стану між смартконтрактами призводить до блокування

Розглянемо сцену "аукціонного" контракту:

• Фіксувати поточного найбільшого учасника торгів та суму
• Користувачі можуть зареєструвати обліковий запис для участі в аукціоні
• Коли ставка перевищує поточну найвищу ціну, повертається попередня найвища ціна, оновлюється стан

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

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

!

3. Втрата приватного ключа адміністратора

Частина ключових функцій (, таких як призупинення/перезапуск торгівлі ), можуть викликати лише адміністратори. Втрата приватного ключа адміністратора призведе до того, що ці функції не зможуть бути використані, і контракт може тривалий час не працювати належним чином.

Рішення: Використання механізму мультипідпису замість єдиного адміністратора, реалізація децентралізованого управління, уникнення єдиної точки відмови.