Ошибки в смарт контрактах

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

1. Типичные low/gas ошибки

Такие баги находятся проще всего, даже при беглом изучении кода. Примером может случить простая потеря indexed в событиях, не нужные чтения переменных из памяти или использование calldata вместо memory.

2. Ошибки при делении

Одни из самых популярных ошибок в смарт контрактах. Начисление бонусных токенов, расчет долей, свапы - везде может быть проблема с округлением, decimals или логическими расчетами.

3. Ошибки "на внимательность"

Такие ошибки часто попадаются в раздел Med Risk issues в отчетах. Тут уже не получится бегло просмотреть код и потребуется время на его изучение, чтобы понять действия, которые в нем совершаются.

4. Ошибки непредвиденных действий

Самые сложные для нахождения баги, так как чаще всего с кодом все в порядке: т.е. он написан правильно и с необходимыми проверками. Однако, чтобы выявить этот баг аудитору нужно иметь хороший опыт и воображение. Привести пример тут достаточно сложно, так как для каждого проекта они будут индивидуальными.

На что нужно обращать внимание при аудите?

1. Проверки if, require и модификаторы

Иногда такие проверки оказываются недостаточными, что позволяет обходить их с определенными условиями. Обращайте на них внимание с позиции "а как их можно обойти?";

2. Память и ее обновления

Также в некоторых отчетах я встречал баги, которые основывались на недостаточном / некорректном / избыточном обновлении в памяти контракта. Тут могут быть и ошибки с маппингами, и memory-storage, да и обычные обновления переменных. Для меня в этом случае бывает полезным контроль слотов и понимание логики функции.

3. Действующие лица

Редко встречается этот пункт в каких-либо статьях или постах в Твиттере. Аудитору нужно понимать, что в смарт контрактах не два уникальных действующих лица: разработчик и пользователь. Их может быть много, в зависимости от направления проекта, как например: разработчик, администратор, модератор, заемщик средств, заниматель средств, инвестор в пул, продавец токена, покупатель токена, мошенник и т.д. При хорошем аудите нужно рассматривать код на предмет взлома от каждого из действующих лиц.

4. Возможные атаки

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

Вот такой длиннопост получился по итогам моего чтения отчетов. Надеюсь и вам поможет взглянуть на этот процесс аудита с новой стороны.

Приятного обучения и практики!

#audit