The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

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

08.08.2019 11:22

Раскрыты детали новой атаки на сайты, использующие модель фронтэнд-бэкенд, например, работающие через сети доставки контента, балансировщики или прокси. Атака позволяет через отправку определённых запросов вклиниваться в содержимое других запросов, обрабатываемых в том же потоке между фронтэндом и бэкендом. Предложенный метод успешно применён для организации атаки, позволяющей перехватывать параметры аутентификации пользователей сервиса 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-сеанса.

  1. Главная ссылка к новости (https://portswigger.net/blog/h...)
  2. OpenNews: Использование настроек по умолчанию в Apache способствует раскрытию данных о скрытых сервисах Tor
  3. OpenNews: Как работает chunked encoding exploit для Apache
  4. OpenNews: Удалённо эксплуатируемая уязвимость в обработчике chunked-запросов Apache
  5. OpenNews: Уязвимость в BitTorrent-клиенте Transmission, позволяющая выполнить код
  6. OpenNews: Новая техника HTTP атак "HTTP Request Smuggling"
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/51242-http
Ключевые слова: http, frontend, backend, web
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (35) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 13:13, 08/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Очень круто, ребята молодцы. Атака понятная. Почему-то ожидал что при наличии обоих загловков, "Content-Length: x" и "Transfer-Encoding: chunked" бэкэнд должен автоматически отвергать запрос.
     
     
  • 2.22, А (??), 21:53, 08/08/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ошибки он должен обрабатывать. Но половина этих людей: белковые тела для закрытия вовремя поставленных задач.

    У нас был клоун, написал страницу с вводом эл.почты, но не проверял, что ему ввдят что- вменяемое.

    И их полно.

     
     
  • 3.26, Аноним (26), 06:25, 09/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Этот подход имеет право на существование. Проверить что поле email введено корректно нетривиальная задача, так что асептить любой инпут и переложить проверку того что адрес валидный на - SMTP вполне ок. Первый шаг обычно это валидация email, т.е. пользователь который email невалидный или валидный но не существующий получат примерно одинаковый результат.
     
     
  • 4.27, Онаним (?), 09:10, 09/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Либо очень толсто, либо очень глупо.
    Как насчёт символов перевода строки во "введённом адресе" и дополнительных команд SMTP?
     
     
  • 5.31, Иваныч (??), 22:51, 10/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В таких случаях 3 вещи:
    - Проверяем через RegExp на клиенте;
    - Проверяем через RegExp на сервере тоже (ибо никогда не верь клиенту);
    - Если просто в голо делать конкатенации строк на сервере (того что пришло с клиента) без проверок и использования экранирования - ССЗБ.

    Если нету всех трех вещей - зачем брать в руки редактор?

     
  • 5.34, Аноним (34), 11:25, 12/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Валидность адреса и валидность аргумента SMTP команды — это же разные вещи, речь идет о первом, очевидно что второе должно присутствовать в любом случае.
     
  • 3.28, Аноним (28), 10:16, 09/08/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Из за таких проверяющих у меня на некоторых сайтах адрес принимать не хочет.
     
     
  • 4.35, Alukardd (ok), 16:34, 12/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да-да, оторвать руки всем тем кто запрещает '+' использовать.
     

  • 1.2, Аноним (2), 13:19, 08/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Круто! Пойду переведу им денег.
     
  • 1.3, Аноним (3), 13:21, 08/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Работает ли это в связке nginx-apache?
     
  • 1.4, Аноним (4), 13:29, 08/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Отправь предложенный POST и проверь
     
  • 1.7, Аноним (7), 14:24, 08/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    HTTPшные беды( Ещё один камень в сторону Everything-over-HTTP
     
     
  • 2.11, ы (?), 14:46, 08/08/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    не обижайте веб-макак, на них и так природа отыгралась.
     
     
  • 3.13, Аноним (13), 15:57, 08/08/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А ты какая макака будешь?
     
     
  • 4.14, ы (?), 16:26, 08/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    "меня вообще очень сложно причислить к поэтам" (ц)
     
     
  • 5.29, жека воробьев (?), 12:20, 09/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ну и самомнение у вас
     
  • 2.17, letsmac (ok), 18:22, 08/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Так легко же настраивается и редиректиться. Быстро сдал проект и свинтил подальше, а дырки вали на адимнов.
     
  • 2.23, А (??), 22:37, 08/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > один камень в сторону Everything-over-HTTP

    Надо тупо не ленится и не жмотится на бюджет разработки.

    Первое - это веб-макаки.
    Вторые - хамы менеджеры.

    )))

     
  • 2.24, Hewlett Packard (?), 23:21, 08/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Предлагаете перейти на everything-over-XNNN, заворачивая все в ASN.1?
     

  • 1.8, xm (ok), 14:35, 08/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Заметьте, если во всей цепочке используется HTTP/2 то проблемы нет.
     
     
  • 2.9, Аноним (9), 14:40, 08/08/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Именно такой нет, зато потом выяснится что там всё ещё эпичнее и надо всем быстро перейти на http/3 (главное запустить процесс частой смены протоколов).
     
     
  • 3.10, xm (ok), 14:45, 08/08/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    HTTP/3 это QUIC который, как известно, реализуется в userland и багов там, вангую, ввиду специфики конкретных реализаций, будут эшелоны.
     
  • 2.15, Аноним (15), 17:48, 08/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Использовать HTTP/2 между фронтендом и бэкэндом - глупость несусветная
     
     
  • 3.18, Аноним (18), 18:27, 08/08/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Дадада, архитекторы упомянутых в новости CDN тоже так считали. Им повезло, что хакеры оказались в белых шапочках, а то поимели бы их на стопицот лимонов зелени.
     
  • 2.33, пох. (?), 12:41, 11/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Заметьте, если во всей цепочке используется HTTP/2 то проблемы нет.

    ну да, зачем все эти геморрои со всраиванием в запросы, когда можно просто стать рутом/вебъюзером на cdn через стопиццотую дыру в нескучном бинарном протоколе.

     

  • 1.12, snmp agent (?), 15:28, 08/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А где они берут эти кривые фронтенды? Браузеры вроде бы должны корректно это обрабатывать. Какие-нибудь Android-приложения наверняка что-то системное используют, которое должно быть нормально отлажено и вообще сделано по уму
     
     
  • 2.16, Michael Shigorin (ok), 17:58, 08/08/2019 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Фронтэнд здесь -- это вообще не браузер.

    // "а Слава Кпсс -- вообще не человек" (ц)

     
     
  • 3.19, Аноним (18), 18:28, 08/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А Карл, Маркс, Фридрих и Энгельс - это не муж и жена, а четыре разных человека.
     

  • 1.20, Аноним (18), 18:30, 08/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > атакующий получит возможность прикрепления произвольных данных к началу чужого запроса

    Ыыы... какая прелесть! Сколь изящна эта схема в своей гениальной простоте!

     
  • 1.21, InuYasha (?), 21:20, 08/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Помнится, раньше по такой схеме прикреплялись к чужой очереди на турникеты %)
     
     
  • 2.32, Алексей Михайлович (?), 06:09, 11/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    И сейчас оно никуда не ушло.
     

  • 1.30, Fedd (ok), 14:05, 09/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    У админа хорошая память, помнит что в 2005 постил
     
  • 1.36, Аноним (36), 17:29, 12/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Довольно типичный подход, когда валят в поток что попало, а потом на стороне сервера это что-попало разбирают формально безо всякого анализа.
     
  • 1.37, Аноним (36), 17:30, 12/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Защищаться от такого дорого слишком.
     
  • 1.38, Аноним (38), 19:39, 29/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    как же юзеры опеннета сгнили.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру