Так, давайте последний кусочек теории перед разбором первой реальной уязвимости
Стандартно у аудита (или одной его итерации в случае приватного) есть 4 шага:
1. Scoping/Обзор. Погружение в контекст, здесь мы получаем доступ к кодовой базе, читаем документацию, бегло смотрим код, запрашиваем данные, если чего-то не хватает. Этап сбора информации, в общем.
2. Reconnaissance/Разведка. Первое вдумчивое чтение кода. Раскидываем вопросительные знаки в комментариях, выписываем приглянувшиеся места, используем инструменты статического анализа, нейронки, в общем получаем первое детальное представление о том коде, который входит в область исследования.
3. Vulnerability Identification/Определение уязвимостей. После полного прохода по коду какие-то места перестанут вызывать вопросы, а те, что останутся должны быть тщательно изучены. На этом моменте происходит оценка уязвимостей, ресерчер пишет proof of code для каждой из них (если это требуется). Доказательство кодом демонстрирует как эксплуатировать уязвимость и показывает, что угроза реальна.
4. Reporting/Создание отчета. После того, как все уязвимости выявлены, необходимые тесты/атакующие скрипты написаны пора приступать к отчету (как правило промежуточно оформляется в md формате, который дальше преобразуется в pdf). Они несколько отличаются для private и competitive аудитов, но описание уязвимостей в них одинаковое, оно всегда должно следовать определенной структуре:
### \[S-#] TITLE (Root Cause + Impact)
[Критичность уязвимости-номер] Название должно содержать причину и влияние
Description: Более подробное описание того почему возникает уязвимость
Impact: Более подробное описание того как она влияет на контракт
Proof of Concept: Доказательство кодом. Считается хорошим тоном предоставлять.
Recommended Mitigation: Предложения по устранению