Несколько слов о том, что это за атака, как оно работает, к чему может привести и пара примеров из жизни.

Концепт

Давайте представим, что мы наткнулись на этот прекрасный псевдокод.

Разберем что тут происходит.

1. Если переменная timesCalled > 0, то функция завершается ошибкой
2. Вызываем какую-то функцию из стороннего контракта
3. увеличиваем переменную timesCalled на 1

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

Так ли это? Зависит от того, что происходит в externalContractFunction.

Для наглядности того, что мы получим в итоге, в badFunction заменим вызов externalContractFunction на код самой badFunction

В итоге в начале мы имеем набор одинаковых проверок каунтера timesCalled и все они пройдут успешно, т.к. все увеличения каунтера происходят в самом конце. Как итог, в случае если externalContractFunction будет вызвана 2 раза - значение timesCalled после выполнения всего кода будет 2, если 6 раз - то 6 и т.п.

Был ли способ этого избежать?

В примере выше мы сделали одно небольшое изменение - мы поставили вызов externalContractFunction в самый конец. Попробуем развернуть код и посмотреть, что у нас выходит теперь.

После перестановки мы имеем последовательные блоки проверки каунтера и его увеличения, как итог - вызов goodFunction завершится ошибкой в строке 4.

Ближе к реальности

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

В функции mintPublic можно заметить знакомый паттерн.

• проверка каунтера
• вызов функции
• увеличения каунтера

Но в примере с badFunction мы добились эксплуатирования уязвимости за счет кастомного кода в вызываемой фунции, что же не так с _safeMint?

А не так с _safeMint то, что слово safe здесь обозначает только то, что её невозможно использовать для минта токена на контракт, с которого будет невозможно этот токен вывести.

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

Таким образом, атака на подобный контракт выглядит так.

• Деплоим контракт с кастомной функцией onERC721Received
• С нашего атакующего контракта начинаем минт уязвимого контракта
• Уязвимый контракт во время выполнения _safeMint вызывает на атакующем контракте onERC721Received, эта функция в свою очередь снова вызывает mintPublic на уязвимом контракте

Примеры из жизни

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

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

- проверки выделены синим

- вызов внешней функции красным

- необходимые изменения в контракте зеленым

SPOODEEMOONWTF

При минте SPOODEEMOONWTF с контракта, можно не только обойти ограничение в количестве токенов на кошелек, но и глобальное ограничение количества токенов.

LACOSTE

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

GossamerSeed

Здесь так же можно обойти ограничение на количество минт мест на кошелек.

Решил написать эту статью, т.к. каждый раз сталкиваюсь с одними и теми же вопросами.

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

Метадата в NFT - это список всех характеристик конкретного токена, включая traits, которые влияют на рарность токена и, непосредственно, контент (ЖПЕГ которым ты торгуешь, а может и не ЖПЕГ).

Как же ОС и остальные маркеты определяют метаданные и где они хранятся? Давайте разбираться.

Оффчейн

Самый распространенный способ хранения метадаты - оффчейн. Другими словами, где угодно, кроме блокчейна. Это может быть IPFS, это может быть свое облако или даже яндекс диск. В момент, когда маркету\тулзе\боту\пытливому юзеру надо получить метадату конкретного токена, он обращается к контракту и просить выдать ему даные токена с ID #. В ответ получает JSON файл с трейтами, именем, кратким описанием коллекции и всем всем, что ты можешь видеть на ОС, открыв страницу конкретного NFT токена. Среди прочей инфы в JSON хранится ссылка на контент - JPEG или что еще.

Плюсы

- Гибкость в изменении метадаты. В случае с хранением на IPFS будет сложнее, но если же у тебя поднят свой сервер с кастом API - ты можешь менять данные на основе погоды, курса битка (F) или своего настроения. В любое время в зависимости от логики.

Можно хранить любые файлы в любом количестве и любого размера.

Ревил проводится путем простой подмены base URI (был yandex.ru стал google.com) с указанием на актуальные данные или путем манипуляций с API.

Минусы

Оффчейн метадата должна быть загружена на сервер до начала минта, иначе вместо токена на ОС ты увидишь иконку незагруженной картинки и абсолютный ноль трейтов. (Если ты видел такое раньше и фаундеры говорили про проблемы с ОС - значит они обосрались с метадатой или своим API и теперь прикрывают себе задницу). Это так же значит, что команда знает порядок токенов в коллекции и, если будет нужно, они могут её подсмотреть и сминтить нужный токен. Да да, тот самый инсайд трейдинг.

Забыл оплатить облако, взломали сервер, API написано левой пяткой? Холдеры увидят пустые странички вместо своих токенов. (ОС редко обновляет метадату, так что с ОС может все будет ок какое-то время). Фаундеры оказались негодяями? Получи изображение МПХ себе на ПФП.

Ончейн

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

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

Из примеров - Anonymice, EtherOrcs, CyberBrokers (сделали финт ушами и сделали оффчейн коллекцию, собрали денег и на 91 эфира загрузили весь арт в блокчейн).

Из плюсов - никто никогда не потеряет свой токен из-за того что уборщица выдернула провод. Все что было в блокчейне остается в блокчейне включая твой ЖПЕГ. Пока эфир жив - жива и коллекция.

Флекс. Флекс был основной причиной всплеска популярности ончейн коллекций. Рядовому юзеру абсолютно пофиг где хранится картинка. Не пофиг только девам задротам.

Минусы

- Дорого. Если прайс на деплой обычной коллекции колеблется в рендже от 0.2E до 0.5E в среднем, то коллеция 24х24 пиксельных пфп на 70 трейтов может обойтись в 3 эфира на деплое. (Перечитай про CyberBrokers еще раз выше, они потратили 91 эфир на загрузку данных)

- Ограничено (потому что дорого) хочешь запилить 1 токен 1мб фоточку? будь готов заплатить сотни тысяч. Поэтому ончейн ограничен по контенту. Говоря о смешанных коллекциях - есть ребята, которые хранят JS код в ончейн, который при прогрузке на маркетах уже генерирует контент. Но это не тру и мы на такое не ведемся.

- Ончейн предсказуем. Рандома не существует для блокчейна. Любое рандомное число может быть сгенерировано заново кем угодно если ты знаешь входные параметры. Если в случае с оффчейн метадатой ты можешь замешать свои данные как тебе угодно и никто не будет об этом знать (кроме тебя и внимательного сталкера который выследит куда ты загрузил данные), то в случае с ончейн данные следующего токена будет способен просчитать каждый, у кого есть на это достаточно знаний и времени.

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

Итог

Оффчейн\ончейн\смешанная модель. Что выбрать для своей коллекции или что куда подходит лучше?

Если вы делаете свой кэшграб без дальнейшего развития и вообще "no roadmap, no utility, no discord etcetcetc" (ну или это просто пфп\арт проект) - просто загружайте данные на IPFS и забудьте о них, оффчейн - ваш выбор.

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

Вам нужно сделать логику зависящую от конкретных трейтов? Или может вам надо не только менять метаданные, но и отслеживать эти изменения с другого контракта? Смешанная модель для вас. Храните хэши трейтов в ончейне чтоб их можно было читать с контрактов, в зависимости от хэшей грузите метаданные с API.

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