Почему безопасность контрактов критична: модель угроз

Кто атакует ваш контракт, зачем и через какие двери он входит.

Модель угроз — систематическое описание того, кто может навредить системе, какие у него мотивы, какими возможностями он обладает и через какие точки входа действует.

Чем смарт-контракт отличается от обычного кода

Обычное приложение можно пропатчить: нашли баг — выкатили фикс, откатили транзакции в БД, заблокировали злоумышленника. Смарт-контракт иной по трём причинам:

• Код неизменяем после деплоя. По умолчанию исправить байт-код на этом адресе нельзя; «горячий патч» невозможен без заранее заложенной апгрейдабельности (которая сама — источник риска).
• Деньги напрямую. Контракт не «представляет» счёт — он и есть хранилище средств. Уязвимость = немедленный доступ к деньгам.
• Нет отката. Украденное ушло необратимо; нет банка, который отменит перевод.

Поэтому в DeFi счёт идёт на миллиарды украденных долларов: цена ошибки максимальна, а исправить её постфактум почти нельзя.

Кто атакует и зачем

Поверхность атаки

«Поверхность атаки» — это все точки, через которые внешний мир взаимодействует с контрактом:

• Публичные и внешние функции (любой может их вызвать с любыми аргументами).
• Внешние вызовы из контракта (call, delegatecall) — они возвращают управление чужому коду.
• Источники данных (оракулы): неверные данные = неверные решения.
• Параметры порядка транзакций (мемпул публичен — об этом раздел про MEV).
• Механизм апгрейда и управления (кто и как меняет правила).

Как работает под капотом: мышление атакующего

Безопасный разработчик мыслит как атакующий, но с защитной целью: «Что будет, если эту функцию вызвать в неожиданном порядке? С нулём? С контрактом вместо пользователя? Дважды в одной транзакции? При экстремальной цене?» Каждое такое «что если» — это потенциальный инвариант, который нужно явно защитить в коде.

Defense-in-depth (эшелонированная защита):
  1) проверки на входе (require)
  2) корректный порядок: checks -> effects -> interactions
  3) ограничение прав (модификаторы доступа)
  4) проверенные библиотеки (OpenZeppelin)
  5) тесты инвариантов + аудит
  6) аварийные механизмы (пауза, лимиты)

Частые ошибки

• «У нас приватный контракт». В блокчейне нет «приватного»: байт-код и состояние видны всем, а любую функцию можно вызвать напрямую.
• «Никто не догадается так сделать». Безопасность через неясность не работает; код открыт.

Итоги

• Неизменяемость, прямой доступ к деньгам и отсутствие отката делают цену ошибки максимальной.
• Атакуют ради денег, MEV или контроля; защищают white-hat-исследователи.
• Поверхность атаки — все внешние функции, внешние вызовы, оракулы, апгрейд.
• Защита эшелонированная; мыслить как атакующий, действовать как защитник.