Аудиты, тесты и больше практики

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

В обучении и практике нет "серединки".

Чаще всего, задачи и тестовые проекты ограничиваются парой небольших контрактов, а задачи и того меньше - парой функций.

А тесты? Все обучающие видео и статьи строятся вокруг "Как начать делать тесты"? Попробуйте найти хоть одно видео, где приводится тестирование мостов или крупных проектов.

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

10+ перекликающихся контрактов, 5000 строк кода, туча импортов и непонятных настроек. И это хорошо, если разработчики постарались и написали комментарии с подробным описанием функций, идеи проекта и natspec. А если нет?..

К чему я это все веду.

После того как изучили базис и написали свои первые контракты, идите на популярные площадки, типа code4rena, скачивайте конкурсные проекты и старайтесь разобраться в них: написать свои тесты, оптимизировать функции и т.д.

Чем раньше вы погрузитесь в "боевой" режим разработчика, тем быстрее будете набираться опыта.

А я пошел дальше разбираться с foundry.

#практика

В дополнение к предыдущему посту

Сейчас проводится конкурс на аудит контрактов Astaria.

Почему я предлагаю этот проект?

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

Что можно сделать для своей практики?

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

Прежде всего постарайтесь ответить себе на следующие вопросы:

1) Понимаю ли я основную идею проекта?
2) Понимаю ли я, за что отвечает каждый контракт?
3) Понимаю ли я их взаимосвязь?
4) Понимаю ли я исходную точку для пользователя?
5) Понимаю ли я весь набор файлов в проекте?
6) Понимаю ли я подключенные библиотеки?

Этого будет вполне достаточно для работы дальше. Не волнуйтесь, если это займет у вас несколько дней.

Далее попробуйте написать свои тесты для него:

1) Создать Сейф от имени пользователя;
2) Сделать перевод;
3) Добавить пользователей и от их имени проведите транзакции;
4) Отдайте NFT в займ;
5) Прочитайте переменные памяти контракта;

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

Просто возьмите за правило раз-два в месяц брать конкурсные проекты и разбираться в них. Это станет наикрутейшей практикой. И никакое платное обучение не сможет это превзойти.

Дерзайте!

#практика

Задачка на день

Ну, и небольшая задачка на день. Сможете найти, в чем тут проблема?

Решение

В аудитах следует всегда обращать внимание на модификаторы функций, какие условия они нам ставят.

В текущем же примере, он просто сверяет msg.sender с другим параметров, а значит, что функция _safeMint() не защищена от reentrancy атак.

#security #task

День задач на канале

Сегодня я подготавливаю отчет для своего конкурсного аудита, поэтому на канале объявляется день задач.

Итак, первая: была помечена как High Risk на code4rena. Сможете понять в чем тут дело?

Решение

В этой задаче стоит обратить внимание не только на саму подпись (мы же помним, что с ними существует достаточное количество проблем?), но и на nonce.

Вроде бы, все правильно написано в коде. Но нет одной единственной проверки. Уже догадались?

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

Вот описание с code4rena.

#task #nonce

Более сложная задача от Immunefi

При аудите всегда следует обращать внимание на переменные и "откуда растут ноги" у токена. Получилось решить?

Решение

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

#task #token

Еще одна с code4rena

Данный баг был обозначен как Medium risk. Поняли в чем дело?

Решение

Функция lendToProject может стать не доступной, если количество задач (tasks) будет слишком большим, что приведет к стопорению проекта.

Это происходит из-за того, что цикл расходует весь газ из функции. Такая вот DoS атака.

#task

Простая, но серьезная

Данная задача одна из самых легких среди тех, что я видел. Тем не менее, она была помечена как High Risk. Решили?

Решение

Функция заканчивает свое действие на return и не доходит до проверки require. К чему это может привести, вы и сами знаете.

#task

Задача на знание нюансов

Задача была помечена как Medium Risk. Ошибка не столько в самом коде, сколько в логике и знании, как работает язык. Поняли, о чем идет речь?

Решение

Проблема все в том же extcodesize. Нельзя полагаться на него при проверке "Контракт ли это?". В первом случае, хакер может все сделать через конструктор контакта, а в более сложном - поиграться с create2 и selfdestruct(). Т.е. проверку довольно просто обойти.

#task

И последняя на сегодня

Последняя задача была помечена как Critical. Достаточно серьезная проблема многих контактов, которые используют переводы.

Решение

Заметили маппинги в начале? Как вы думаете, зачем они были указаны?

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

#task

Нет, не задача

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

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

ERC4626, объясняю своими словами, используется тогда, когда вам нужно выдать пользователям вашего проекта некоторое количество shares взамен их токенов, которые они внесли. Он используется и в играх, и в Dao, и на биржах. При аудитах он встречается довольно часто. 

В контрактах, которые используют данный стандарт, нужно обращать внимание на формулу расчета количество shares.

Чаще всего разработчики упускают из вида проблему минта shares для первого пользователя, а он может оказаться хакером.

Хоть я сам и понял суть бага, но объяснить его немного затрудняюсь, поэтому предлагаю вам посмотреть часть видео, где он хорошо разбирается.

Видео разбор.

#erc4626

Хэширование в EIP712

