На реальном примере:

Контрабанда HTTP-запросов:

Несколько спроектированных HTTP-запросов, в которых задействованные сущности видят разные запросы. Контрабандные запросы на одно устройство без ведома другого устройства; управлять последовательностью запросов / ответов.

Пример: В инфраструктуре у нас есть балансировщик нагрузки и веб-сервер, а балансировщик нагрузки отправляет несколько запросов на веб-сервер. Каждый запрос имеет разную длину содержимого. Итак, если так или иначе злоумышленник сможет выполнить несанкционированный запрос между балансировщиком нагрузки на веб-сервер.

HTTP-заголовок Http-request-Smuggling 2 имеет очень важную роль.

· Content-Length: указывает размер тела запроса. Просто любые данные, отправленные в запросе POST, относятся к длине содержимого.

· Кодирование передачи: кодирование передачи, используемое для обхода атаки WAF, и мы реализуем «кодирование передачи» в виде фрагментов, то есть мы передаем тело полезной нагрузки фрагментами. Это упростит нам обход WAF или манипуляции с сервером. Данные фрагментов будут передаваться в буферах разной длины, благодаря чему соединение будет непрерывным до тех пор, пока не будет сдвинута вся полезная нагрузка.

Так что всякий раз, когда злоумышленник может управлять лимитом внешнего и внутреннего интерфейса HTTP-запроса. Http-request-Smuggling позволяет использовать множество других атак, например:

· Отравление веб-кеша: путем изменения записей в кэше, чтобы из существующего кэша страницы A была переведена страница B.

· Перехват сеанса. Это происходит, когда клиент использует прокси-сервер и делится учетными данными с веб-сервером.

· Обход защиты брандмауэра веб-приложений: WAF не имеет правил для незаконных запросов.

Некоторые техники помогают злоумышленнику выполнить вышеуказанные атаки.

· Удвойте заголовок длины содержимого: отправляя заголовок длины содержимого 2 раза в запросе, мы можем обойти ограничения длины содержимого между внешним и внутренним сервером. Таким образом, первые заголовки длины содержимого игнорируются, а второй заголовок длины содержимого обрабатывается, и это поможет скрыть запрос.

· Длина содержимого, кодировка передачи. Таким образом, внешний и внутренний сервер имеют разные приоритеты в отношении длины содержимого и заголовка кодирования передачи. У разных устройств разные приоритеты. Следовательно, если длина содержимого имеет больший приоритет над кодированием, поэтому внутренний сервер будет обрабатывать запрос в конце символа 0. В результате запрос 404-й страницы не найден, обрабатывается как отдельный запрос.

Работает:

· Злоумышленник создает запрос, длина содержимого которого равна 0, И кодировка передачи установлена ​​как отброшенная, а в теле он упомянул запрос к другой конечной точке после разрыва строки.

· Когда интерфейсный сервер увидел запрос и увидел длину контента 0, он будет понимать несколько запросов, идущих рядом с одним запросом. Теперь промежуточное программное обеспечение считает, что, поскольку данные поступают порциями и длина содержимого первого запроса равна 0, тело - это данные другого запроса.

· Процесс внутреннего сервера передает запрос и конечную точку, которая добавляется в запрос.

Эксплуатация:

В нем мы должны передавать запрос, поэтому следующий запрос, обслуживаемый внутренним сервером, может использовать метод GPOST, а внешний конечный сервер принимает только методы GET и POST.

Перехваченный запрос выглядит так.

Как я уже упоминал ранее, интерфейсный сервер принимает только методы GET и POST. Когда я изменил GET на HEAD и пересылал запросы, это дало мне ошибку.

Поэтому я обновлю получить перехваченный запрос в POST, так как мне нужно отправить некоторый контент в теле запроса, чтобы переправить запрос. В приведенном выше запросе GET я должен добавить один заголовок, то есть «Transfer-Encoding».

Теперь мы добавляем тело к этому обновленному запросу. Итак, я добавлю «0» и «G».

· «0»: показывает, что длина содержимого первого запроса равна нулю. Благодаря этому мы можем отправлять наши 2 запроса по частям.

· «G»: поскольку нам нужен ответный метод GPOST.

1-й запрос: после 1-го запроса от сервера мы получили 200 ОК, так как он обрабатывает первые фрагменты длины 0, это рассматривается как запрос завершения.

2-й запрос: но полная длина содержания в запросе 10, мы пересылаем один и тот же запрос 2 раза. Таким образом, оставшаяся длина содержимого не обрабатывается, и внутренний сервер будет рассматривать их как новый запрос. Таким образом, запрос обработан, и внутренний сервер, похоже, использует метод «GPOST».

Исправление:

Это немного сложно и зависит от бизнес-потребностей клиентов.

· Каждый раз, когда запрос имеет длину содержимого и кодировку передачи, оба в заголовке запроса пытаются заблокировать этот запрос.

· Если блокировка для обоих 2 заголовков невозможна, попробуйте дать больший приоритет кодировке передачи по сравнению с длиной содержимого.

· Следует более аккуратно обрабатывать синтаксический анализ и очистку кодировки передачи.

· Внедрить WAF в инфраструктуру, чтобы можно было снизить скорость, нельзя полностью удалить ее полностью, но попытайтесь уменьшить количество.

· Понять поведение устройства инфраструктуры, чтобы мы могли избежать незаконных запросов.