Использование ИИ для поиска багов авторизации

Программы Bug Bounty закрываются. Nextcloud прекратил выплаты вознаграждений из-за низкокачественных отчетов, созданных ИИ. Mattermost завершил свою программу. Internet Bug Bounty сократил выплаты на 80 процентов.

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

В 2026 году вам понадобится не навык поиска багов. Модель выдаст вам пятьдесят идей еще до обеда. Настоящий навык — это умение доказать, почему сорок девять из них ложны. Вам нужен метод, который выдает верные отрицательные результаты.

Используйте этот двухэтапный метод для source-available кода:

  1. Fan-out (Дешевые модели) Разделите поверхность авторизации на небольшие части. Читайте каждую часть параллельно. Ищите нарушения правил. Ищите места, где объект загружается без проверки владельца. Ищите пути, которые обходят защитные барьеры. Сосредоточьтесь на поиске всех возможных зацепок. Будьте готовы к множеству ложноположительных результатов.

  2. Adversarial Verification (Дорогие модели) Берите каждую зацепку и пытайтесь её опровергнуть. Исходите из предположения, что зацепка ложна. Зацепка выживает только в том случае, если вы можете показать конкретные строки кода, доказывающие отсутствие проверки безопасности. Вы должны доказать, что путь достижим и ничто другое не препятствует атаке.

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

Я протестировал Ory Kratos, сервер идентификации. Система обрабатывает конфиденциальные действия, такие как смена паролей или адресов электронной почты. Это зона высокого риска.

Первый этап выявил зацепку. Это выглядело как серьезная уязвимость в том, как система обрабатывает OIDC-потоки. Инструмент сопоставления паттернов назвал бы это багом высокой степени критичности.

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

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

Тот же метод помог найти реальный баг в другом объекте. Вторичная точка входа «забыла» продублировать проверку авторизации. Пользователь мог войти через «черный ход», даже если его доступ был отозван.

Победителями в bug hunting станут те, кто сосредоточится на сигнале, а не на объеме. Используйте ИИ, чтобы читать больше кода, чем человек. А затем используйте ИИ, чтобы опровергнуть самого себя, прежде чем отправлять отчет.

Source: https://dev.to/fdjedkdlsspec/using-ai-to-find-authorization-bugs-and-to-prove-the-ones-that-arent-real-3m7d

Optional learning community: https://t.me/GyaanSetuAi