Поиск контрабанды запросов

Выявление уязвимостей контрабанды HTTP-запросов с помощью тайминговых методов

Наиболее универсальный способ обнаружения уязвимостей контрабанды HTTP-запросов — отправлять запросы, которые вызовут задержку в ответах приложения, если уязвимость присутствует. Эту технику использует Burp Scanner для автоматизации обнаружения уязвимостей контрабанды запросов.

Выявление CL.TE

Если приложение уязвимо к варианту CL.TE контрабанды запросов, то отправка запроса вида ниже часто приводит к задержке:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Content-Length: 4

1
A
X

Поскольку фронтенд-сервер использует заголовок Content-Length, он перешлёт только часть этого запроса, опустив X. Бэкэнд-сервер использует заголовок Transfer-Encoding, обработает первый блок и затем будет ждать поступления следующего блока. Это вызовет наблюдаемую задержку.

Выявление TE.CL

Если приложение уязвимо к варианту TE.CL контрабанды запросов, то отправка запроса вида ниже часто приводит к задержке:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Content-Length: 6

0

X

Поскольку фронтенд-сервер использует заголовок Transfer-Encoding, он перешлёт только часть этого запроса, опустив X. Бэкэнд-сервер использует заголовок Content-Length, ожидает больше содержимого в теле сообщения и ждёт поступления оставшегося содержимого. Это вызовет наблюдаемую задержку.

Примечание

Тайминговый тест для TE.CL потенциально нарушит работу других пользователей приложения, если приложение уязвимо к варианту CL.TE. Поэтому, чтобы действовать скрытно и минимизировать помехи, сначала используйте тест CL.TE и переходите к тесту TE.CL только если первый тест не дал результата.

Подтверждение уязвимостей контрабанды с помощью различий в ответах

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

  • Атакующего запроса, предназначенного для вмешательства в обработку следующего запроса.

  • Обычного запроса.

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

Например, предположим, что обычный запрос выглядит так:

Обычно этот запрос получает HTTP-ответ со статусом 200, содержащий некоторые результаты поиска.

Атакующий запрос, необходимый для вмешательства в этот запрос, зависит от варианта контрабанды запросов: CL.TE или TE.CL.

Подтверждение уязвимостей CL.TE

Чтобы подтвердить уязвимость CL.TE, вы отправите такой атакующий запрос:

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

Поскольку теперь этот запрос содержит недопустимый URL, сервер ответит статусом 404, что укажет: атакующий запрос действительно повлиял на него.

LAB

HTTP request smuggling, confirming a CL.TE vulnerability via differential responses

Подтверждение уязвимостей TE.CL

Чтобы подтвердить уязвимость TE.CL, вы отправите такой атакующий запрос:

Примечание

Чтобы отправить этот запрос с помощью Burp Repeater, сначала откройте меню Repeater и убедитесь, что опция «Update Content-Length» отключена.

Необходимо добавить завершающую последовательность \r\n\r\n сразу после последнего 0.

Если атака успешна, то всё начиная с GET /404 бэкэнд-сервер воспримет как принадлежащее следующему поступившему запросу. Это приведёт к тому, что последующий обычный запрос будет выглядеть так:

Поскольку теперь этот запрос содержит недопустимый URL, сервер ответит статусом 404, что подтвердить влияние атакующего запроса.

LAB

HTTP request smuggling, confirming a TE.CL vulnerability via differential responses

Примечание

При попытке подтвердить уязвимости контрабанды через вмешательство в другие запросы следует учитывать несколько важных моментов:

  • Атакующий и обычный запросы должны отправляться на сервер по разным сетевым соединениям. Отправка обоих запросов по одному соединению не докажет существование уязвимости.

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

  • При тестировании обычного запроса на предмет вмешательства со стороны атакующего вы соревнуетесь с любыми другими запросами, которые приложение получает в тот же момент, включая запросы других пользователей. Отправляйте обычный запрос сразу после атакующего. Если приложение загружено, возможно, потребуется несколько попыток, чтобы подтвердить уязвимость.

  • В некоторых приложениях фронтенд-сервер выступает как балансировщик нагрузки и пересылает запросы на разные бэкэнд-системы согласно алгоритму балансировки. Если ваши атакующий и обычный запросы отправятся на разные бэкэнд-системы, атака провалится. Это ещё одна причина, по которой может понадобиться несколько попыток до подтверждения уязвимости.

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

Подробнее

Эксплуатация уязвимостей контрабанды HTTP-запросов

PreviousHTTP request smugglingNextЭксплуатация контрабанды запросов

Last updated