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

Итак, мы получили задачу или контракт, с чего же начать поиск багов? Опишу, как я это делаю и куда смотрю.

1) Pragma. Как не удивительно, но версия прагмы тоже играет роль. Пару раз я попадался, потому что думал, к примеру, что во всех контрактах последняя его версия и многих багов ранних версий уже нет. Напомню, что до 0.8 в расчетах возможен overflow / underflow.

Смотрим на прагму, в голове держим версию и баги, которые в ней возможны.

2) Импорты. В любом случае идем и проверяем контракты, которые подключаются. Если они от openzeppelin (или другой достойной компании, типа chainlink), то просматривает код, чтобы вспомнить его детали (например, когда и где даются апрувы и т.д.). Если "левые контракты", то в начале изучаем подробно их и ищем баги там. Очень важно разобраться в коде и понимать его "потоки".

3. Интерфейсы. Это простое описание кода, которое подключается в контракт, и в некоторых задачах исполнение его функций можно было подменить в хакерском контракте. Т.е. вы пишите свой контракте с таким же именем и функциями, подключаете его в контракт жертвы и ломаете его. В общем, вы смотрите можно ли в проверяемом контракте сделать подмену.

4. Библиотеки. Пару раз видел самописную библиотеку safeMath, которая по названию очень похожа на openzeppelin. Кажется, что все ок, но там измененные расчеты.

Мы сделали небольшую подготовку и далее начинаем изучать сам контракт.    

#security #audit