Техника атаки HTTP Request Smuggling (контрабанда вредоносных HTTP-запросов на бэкенд в результате рассинхронизации фронтенд- и бэкенд-серверов) известна 15 лет, хотя в прошлом году Джеймс Кеттл рассказал о новых методах, c помощью которых заработал на bugbounty около $70 000. Судя по всему, атака эффективна и сейчас, причём уязвимы многие.
12 марта 2020 года на портале HackerOne рассекретили описание уязвимости Slack, которую закрыли 13 февраля. Оказывается, до этого времени сессионные куки пользователей Slack были доступны для массового перехвата. Описание взлома Slack довольно подробное, поэтому заслуживает внимания. Похоже, что эту технику можно использовать для взлома других сервисов, которые работают за прокси (AWS ALB, nginx, haproxy до 2.0.6 и прочие).
Автор по имени Эван рассказывает на HackerOne, что он специализируется на атаках данного типа, поэтому разработал собственный инструментарий (судя по всему, это программа
smuggler). Он решил проверить её на сервере slackb.com (см. скриншот). 
Внимание привлёк тест
space1, который проверяет возможность рассинхронизации HTTP:
Программа возвращала ошибку после прогона теста CLTE. Это запрос, который включает в себя одновременно заголовки
Transfer-Encoding: chunked (с лишним пробелом перед двоеточием) и Content-Length: (CL). Согласно RFC, при одновременном получении этих двух заголовков приоритет всегда у TE. Но если TE аномальный, то он может по-разному интерпретироваться на фронтенде и бэкенде. Так и вышло в случае https://slackb.com. Здесь фронтенд интерпретировал размер запроса по CL, а бэкенд сначала обрабатывает TE. Лишнего пробела оказалось достаточно, чтобы фронтенд не распознал TE.Такая ситуация приводит к рассинхронизации запроса и возможности отравления сокета на бэкенде с предварительным отложением данных на бэкенде (так работает одна из популярных атак с контрабандой запросов).
Фронтенд принимает на веру указанную длину пакета и не обрабатывает код, который указан дальше указанного количества бит. А бэкенд — обрабатывает протянутый «контрабандой» вредоносный запрос, как показано на скриншоте.
Получив запрос типа
GET <URL> HTTP/1.1, бэкенд отвечает следующим образом:
… отправляя на указанный URL все куки, включая сессионный ('d').
В своём сообщении Эван приводит пошаговую инструкцию, как проверить сервер на наличие уязвимости в программе Burp Collaborator.
Украденный куки:
Остаётся надеяться, что злоумышленники не воспользуются этой информацией на других серверах.
Пока не совсем ясно, какие конкретно прокси уязвимы для этой атаки, а какие — нет. Более того, рассинхронизация возможна в том случае, если прокси корректно действует в соответствии с RFC, а ваше приложение — нет. Так что для лучшей уверенности желательно проверить конфигурацию целиком.
