Аудит вне рамок - 0

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

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

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

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

В задаче, на 20-30 строк кода, это понять достаточно просто. Но когда дело касается проекта, где обновление информации в маппинге может быть в совсем другом контракте - заметить это будет проблематично.

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

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

В общем, надеюсь в таких постах вы тоже сможете найти для себя много нового.

#audit #outofbox