Викиновости

Атака на системы фронтэнд-бэкенд, позволяющая вклиниться в сторонние запросы

8 августа 2019 года

Раскрыты детали новой атаки на сайты, использующие модель фронтэнд-бэкенд, например, работающие через сети доставки контента, балансировщики или прокси. Атака позволяет через отправку определённых запросов вклиниваться в содержимое других запросов, обрабатываемых в том же потоке между фронтэндом и бэкендом. Предложенный метод успешно применён для организации атаки, позволяющей перехватывать параметры аутентификации пользователей сервиса PayPal, который выплатил исследователям около 40 тысяч долларов в рамках программы информирования о наличии неисправленных уязвимостей. Атака также применима для сайтов, использующих сеть доставки контента Akamai.

Суть проблемы в том, что фронтэнды и бэкенды зачастую обеспечивают разный уровень поддержки протокола HTTP, но при этом инкапсулируют запросы разных пользователей в общий канал. Для связи принимающего запросы фронтэнда и обрабатывающего запросы бэкенда устанавливается долгоживующее TCP-соединение, через которое транслируются запросы пользователей, передаваемые по цепочке один следом за другим с разделением средствами протокола HTTP. Для разделения запросов могут использоваться заголовки "Content-Length" (определяет общий размер данных в запросе) и "Transfer-Encoding: chunked" (позволяет передавать данные по частям, указывая блоки разного размера в формате "{размер}\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-данных. Для более полной проверки подготовлена специальная утилита, которая также тестирует возможные методы скрытия заголовка "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 году была предложена похожая по сути техника подмены запросов, позволяющая подменить данные в кэширующих прокси (Tomcat, squid, mod_proxy) или обойти блокировки межсетевых экранов через указание нескольких запросов "GET" или "POST" в рамках одного HTTP-сеанса.

Источники

править


 
 
Creative Commons
Эта статья содержит материалы из статьи «Атака на системы фронтэнд-бэкенд, позволяющая вклиниться в сторонние запросы», опубликованной OpenNET и распространяющейся на условиях лицензии Creative Commons Attribution (CC BY) — указание автора, источник и лицензию.
 
Эта статья загружена автоматически ботом NewsBots в архив и ещё не проверялась редакторами Викиновостей.
Любой участник может оформить статью: добавить иллюстрации, викифицировать, заполнить шаблоны и добавить категории.
Любой редактор может снять этот шаблон после оформления и проверки.

Комментарии

Викиновости и Wikimedia Foundation не несут ответственности за любые материалы и точки зрения, находящиеся на странице и в разделе комментариев.



Источник — https://ru.wikinews.org/w/index.php?title=Атака_на_системы_фронтэнд-бэкенд,_позволяющая_вклиниться_в_сторонние_запросы&oldid=11097027