Контрабанда запросов CL.0
Уязвимости контрабанды запросов возникают из-за расхождений в том, как связанные в цепочку системы определяют, где начинается и заканчивается каждый запрос. Обычно это связано с неконсистентной обработкой заголовка, из-за чего один сервер использует Content-Length запроса, а другой трактует сообщение как chunked. Однако многие из тех же атак можно выполнять, не полагаясь ни на одну из этих проблем.
В некоторых случаях серверы можно вынудить игнорировать заголовок Content-Length, что по сути означает, что они предполагают завершение каждого запроса в конце заголовков. Это фактически равносильно тому, что Content-Length равен 0.
Если бэкэнд-сервер проявляет такое поведение, а фронтенд при этом по-прежнему использует заголовок Content-Length, чтобы определить конец запроса, вы можете эксплуатировать это расхождение для контрабанды запросов.
Тестирование на уязвимости CL.0
Чтобы прощупать уязвимости CL.0, сначала отправьте запрос, содержащий другой частичный запрос в своём теле, а затем отправьте обычный последующий запрос. Затем вы сможете проверить, повлиял ли провезённый префикс на ответ на последующий запрос.
Чтобы проверить наличие уязвимостей CL.0, сначала отправьте запрос, содержащий начало другого запроса в своем теле, а затем отправьте обычный последующий запрос. Затем вы можете проверить, был ли ответ на последующий запрос затронут контрабандным префиксом.
В примере ниже последующий запрос на главную страницу получил ответ 404. Это явно указывает на то, что бэкэнд-сервер интерпретировал тело POST-запроса (GET /hopefully404...) как начало другого запроса.
POST /vulnerable-endpoint HTTP/1.1
Host: vulnerable-website.com
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 34
GET /hopefully404 HTTP/1.1
Foo: xGET / HTTP/1.1
Host: vulnerable-website.comВажно отметить, что мы никоим образом не трогали заголовки — длина запроса указана совершенно нормальным, корректным заголовком Content-Length.
Чтобы попробовать это самостоятельно в Burp Repeater:
Создайте одну вкладку с подготовительным запросом и другую — с произвольным последующим запросом.
Добавьте обе вкладки в группу в правильном порядке.
В раскрывающемся меню рядом с кнопкой Send измените режим отправки на Send group in sequence (single connection).
Измените заголовок
Connectionнаkeep-alive.Отправьте последовательность и проверьте ответы.
На практике чаще всего такое поведение наблюдается на конечных точках, которые просто не ожидают POST-запросов, поэтому они неявно предполагают, что у запросов нет тела. Конечные точки, которые вызывают редиректы на уровне сервера, и запросы статических файлов — основные кандидаты.
Вызов поведения CL.0
Если вы не находите конечных точек, которые кажутся уязвимыми, попробуйте спровоцировать такое поведение.
Когда заголовки запроса вызывают ошибку на сервере, некоторые серверы отдают ответ об ошибке, не считывая тело запроса из сокета. Если затем они не закрывают соединение, это может также стать вектором десинхронизации CL.0.
Вы также можете попробовать использовать GET-запросы с обфусцированным заголовком Content-Length. Если вам удастся скрыть его от бэкэнда, но не от фронтенда, это тоже может привести к десинхронизации. Некоторые техники обфускации заголовков мы рассматривали, когда обсуждали контрабанду запросов TE.TE.
Эксплуатация уязвимостей CL.0
Вы можете эксплуатировать уязвимости CL.0 для тех же серверных атак контрабанды запросов, которые мы разбирали в предыдущих материалах. Попробуйте сами в следующей лабораторной работе.
Уязвимости H2.0
Сайты, которые понижают HTTP/2 запросы до HTTP/1, могут быть уязвимы к аналогичной проблеме H2.0, если бэкэнд-сервер игнорирует заголовок Content-Length пониженного запроса.
Как предотвратить уязвимости CL.0
Некоторые меры для предотвращения уязвимостей CL.0 и других форм десинхронизации смотрите в разделе Как предотвратить уязвимости контрабанды HTTP-запросов.
Что дальше?
Вы можете расширить изученное в этом разделе, чтобы выполнять клиентские варианты ряда атак контрабанды запросов. Чтобы узнать как, ознакомьтесь с разделом Атаки десинхронизации на стороне клиента
Last updated