Поиск уязвимостей. Обучение. Первые итоги. Часть 4

Далее поговорим о функциях и их аудите. Напомню, что, возможно, для топового уровня аудита потребуются дополнительные нюансы, на которые следуют обращать внимание. А эти подойдут для начального и среднего уровня.

После следующей части обучения, скорее всего этот список будет расширен.

P.S. Я предполагаю, что перед прочтением последующих пунктов, вы уже будете знать о наиболее популярных атаках, типа reentrancy или dos.

9. Области видимости функций: public, external или internal. Если область не указана, то по умолчанию это public. Уже были много задач, да и взломов, когда в важной функции забывали указывать видимость, и она могла быть вызвана любым пользователем.

10. Модификаторы. Обращаем внимание: подключаются ли они из внешних контрактов (типа ownable от openzeppelin) или из данного контракта. Смотрим его условия и возможность обхода.

11. Доступы. Да, чаще всего доступы к исполнению функции прописываются в модификаторах, но иногда и в самой функции. Нужно проверить, кто из пользователей может ее вызывать: только админ, только модераторы, только владельцы токена, только другие функции по условиям (типа ДАО) или вообще все пользователи.

12. Require. Внутренние проверки функции. Можно или как-то обойти их?

13. Расчеты. Больная тема всех контрактов. Чаще всего уязвимость скрывается в неправильном определении долей / бонусов / наград, особенно, когда в них используются несколько контрактов.

14. Переводы. Обращаем внимание на функции типа transfer(), send() и другие, которые переводят токены или эфир. Есть ли проверка успешности выполнения? Возможен ли reentrancy? Когда обновляются маппинги и массивы?

15. Низкоуровневые вызовы. Call, delegatecall, callcode - особенно пристально смотрим на эти вызовы: есть ли проверка успешности вызова, куда идет ответ, что передается?

16. Аргументы функции. Я хотел поставить этот пункт вначале списка, но решил, что будет логичнее сделать его после low-level calls, и вот почему. Иногда в аргументы функции передают тип данных bytes. В байтах иногда шифруются функции и условия для низкоуровневых вызовов. И если такое есть в функции, то есть вероятность использовать байты для взлома.

17. Изменения переменных памяти. Проверяем, какие действия изменяют основные переменные, ведь это могут быть и права доступа владельца!

18. Валидация аргументов, адресов и токенов. Есть ли достаточная проверка всех данных, которые передает пользователь? Предусмотрены ли все случаи, когда пользователь может ввести нарочно некорректные данные.

Далее пара слов о defi.   

#security #audit