Важность анализа истории Burp Suite для обхода ошибки 403

[Benzema]

Данная статья является переводом и ведется со слов автора. Оригинал тут.

​

Когда дело доходит до поиска ошибок веб приложения, перебор каталогов является неотъемлемой частью. И иногда, в зависимости от политики программы выявления ошибок или просто от того, как настроены сервера, вам будут попадаться такие вещи, как капча, код ответа 429 или просто полная блокировка вашего IP-адреса.

Есть способы обойти это, но сейчас не об этом. Речь пойдет о проверке интересных конечных точек, возвращающих код ответа 403 (доступ запрещен), и о невозможности их обхода с помощью обычных методов (заголовков, таких как Host, X-forwarded-host, X-forwarded-for и т.д.). Что же тогда? Пора двигаться дальше?

Заголовок Referer и более известный обход​

Возможно, некоторые из вас знают, что определенные конечные точки не будут принимать запросы без заголовка Referer. Обычный случай, когда конечная точка находится например по адресу:

https://admin.target.com/interestingendpoint.php

и если Referer не соответствует поддомену или, по крайней мере, базовому домену, это приведет к коду ответа 403 или 404, или перенаправлению. Но иногда и эти значения заголовка не работают. Запустите Burp или любой другой инструмент для анализа запросов и ответов при просмотре соответствующего веб-сайта.

Заголовок Referer и менее известный обход.​

Это произошло по чистой случайности. Я закончил фаззинг с помощью ffuf на конкретном поддомене, который показался мне интересным. И ничего не получил, поэтому я перешел на другие поддомены. Это была широкомасштабная программа поиска ошибок, так что у меня было много других целей, с которыми можно было поиграть.

Во время работы я также следил за историей в Burp Suite, пытаясь выяснить, как одни конечные точки связаны с другими, и, поскольку это была объемная цель, я также следил за междоменными взаимодействиями. А потом я заметил знакомый поддомен с конечной точкой, которая возвращала 200 OK. Причина, по которой я решил углубиться в это, заключалась в том, что конечная точка в запросе была частью списка слов ffuf и данная конечная точка возвращала там код ответа 403. Чтобы разрешить мою путаницу, я просто скопировал и вставил весь адрес и получил 403. Wtf?

Анализ​

Я скопировал и отправил запрос из истории Burp в Repeater, нажал «Отправить» и получил 200 ОК. Выходит это не было случайностью. Следующим шагом было удаление заголовка User-agent, и я все равно получил 200 OK. Итак, я попробовал удалить Referer и получил 403 Forbidden. ОК. Прогресс… вроде.

Интересным в заголовке Referer было то, что у него был субдомен, отличный от конечной точки (т.е. вместо https://targetsubdomain.target.com это был https://othersubdomain.target.com). Я удалил имя поддомена, полагая, что, возможно, сервер проверяет только часть базового домена (например, https://target.com). И получил… 403 Forbidden.

Итак, я попытался поставить поддомен конечной точки (например, https://targetsubdomain.target.com) и снова… 403 Forbidden. По какой-то причине только один конкретный поддомен разрешал прохождение запроса и давал код ответа 200 OK. Очевидно, я отредактировал заголовок запроса, изменил Referer на этот «специальный» поддомен (например, https://othersubdomain.target.com) и получил ожидаемые 200 OK.

ffuf -c -w words.txt -H "Referer: othersubdomain.target.com" https://somethingelse.target.com/FUZZ

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

Таким образом, в следующий раз, когда у вас будет цель с широким охватом, и один из ее поддоменов имеет интересную конечную точку, которая возвращает 403, а ни один из обычных обходов не работает, попробуйте повозиться с заголовком Referer, но не забудьте объединить это с анализом истории в Burp Suite.