Раскрыты (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.me/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.me/opennews/art.shtml?num=51242
Очень круто, ребята молодцы. Атака понятная. Почему-то ожидал что при наличии обоих загловков, "Content-Length: x" и "Transfer-Encoding: chunked" бэкэнд должен автоматически отвергать запрос.
Ошибки он должен обрабатывать. Но половина этих людей: белковые тела для закрытия вовремя поставленных задач.У нас был клоун, написал страницу с вводом эл.почты, но не проверял, что ему ввдят что- вменяемое.
И их полно.
Этот подход имеет право на существование. Проверить что поле email введено корректно нетривиальная задача, так что асептить любой инпут и переложить проверку того что адрес валидный на - SMTP вполне ок. Первый шаг обычно это валидация email, т.е. пользователь который email невалидный или валидный но не существующий получат примерно одинаковый результат.
Либо очень толсто, либо очень глупо.
Как насчёт символов перевода строки во "введённом адресе" и дополнительных команд SMTP?
В таких случаях 3 вещи:
- Проверяем через RegExp на клиенте;
- Проверяем через RegExp на сервере тоже (ибо никогда не верь клиенту);
- Если просто в голо делать конкатенации строк на сервере (того что пришло с клиента) без проверок и использования экранирования - ССЗБ.Если нету всех трех вещей - зачем брать в руки редактор?
Валидность адреса и валидность аргумента SMTP команды — это же разные вещи, речь идет о первом, очевидно что второе должно присутствовать в любом случае.
Из за таких проверяющих у меня на некоторых сайтах адрес принимать не хочет.
Да-да, оторвать руки всем тем кто запрещает '+' использовать.
Круто! Пойду переведу им денег.
Работает ли это в связке nginx-apache?
Отправь предложенный POST и проверь
HTTPшные беды( Ещё один камень в сторону Everything-over-HTTP
не обижайте веб-макак, на них и так природа отыгралась.
А ты какая макака будешь?
"меня вообще очень сложно причислить к поэтам" (ц)
ну и самомнение у вас
Так легко же настраивается и редиректиться. Быстро сдал проект и свинтил подальше, а дырки вали на адимнов.
> один камень в сторону Everything-over-HTTPНадо тупо не ленится и не жмотится на бюджет разработки.
Первое - это веб-макаки.
Вторые - хамы менеджеры.)))
Предлагаете перейти на everything-over-XNNN, заворачивая все в ASN.1?
Заметьте, если во всей цепочке используется HTTP/2 то проблемы нет.
Именно такой нет, зато потом выяснится что там всё ещё эпичнее и надо всем быстро перейти на http/3 (главное запустить процесс частой смены протоколов).
HTTP/3 это QUIC который, как известно, реализуется в userland и багов там, вангую, ввиду специфики конкретных реализаций, будут эшелоны.
Использовать HTTP/2 между фронтендом и бэкэндом - глупость несусветная
Дадада, архитекторы упомянутых в новости CDN тоже так считали. Им повезло, что хакеры оказались в белых шапочках, а то поимели бы их на стопицот лимонов зелени.
> Заметьте, если во всей цепочке используется HTTP/2 то проблемы нет.ну да, зачем все эти геморрои со всраиванием в запросы, когда можно просто стать рутом/вебъюзером на cdn через стопиццотую дыру в нескучном бинарном протоколе.
А где они берут эти кривые фронтенды? Браузеры вроде бы должны корректно это обрабатывать. Какие-нибудь Android-приложения наверняка что-то системное используют, которое должно быть нормально отлажено и вообще сделано по уму
Фронтэнд здесь -- это вообще не браузер.// "а Слава Кпсс -- вообще не человек" (ц)
А Карл, Маркс, Фридрих и Энгельс - это не муж и жена, а четыре разных человека.
> атакующий получит возможность прикрепления произвольных данных к началу чужого запросаЫыы... какая прелесть! Сколь изящна эта схема в своей гениальной простоте!
Помнится, раньше по такой схеме прикреплялись к чужой очереди на турникеты %)
И сейчас оно никуда не ушло.
У админа хорошая память, помнит что в 2005 постил
Довольно типичный подход, когда валят в поток что попало, а потом на стороне сервера это что-попало разбирают формально безо всякого анализа.
Защищаться от такого дорого слишком.
как же юзеры опеннета сгнили.