Раскрыты (https://portswigger.net/blog/http-desync-attacks-request-smu... детали новой атаки на сайты, использующие модель фронтэнд-бэкенд, например, работающие через сети доставки контента, балансировщики или прокси. Атака позволяет через отправку определённых запросов вклиниваться в содержимое других запросов, обрабатываемых в том же потоке между фронтэндом и бэкендом. Предложенный метод успешно применён для организации атаки, позволяющей перехватывать параметры аутентификации пользователей сервиса PayPal, который выплатил исследователям около 40 тысяч долларов в рамках программы информирования о наличии неисправленных уязвимостей. Атака также применима для сайтов, использующих сеть доставки контента Akamai.
Суть проблемы в том, что фронтэнды и бэкенды зачастую обеспечивают разный уровень поддержки протокола HTTP, но при этом инкапсулируют запросы разных пользователей в общий канал. Для связи принимающего запросы фронтэнда и обрабатывающего запросы бэкенда устанавливается долгоживующее TCP-соединение, через которое транслируются запросы пользователей, передаваемые по цепочке, один следом за другим с разделением средствами протокола HTTP. Для разделения запросов могут использоваться заголовки "Content-Length" (определяет общий размер данных в запросе) и "Transfer-Encoding: chunked (https://ru.wikipedia.org/wiki/Chunked_transfer_encoding)" (позволяет передавать данные по частям, указывая блоки разного размера в формате "{размер}\r\n{блок}\r\n{размер}\r\n{блок}\r\n0").
Проблема возникает если фронтэнд поддерживает только "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-данных. Для более полной проверки подготовлена (https://github.com/portswigger/http-request-smuggler) специальная утилита, которая также тестирует возможные методы скрытия заголовка "Transfer-Encoding: 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=//redhat.com@evil.net/ HTTP/1.1").
Применение метода для сетей доставки контента, позволяло просто подменить запрашиваемый сайт через подстановку заголовка "Host:". Атака также применима для организации отравления содержимого систем кэширования контента и извлечения прокешированных конфиденциальных данных. Вершиной применения метода стала организация атаки на PayPal, позволяющей перехватывать пароли, отправляемые пользователями при аутентификации (было осуществлено изменение запроса iframe для выполнения JavaScript в контексте страницы paypal.com/us/gifts, для которой не применялся CSP (Content Security Policy)).
Интересно, что в 2005 году была предложена (https://www.opennet.ru/opennews/art.shtml?num=5619) похожая по сути техника подмены запросов, позволяющая подменить данные в кэширующих прокси (Tomcat, squid, mod_proxy) или обойти блокировки межсетевых экранов через указание нескольких запросов "GET" или "POST" в рамках одного HTTP-сеанса.
URL: https://portswigger.net/blog/http-desync-attacks-request-smu...
Новость: https://www.opennet.ru/opennews/art.shtml?num=51242
