Аудит вне рамок - 0
Хочу сделать некоторую серию постов, в которых будут описаны не столько уязвимости в коде, сколько моменты, на которые стоит акцентировать внимание при проведении аудита.
Через данные посты я хочу сформировать такой метод проведения аудита, в котором у проверяющего с самого начала будет видна общая картина проекта, и он сможет понимать вектор потенциальных атак.
Возможно, это звучит несколько сумбурно, но я попытаюсь объяснить, что хочу сделать.
На канале однажды была задача, в которой уязвимость крылась в том, что разработчик забыл обновить данные в маппинге, что позволяло вызывать withdraw() несколько раз и опустошить таким образом пул.
В задаче, на 20-30 строк кода, это понять достаточно просто. Но когда дело касается проекта, где обновление информации в маппинге может быть в совсем другом контракте - заметить это будет проблематично.
И вот я хочу, чтобы у меня, или у любого другого начинающего аудитора, с самого начала проведения аудита в памяти фиксировалось: "Ага, вот маппинг отвечающий за состояние счета владельца. Он должен обновляться в ключевых функциях". И потом в течение всего периода исследований, это держалось в голове.
Это самый банальный пример логического бага в контракте, когда код кажется написанным верно, но все равно есть проблемы.
В общем, надеюсь в таких постах вы тоже сможете найти для себя много нового.
#audit #outofbox
Хочу сделать некоторую серию постов, в которых будут описаны не столько уязвимости в коде, сколько моменты, на которые стоит акцентировать внимание при проведении аудита.
Через данные посты я хочу сформировать такой метод проведения аудита, в котором у проверяющего с самого начала будет видна общая картина проекта, и он сможет понимать вектор потенциальных атак.
Возможно, это звучит несколько сумбурно, но я попытаюсь объяснить, что хочу сделать.
На канале однажды была задача, в которой уязвимость крылась в том, что разработчик забыл обновить данные в маппинге, что позволяло вызывать withdraw() несколько раз и опустошить таким образом пул.
В задаче, на 20-30 строк кода, это понять достаточно просто. Но когда дело касается проекта, где обновление информации в маппинге может быть в совсем другом контракте - заметить это будет проблематично.
И вот я хочу, чтобы у меня, или у любого другого начинающего аудитора, с самого начала проведения аудита в памяти фиксировалось: "Ага, вот маппинг отвечающий за состояние счета владельца. Он должен обновляться в ключевых функциях". И потом в течение всего периода исследований, это держалось в голове.
Это самый банальный пример логического бага в контракте, когда код кажется написанным верно, но все равно есть проблемы.
В общем, надеюсь в таких постах вы тоже сможете найти для себя много нового.
#audit #outofbox