Суть проблемы в том, что фронтэнды и бэкенды зачастую обеспечивают разный уровень поддержки протокола HTTP, но при этом инкапсулируют запросы разных пользователей в общий канал. Для связи принимающего запросы фронтэнда и обрабатывающего запросы бэкенда устанавливается долгоживующее TCP-соединение, через которое транслируются запросы пользователей, передаваемые по цепочке один следом за другим с разделением средствами протокола HTTP. Для разделения запросов могут использоваться заголовки «Content-Length» (определяет общий размер данных в запросе) и «
Проблема возникает, если фронтэнд поддерживает только «Content-Length», но игнорирует «Transfer-Encoding: chunked» (например, так поступал CDN Akamai) или наоборот. В случае поддержки Transfer-Encoding: chunked» на обеих сторонах для атаки могут использоваться особенности реализации парсеров HTTP-заголовков (например, когда фронтэнд игнорирует строки вида «Transfer-Encoding: xchunked», » Transfer-Encoding: chunked», «Transfer-Encoding:[tab]chunked», «X: X[\n]Transfer-Encoding: chunked», «Transfer-Encoding[\n]: chunked» или «Transfer-Encoding : chunked», а бэкенд успешно обрабатывает их).
В этом случае атакующий может отправить запрос, в котором одновременно указаны заголовки «Content-Length» и «Transfer-Encoding: chunked», но размер в «Content-Length» не соответствует размеру chunked-цепочки, которая меньше фактического значения. Если фронтэнд обработает и перенаправит запрос в соответствии с «Content-Length», а бэкенд будет ожидать завершения блока на основе «Transfer-Encoding: chunked», то конец данных на основании «Transfer-Encoding: chunked» будет определён раньше и оставшийся хвост запроса атакующего окажется вначале следующего запроса, т.е. атакующий получит возможность прикрепления произвольных данных к началу чужого запроса, переданного следом.
Для определения проблемы в используемой связке фронтэнд-бэкенд через фронтэнд можно отправить запрос вида:
POST /about HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
Content-Length: 4
1
Z
Q
Проблема присутствует, если бэкенд сразу не обработает запрос и будет ожидать прихода финального нулевого ограничивающего блока chunked-данных. Для более полной проверки
Проведение реальной атаки зависит от возможностей атакуемого сайта, например, при атаке на web-приложение Trello можно подменить начало запроса (подставить данные вида «PUT /1/members/1234… x=x&csrf=1234&username=testzzz&bio=cake») и отправить сообщение, включающее оригинальный запрос стороннего пользователя и указанные в нём Cookie аутентификации. Для атаки на saas-app.com оказалось возможным осуществить подстановку JavaScript-кода в ответ, через его подстановку в один из параметров запроса. Для атаки на redhat.com был использован внутренний обработчик для перенаправления на сайт атакующего (был подставлен запрос вида «POST /search?dest=../assets/idx?redir=//[email protected]/ HTTP/1.1»).
Применение метода для сетей доставки контента позволяло просто подменить запрашиваемый сайт через подстановку заголовка «Host:». Атака также применима для организации отравления содержимого систем кэширования контента и извлечения прокешированных конфиденциальных данных. Вершиной применения метода стала организация атаки на PayPal, позволяющей перехватывать пароли, отправляемые пользователями при аутентификации (было осуществлено изменение запроса iframe для выполнения JavaScript в контексте страницы paypal.com/us/gifts, для которой не применялся CSP (Content Security Policy)).
Интересно, что в 2005 году была
Источник: opennet.ru