Тестирование частых веб-багов с помощью ИИ

С проверенным списком endpoints из чтения JavaScript можно начинать тестирование настоящих багов. Этот пост покрывает четыре класса, которые новичок находит рано: IDOR, межсайтовый скриптинг, подделку запроса на стороне сервера и сломанную аутентификацию. Модель помогает читать responses и выбирать следующий тест. Каждый request вы запускаете сами и каждую находку подтверждаете руками. Держите всё тестирование на хостах, которые перечислены в программе, и для чего-то шумного используйте локальную копию приложения.

#Как пользоваться моделью при тестировании

Модель это вторая пара глаз на response. Вставьте request и его response и спросите, что сервер, похоже, делает с вашим вводом, что вернуло бы безопасное приложение и какое единственное изменение сказало бы вам больше. Она делает это быстро и иногда уверенно ошибается, поэтому каждый ответ это гипотеза для проверки, а не вывод для отчёта. В OWASP Web Security Testing Guide есть полная процедура для каждого класса ниже.

Класс	Какой вопрос вы задаёте	Как проверяете
IDOR	Могу ли я дотянуться до объекта другого пользователя?	Два аккаунта, меняем id, сравниваем responses
XSS	Запускается ли мой ввод как код?	Отражённый ввод исполняется в настоящем браузере
SSRF	Сходит ли сервер по URL, который я выберу?	Подконтрольный вам хост логирует request сервера
Сломанная аутентификация	Могу ли я действовать без нужной сессии?	Request без токена или с чужой ролью проходит

#IDOR: смените идентификатор, прочитайте response

Небезопасная прямая ссылка на объект это самый дружелюбный баг для новичка. Найдите request с идентификатором внутри, например /api/orders/1051, и поменяйте число. Если вам вернётся заказ другого пользователя, приложение не проверяет, кто владелец. Чистый способ доказать это два подконтрольных вам аккаунта: запросите свой объект, потом попробуйте идентификатор второго аккаунта из своей сессии и сравните. Модель помогает заметить, какие поля являются идентификаторами и какие responses различаются так, что это важно.

#XSS: где ввод возвращается как код

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

#SSRF: где сервер сходит по URL

Подделка запроса на стороне сервера случается, когда приложение берёт URL от вас, а сервер сходит по нему. Ищите функции, которые тянут удалённый ресурс: картинку по URL, webhook, превью ссылки. Чтобы тестировать безопасно, направьте функцию на подконтрольный вам хост и следите в своих логах за request сервера. Если сервер обратился наружу, вы подтвердили поведение, а последствия зависят от того, до чего может дотянуться сеть сервера. Описывайте только то, что доказали, и не ходите на охоту за внутренними сервисами дальше, чем разрешает программа.

#Сломанная аутентификация и контроль доступа

Этот класс покрывает requests, которым полагается валидная сессия или конкретная роль, а они обходятся без них. Возьмите аутентифицированный request, уберите токен или подставьте аккаунт с меньшими правами и посмотрите, работает ли он всё ещё. Баги контроля доступа частые, нередко высокого impact и легко доказываются двумя аккаунтами. Модель помогает перечислить, какие действия стоит повторить без сессии, из списка endpoints, который вы собрали раньше.

#Проверяйте, прежде чем поверить

Большую часть потерянного времени в первый месяц новичка съедают ложные срабатывания, к которым подтолкнула модель. Три привычки это предотвращают. Воспроизводите баг из чистого состояния, чтобы знать, что он настоящий, а не кэшированная причуда. Меняйте по одной переменной за раз, чтобы знать, что дало результат. Сохраняйте точные request и response, которые это доказывают, потому что это нужно отчёту и это triager перезапустит. Если вы не можете воспроизвести по требованию, это ещё не находка.

#Дальше в этой серии

API заслуживают своего метода. Тестирование API с ИИ покрывает OpenAPI и GraphQL. OWASP Top 10 и PortSwigger Web Security Academy это ссылки, которые стоит проработать по каждому классу.