Аудитор, продавай свои баги

Написать этот пост меня сподвигла ситуация, которая происходила со мной на площадках code4rena и sherlock. Можно прочитать сотни аудиторских отчетов, понять важные уязвимости и методы их предотвращения, но упустить из виду один важный момент: то, как пишутся сами отчеты.

Поначалу, я думал, что баг есть баг: если ты его нашел, то молодец, получай оплату. Но не тут-то было.

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

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

Тем не менее, его отклонили. Однако этот репорт пометили, как High, а сам аудитор получил $2382.89 USDC, хотя суть проблемы такая же: доступ к функциям для всех.

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

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

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

Для себя я вынес несколько правил по работе с конкурсными площадками, да и в целом, по работе аудитора:

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

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

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

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

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

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

#audit #report