Ошибки в смарт контрактах
Я все еще нахожусь в дороге и надеюсь на следующей неделе уже вернуться к регулярному ведению канала. А пока что, я читаю много аудиторских отчетов и примеров взломов. Для себя выделил несколько типов ошибок, которые присутствуют в контрактах.
1. Типичные low/gas ошибки
Такие баги находятся проще всего, даже при беглом изучении кода. Примером может случить простая потеря indexed в событиях, не нужные чтения переменных из памяти или использование calldata вместо memory.
2. Ошибки при делении
Одни из самых популярных ошибок в смарт контрактах. Начисление бонусных токенов, расчет долей, свапы - везде может быть проблема с округлением, decimals или логическими расчетами.
3. Ошибки "на внимательность"
Такие ошибки часто попадаются в раздел Med Risk issues в отчетах. Тут уже не получится бегло просмотреть код и потребуется время на его изучение, чтобы понять действия, которые в нем совершаются.
4. Ошибки непредвиденных действий
Самые сложные для нахождения баги, так как чаще всего с кодом все в порядке: т.е. он написан правильно и с необходимыми проверками. Однако, чтобы выявить этот баг аудитору нужно иметь хороший опыт и воображение. Привести пример тут достаточно сложно, так как для каждого проекта они будут индивидуальными.
На что нужно обращать внимание при аудите?
1. Проверки if, require и модификаторы
Иногда такие проверки оказываются недостаточными, что позволяет обходить их с определенными условиями. Обращайте на них внимание с позиции "а как их можно обойти?";
2. Память и ее обновления
Также в некоторых отчетах я встречал баги, которые основывались на недостаточном / некорректном / избыточном обновлении в памяти контракта. Тут могут быть и ошибки с маппингами, и memory-storage, да и обычные обновления переменных. Для меня в этом случае бывает полезным контроль слотов и понимание логики функции.
3. Действующие лица
Редко встречается этот пункт в каких-либо статьях или постах в Твиттере. Аудитору нужно понимать, что в смарт контрактах не два уникальных действующих лица: разработчик и пользователь. Их может быть много, в зависимости от направления проекта, как например: разработчик, администратор, модератор, заемщик средств, заниматель средств, инвестор в пул, продавец токена, покупатель токена, мошенник и т.д. При хорошем аудите нужно рассматривать код на предмет взлома от каждого из действующих лиц.
4. Возможные атаки
Составляйте свой список атак в начале аудита после прочтения документации. Постарайтесь вспомнить все атаки, которые вы встречали в подобных проектах. Это помогает увидеть более развернутую картину потенциальных атак и позже прицельно смотреть в контракт, который аудируете.
Вот такой длиннопост получился по итогам моего чтения отчетов. Надеюсь и вам поможет взглянуть на этот процесс аудита с новой стороны.
Приятного обучения и практики!
#audit
Я все еще нахожусь в дороге и надеюсь на следующей неделе уже вернуться к регулярному ведению канала. А пока что, я читаю много аудиторских отчетов и примеров взломов. Для себя выделил несколько типов ошибок, которые присутствуют в контрактах.
1. Типичные low/gas ошибки
Такие баги находятся проще всего, даже при беглом изучении кода. Примером может случить простая потеря indexed в событиях, не нужные чтения переменных из памяти или использование calldata вместо memory.
2. Ошибки при делении
Одни из самых популярных ошибок в смарт контрактах. Начисление бонусных токенов, расчет долей, свапы - везде может быть проблема с округлением, decimals или логическими расчетами.
3. Ошибки "на внимательность"
Такие ошибки часто попадаются в раздел Med Risk issues в отчетах. Тут уже не получится бегло просмотреть код и потребуется время на его изучение, чтобы понять действия, которые в нем совершаются.
4. Ошибки непредвиденных действий
Самые сложные для нахождения баги, так как чаще всего с кодом все в порядке: т.е. он написан правильно и с необходимыми проверками. Однако, чтобы выявить этот баг аудитору нужно иметь хороший опыт и воображение. Привести пример тут достаточно сложно, так как для каждого проекта они будут индивидуальными.
На что нужно обращать внимание при аудите?
1. Проверки if, require и модификаторы
Иногда такие проверки оказываются недостаточными, что позволяет обходить их с определенными условиями. Обращайте на них внимание с позиции "а как их можно обойти?";
2. Память и ее обновления
Также в некоторых отчетах я встречал баги, которые основывались на недостаточном / некорректном / избыточном обновлении в памяти контракта. Тут могут быть и ошибки с маппингами, и memory-storage, да и обычные обновления переменных. Для меня в этом случае бывает полезным контроль слотов и понимание логики функции.
3. Действующие лица
Редко встречается этот пункт в каких-либо статьях или постах в Твиттере. Аудитору нужно понимать, что в смарт контрактах не два уникальных действующих лица: разработчик и пользователь. Их может быть много, в зависимости от направления проекта, как например: разработчик, администратор, модератор, заемщик средств, заниматель средств, инвестор в пул, продавец токена, покупатель токена, мошенник и т.д. При хорошем аудите нужно рассматривать код на предмет взлома от каждого из действующих лиц.
4. Возможные атаки
Составляйте свой список атак в начале аудита после прочтения документации. Постарайтесь вспомнить все атаки, которые вы встречали в подобных проектах. Это помогает увидеть более развернутую картину потенциальных атак и позже прицельно смотреть в контракт, который аудируете.
Вот такой длиннопост получился по итогам моего чтения отчетов. Надеюсь и вам поможет взглянуть на этот процесс аудита с новой стороны.
Приятного обучения и практики!
#audit