Все чаще встречаюсь с этим стандартом на просторах аудиторских отчетов, и стараюсь осмысливать его шаг за шагом.

Вообще EIP712 был создан для того, чтобы можно было подписывать сообщения, которые состоят не только из строк, но и более сложных параметров: например, struct.

И сегодня разберем, как шифруются структуры. Возьмем такой код:

struct Parent {
    uint s;
    Child[] children;
}

Child {
   uint a;
   uint b;
}

Сначала будет хешироваться каждый пункт в Child по отдельности, затем они соединяются (конкатенация) и еще раз хешируются. Из этого получается хеш структуры.

В самом конце, берется S и хеш структуры и высчитывается уже конечный хеш Parent.

#erc712 #struct

Читаем отчеты вместе. 1

Я тут подумал, а давайте читать аудиторские отчеты вместе всем каналом? За месяц у нас получится около 25 прочитанных отчетов (не считая выходные дни), что точно повысит наши знания.

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

Для сегодняшнего вечера я выбрал отчет от Sherlock.

Кто что думает?

#report #audit

Новый скам в NFT

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

В общем, пользователи Open Sea, да и других бирж, стали замечать, что либо с их аккаунта, либо на их аккаунт идет перевод NFT. Порой даже предлагается подписать транзакцию в кошельке. Делать этого, конечно не стоит.

Дело в том, что практически все переводы NFT порождают событие transfer, которое и отлавливается биржами и другими сервисами. Однако, в случае скама, никакой транзакции не происходит. Злоумышленник просто в своем контракте override функцию transferFrom / safeTransferFrom, оставляя только emit event.

Для того чтобы не попасть в такую ловушку, нужно просмотреть транзакции (а был ли перевод вообще!), а также заглянуть в контракт, который и порождает это уведомление.

Будьте аккуратны, и не подписывайте подозрительные сообщения в кошельках.

#nft #scam

Внимание на decimals в аудитах

Короткий пост для привлечения внимания разработчиков и аудиторов к проблеме decimals в Solidity и расчетах.

Очень и очень часто встречаются ошибки, в которых разработчики учитывали только 18 (WETH) или 6 (USDT) decimals в токенах. При этом их количество в разных токенах варьируется от 1 до 20 (максимальный, который я встречал), но, вполне вероятно, что может быть и больше.

Поэтому, если вы не ограничиваете работу своего смарт контракта whitelist токенами с конкретным значением decimals, то следует учитывать и другие варианты.

Вот один из примеров такого бага в контракте.

#decimals #audit

Прочитать mapping в Foundry

Просто оставлю тут небольшую заметку про работу с памятью.

Я еще только учусь вместе с вами, и сегодня столкнулся с проблемой прочтения значений из памяти контракта.

Допустим есть такой маппинг:

mapping (uint256 => structInt) internal BlaBlaSt;

Я перерыл весь foundry и гугл, но так и не понял есть ли какие-нибудь команды, чтобы прочитать значения по нужному id.

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

Получили значения из функции => сохранили в переменные => вывели в консоль.

Мне сегодня это стоило пары часов.

Если знаете более простой способ или команду, буду рад, если поделитесь в комментариях.

#foundry #mapping

Читаем отчеты вместе. 2

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

Вообще, тесты, которые учат писать в роликах на Ютуб, и тесты, которые требуются проводить аудитору - два абсолютно разных по сложности принципа. Завтра сделаю отдельный пост про это.

А пока, вечерний отчет для чтения вместе!

#report #audit

Тесты в обучении и аудите. Часть 1

Сегодня хочу поднять тему проведения тестов. В частности на Foundry, но подойдет и для HardHat.

В сети можно встретить достаточно большое количество уроков по темам проведения тестов. Даже ролики на Ютуб на русском языке есть, и по ним действительно можно научиться основам. Точнее установке пакетов, созданию файла и написанию простых тестов.

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

Что можно найти в серьезных проектах?

Во-первых, в папке с тестами чаще всего лежит не один файл, а несколько.

Во-вторых, там же еще присутствуют и другие папки.

В-третьих, появляются некие контракты хелперы.

И вот после простеньких тестов, с которыми мы игрались на своем проекте, в первый раз такое собрание файлов вызывает некоторую панику.

#tests

Тесты в обучении и аудите. Часть 2

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

Итак, для каждого контракта в проекте чаще всего создается свой файл теста. Нельзя нагружать все в одно место, так будет проблематичнее потом.

Если есть какие либо библиотеки или сторонние файлы, которые требуют тестов, то также создаем отдельную папку для них (например, utils) и проверяем.

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

При встрече с ними, крайне рекомендую начинать изучение именно с них.

Сложнее всего иногда бывает определить контракт входа, т.е. с какого контракта начинается взаимодействие с остальными. И от какого лица. Ведь некоторые контракты могут разворачивать только другие контракты (фабрики), или частные лица, или только Сейф и т.д.

При написание своих тестов, мы определяем изначальные условия: контракт входа, его настройки (нужно ли сминтить токены и забросить туда), его пользователей и т.д. В этом очень сильно помогают как раз те хелперы.

И только потом начинаем писать свои тесты.

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

Очень жаль, что нет полноценного курса по проведению тестов.

#tests