Поиск распространённых ошибок

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

• IDOR — получение данных других пользователей через предсказуемые идентификаторы
• XSS — внедрение скрипта в страницу
• SSRF — заставить сервер запросить выбранные атакующим URL

В этом уроке показано, как методично искать каждую из них.

Небезопасная прямая ссылка на объект (IDOR) возникает, когда приложение использует предоставленный пользователем идентификатор для получения объекта, не проверяя, принадлежит ли этот объект пользователю.

Измените ID — и получите доступ к чужим данным. Это ошибка контроля доступа, а не внедрение.

Чтобы найти IDOR, создайте две учётные записи и сравните их поведение. Любой объект, на который ссылаются по ID, может быть уязвим.

• Перехватите запрос из учётной записи A, который получает данные A
• Повторите его с сеансом учётной записи B, но с ID объекта A
• Если B видит данные A, это IDOR

Ищите ID в URL, телах JSON, заголовках и даже в формах base64/UUID.

Межсайтовый скриптинг (XSS) — это внедрение JavaScript, который выполняется в браузере другого пользователя. Существует три основных типа:

• Отражённый — полезная нагрузка возвращается в непосредственном ответе
• Сохранённый — полезная нагрузка сохраняется и отправляется другим пользователям (наибольшая опасность)
• На основе DOM — клиентский JS небезопасно записывает пользовательский ввод в DOM

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

Именно контекст определяет, какая полезная нагрузка выйдет за пределы текущего контекста и выполнится.

Простой alert(1) доказывает выполнение, но проверяющим нужна опасность. Покажите, что именно атакующий может украсть или сделать.

• Прочитайте токен CSRF или сведения о сеансе, доступные JS
• Покажите document.domain, чтобы доказать источник
• Для сохранённого XSS покажите его выполнение в учётной записи жертвы

Никогда не крадите сеансы реальных пользователей — только демонстрируйте такую возможность.

SSRF в контексте поиска ошибок означает обнаружение функции, которая получает URL под Вашим контролем. Вероятные кандидаты:

• URL веб-перехватчиков и обратных вызовов
• Генераторы изображений/PDF, загружающие удалённые ресурсы
• Функции предварительного просмотра URL и разворачивания ссылок
• Функции импорта по URL

Укажите для них внутренние конечные точки или конечные точки метаданных, чтобы доказать опасность.

Если ответ не показывает полученное содержимое, используйте внеполосный сервер, чтобы подтвердить, что цель выполнила запрос. Обратный вызов с фиксацией взаимодействия доказывает слепой SSRF.

Такие инструменты, как Burp Collaborator или interactsh, предоставляют уникальный URL, обращения к которому регистрируются.

Все три класса уязвимостей находят, перехватывая и изменяя запросы. Перехватывающий прокси — основной инструмент.

• Burp Suite или OWASP ZAP для перехвата и изменения трафика
• Repeater для повторной отправки и изменения отдельных запросов
• Intruder/fuzzer для проверки множества ID или полезных нагрузок

Глубокое освоение прокси принесёт больше пользы, чем изучение любой отдельной техники.

Самые крупные вознаграждения получают за объединение уязвимостей. Уязвимость средней серьёзности вместе с другой может стать критической.

• SSRF с доступом к облачным метаданным приводит к краже учётных данных и захвату учётной записи
• IDOR, раскрывающая токены, приводит к полной компрометации учётной записи
• Сохранённый XSS в панели администратора приводит к захвату учётной записи администратора

Всегда спрашивайте себя: с чем можно объединить эту уязвимость?

Эти уязвимости затрагивают реальные данные и реальных пользователей. Действуйте этично:

• Используйте собственные тестовые учётные записи и не просматривайте данные реальных пользователей сверх необходимого для доказательства
• Избегайте сохранённых полезных нагрузок XSS, которые могут выполниться у реальных пользователей; ограничьте их своей учётной записью
• При SSRF не углубляйтесь во внутренние системы; докажите сам факт уязвимости и остановитесь

Ответственная демонстрация опасности позволяет Вам оставаться в рамках безопасной гавани.

Вы вошли как пользователь B, повторили запрос с сеансом B, но с ID объекта пользователя A, и получили личные данные A. Какая это уязвимость?

Вы научились искать три наиболее ценных класса уязвимостей.

• IDOR: сравнивайте две учётные записи, изменяйте ID объектов и проверяйте контроль владения
• XSS: проверяйте отражение, подбирайте полезную нагрузку под контекст и доказывайте реальную опасность
• SSRF: находите функции получения URL и подтверждайте слепые случаи внеполосным способом
• Объединяйте уязвимости для критических последствий (например, SSRF с доступом к облачным метаданным)
• Используйте перехватывающий прокси и оставайтесь в пределах области действия

Далее: превращение находок в отчёты, за которые выплачивают вознаграждение.