DRAFT — Черновик (Статья находится в процессе доработки, может содержать неточности и непроверенный код)

Часто смарт-контракты работают с большими деньгами. А значит требования к безопасности в этой области высокие.
Поэтому неотъемлемой частью разработки смарт-контракта является тестирование. В этой статье мы узнаем основные термины, которые потребуются в дальнейшем. А также познакомимся с атакой re-entrancy attacks.

Способы выявления проблем в контрактах

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

Тесты

— Юнит-тесты или модульное тестирование — тестирования отдельных частей контракта. Мы под этим термином будем в основном понимать тест отдельной функции контракта
— Регрессионное тестирование — запуск тех же тестов на уже протестированном ранне коде, после того как код был изменен. Мы будем под этим понимать повторный запуск тестов после изменений.
— Интеграционные тесты — тесты на взаимодействие модулей и системы в целом. Мы будем под этим термином будем понимать тестирование на взаимодействие контрактов.
— Формальное тестирование — тестирование на смарт-контракта на соответсвие документации

Аудит

• Аудит сторонним разработчиком. Помимо основного разработчика контракт провреяется еще и разработчиком аудитором.
• Баг-баунти — схема при которой код выкладывается в git-репозиторий и всех желающих приглашают за вознаграждение (обычно токенами) найти ошибки.

Предлагаемая система тестиорвания

1. Remix — ранние тесты, выявление мелких ошибок.
   Можно тестировать независимые части контрактов. Проверять компилируется ли контракт вообще. Полезно для раннего unit-тестирования. Зависимые контракты и межконтрактные взаимодействия на данный момент в Remix тестировать нельзя (не работает at address).
2. Написание критических тестов на truffle и последующее тестирование
   Очень полезный этап. В серьезных проектах ему уделяется большое внимание. На truffle можно писать как юнит-тесты так и проводить полноценное интеграционное тестирование с реальными параметрами из продакшен среды.
   Основные полюсы:
   + Возможность «перемтоки» времени
   + Возможность протестировать продакшен конфигурацию
   + Возможность быстро провести регрессионное тестирование
   Часто, уже на этапе написания тестов выявляются серьезные ошибки.
3. Тестирование в тестовой сети
   Наиболее распространенный способ. Контракты или отдельный контракт загружается в одну из тестовых сетей. Контракту устанавливают тестовые параметры, отличные от продуктива. А затем в ручную, избирательно тестируют основные активности.
4. Изменения если необходимо
5. Регрессионное тестирование
6. Аудит кода
7. Баг-баунти

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

Серьезные проекты начинают работать над смарт-контрактом за месяц. Качественное покрытие тестами на truffle удовольствие не из дешевых.

re-entrancy attacks

Очень рапространенная и опасная ошибка. Ее трудно заметить, потому что она связана с особенностью solidity, которая не присутсвует в других языках.

В Solidity есть так называемая fallback функция без названия. Она вызывается всякий раз, когда на контракт отправляется эфир.
Рассмотрим условный контракт дцентрализованной инвестиционной организации. Людой пользоватаель может инвестировать в него отослав немного эфира. И размер инвестиций контракт запишет в balances.

 

Контракт также предоставляет возможность вернуть средства инвестору посредством вызова refund.
И эта функция является уязвимой. Давайте разберемся почему.
Как вы уже наверное заметили, solidity предоставляет возможность переопределить fallback функцию. Что и было сделано в этом контракте.
Если обычный пользователь вызовет refund, то ему вернуться средства и контракт отработает нормально. А теперь представьте, что функцию refund вызывает следующий контракт.

 

 

В первой строчке функции refund контракта VulnerableContract вызывается передача средств на адресс того, кто вызвал refund. А значит будет вызвана fallabck функция у msg.sender. А если наш инвестор является контрактом Scammer. Смотрим что произойдет…

1. Мошенник задеплоил контракт Scammer и вызвал fallback функцию у Scammer
2. fallback функция у Scammer вызвала refund у VulnerableContract
3. В первой строчке refund начинает перевод средств msg.sender.transfer(balances[msg.sender]) — а поскольку msg.sender это контракт Scammer, то вызывается fallabck функция у Scammer и мы переходим в пункт (2).

В результате у нас произойдет зацикливание контракта до тех пор пока не кончится газ или пока не закончатся деньги на контракте. В любом случае транзакция не выполнится. Обратите внимание что при зацикливании мы не доходим до второй строчке в refund. А значит баланс у вызвавшего контракт не обнуляется! Т.е. пока работает зацикливание на счет вызвавшего refund контракта непрерывно переводится эфир. В данном контракт из-за того что закончится газ или средства уязвимость в итоге не проявит себя. Теперь мошеннику остается сделать так, чтобы транзакция завершилась успехом.
Для этого нужно вовремя остановить зацикливание тогда, когда на контракте инветисционной организации останется меньше чем мошенник инвестировал. Давайте исправим конракт мошенника:

 

 

В fallnack функции мы добавили условие проверки
vulnerableContract.balance > invested && counter < COUNTER_LIMIT
Первая часть — это проверка на то, что у фонда достаточно денег для перевода нам, иначе попытка перевести больше чем есть приведет к ошибке. Второй — условное ограничение по счетчику, чтобы транзакция не закончилась испольщовава весь газ.

Как теперь происходит атака:

1. Злоумышленник заливает контракт Scammer в блокчейн
2. Вызывает startAttack с указанием адреса инвестиционного фона и отправляет к примеру 1 эфир.
3. startAttack инвестирует в фонд, а затем сразу вызывает возврат средств vulnerableContract.refund()
4. refund возвращает стредства в размер 1 эфира и одновременно вызывает fallback у Scammer так и не дойдя до слеующей строчки и не обнулив баланс.
5. fallback у Scammer проверяет что средств у фонда еще хватает и сновы вызывает refund. И мы возвращаемся к пункту 3

Когда наконец счетчик дойдет до COUNTER_LIMIT = 10 или средства закончаться у фонда транзакция успешно завершиться. Таким образом вместо 1 эфира мошенник с помощью контракта Scammer украдет до 10 эфиров!

Код, который использует уязвимость называется — эксплоит.

Такая атака называется re-entrancy attacks. С помощью нее были выведены средства The DAO. Пример, который мы тут рассмотрели может быть также функцией refund, которая возвращает средства если softcap не был достигнут в ICO.

Как исправить? Достаточно обунлять баланс ДО отправки эфира.

А теперь рекомендация по написанию безопасного кода. Вызывать функцию отправки средств нужно ПОСЛЕ обновления баланса.