maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-web/http-request-smuggling/README.md', 'src/

Browse Source
This commit is contained in:
Translator 2025-08-20 16:35:36 +00:00
parent 90f50f3b88
commit 4c1906f1fb
2 changed files with 176 additions and 47 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

205
src/pentesting-web/http-request-smuggling/README.md
View File

@ -2,9 +2,10 @@
{{#include ../../banners/hacktricks-training.md}}
## Що таке
Ця вразливість виникає, коли **десинхронізація** між **фронтальними проксі** та **бекенд** сервером дозволяє **зловмиснику** **надіслати** HTTP **запит**, який буде **інтерпретований** як **один запит** фронтальними проксі (балансування навантаження/реверсний проксі) і **як 2 запити** бекенд сервером.\
Ця вразливість виникає, коли **десинхронізація** між **фронтальними проксі** та **бекенд** сервером дозволяє **зловмиснику** **надіслати** HTTP **запит**, який буде **інтерпретований** як **один запит** фронтальними проксі (балансування навантаження/реверс-проксі) і **як 2 запити** бекенд сервером.\
Це дозволяє користувачу **модифікувати наступний запит, який надходить до бекенд сервера після його**.
### Теорія
@ -24,29 +25,29 @@
### Реальність
**Фронтальне** (балансування навантаження / Реверсний Проксі) **обробляє** _**content-length**_ або _**transfer-encoding**_ заголовок, а **бекенд** сервер **обробляє інший**, викликаючи **десинхронізацію** між 2 системами.\
Це може бути дуже критично, оскільки **зловмисник зможе надіслати один запит** до реверсного проксі, який буде **інтерпретований** бекенд сервером **як 2 різні запити**. **Небезпека** цієї техніки полягає в тому, що **бекенд** сервер **інтерпретує** **2-й запит, що інжектується**, як якщо б він **надійшов від наступного клієнта**, а **реальний запит** цього клієнта буде **частиною** **інжектованого запиту**.
**Фронтальне** (балансування навантаження / Реверс-проксі) **обробляє** _**content-length**_ або _**transfer-encoding**_ заголовок, а **бекенд** сервер **обробляє інший**, викликаючи **десинхронізацію** між 2 системами.\
Це може бути дуже критично, оскільки **зловмисник зможе надіслати один запит** до реверс-проксі, який буде **інтерпретований** бекенд сервером **як 2 різні запити**. **Небезпека** цієї техніки полягає в тому, що **бекенд** сервер **інтерпретує** **2-й запит, що інжектується**, як якщо б він **надійшов від наступного клієнта**, а **реальний запит** цього клієнта буде **частиною** **інжектованого запиту**.
### Особливості
Пам'ятайте, що в HTTP **новий символ рядка складається з 2 байтів:**
- **Content-Length**: Цей заголовок використовує **десяткове число** для вказівки **кількості** **байтів** тіла запиту. Тіло, як очікується, закінчується останнім символом, **новий рядок не потрібен в кінці запиту**.
- **Content-Length**: Цей заголовок використовує **десяткове число** для вказівки **кількості** **байтів** тіла запиту. Тіло очікується, що закінчується останнім символом, **новий рядок не потрібен в кінці запиту**.
- **Transfer-Encoding:** Цей заголовок використовує в **тілі** **шістнадцяткове число** для вказівки **кількості** **байтів** **наступного фрагмента**. **Фрагмент** повинен **закінчуватися** **новим рядком**, але цей новий рядок **не враховується** індикатором довжини. Цей метод передачі повинен закінчуватися **фрагментом розміром 0, за яким слідують 2 нові рядки**: `0`
- **Connection**: Згідно з моїм досвідом, рекомендується використовувати **`Connection: keep-alive`** в першому запиті при використанні HTTP Request Smuggling.
- **Connection**: Згідно з моїм досвідом, рекомендується використовувати **`Connection: keep-alive`** в першому запиті при експлуатації Smuggling.
## Основні приклади
> [!TIP]
> При спробі експлуатувати це з Burp Suite **відключіть `Update Content-Length` та `Normalize HTTP/1 line endings`** в повторювачі, оскільки деякі гаджети зловживають новими рядками, поверненнями каретки та неправильно сформованими content-length.
> При спробі експлуатувати це з Burp Suite **вимкніть `Update Content-Length` та `Normalize HTTP/1 line endings`** в повторювачі, оскільки деякі гаджети зловживають новими рядками, поверненнями каретки та неправильно сформованими content-length.
Атаки HTTP request smuggling створюються шляхом надсилання неоднозначних запитів, які експлуатують розбіжності в тому, як фронтальні та бекенд сервери інтерпретують заголовки `Content-Length` (CL) та `Transfer-Encoding` (TE). Ці атаки можуть проявлятися в різних формах, головним чином як **CL.TE**, **TE.CL** та **TE.TE**. Кожен тип представляє унікальну комбінацію того, як фронтальні та бекенд сервери пріоритетизують ці заголовки. Вразливості виникають через те, що сервери обробляють один і той же запит по-різному, що призводить до несподіваних і потенційно шкідливих наслідків.
Атаки HTTP request smuggling створюються шляхом надсилання неоднозначних запитів, які експлуатують розбіжності в тому, як фронтальні та бекенд сервери інтерпретують заголовки `Content-Length` (CL) та `Transfer-Encoding` (TE). Ці атаки можуть проявлятися в різних формах, головним чином як **CL.TE**, **TE.CL** та **TE.TE**. Кожен тип представляє унікальну комбінацію того, як фронтальні та бекенд сервери пріоритизують ці заголовки. Вразливості виникають через те, що сервери обробляють один і той же запит по-різному, що призводить до несподіваних і потенційно шкідливих наслідків.
### Основні приклади типів вразливостей
![https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104](../../images/EKi5edAUUAAIPIK.jpg)
> [!NOTE]
> [!TIP]
> До попередньої таблиці слід додати техніку TE.0, як техніку CL.0, але з використанням Transfer Encoding.
#### Вразливість CL.TE (Content-Length використовується фронтальним, Transfer-Encoding використовується бекендом)
@ -80,7 +81,7 @@ Foo: x
- **Сценарій атаки:**
- Зловмисник надсилає фрагментований запит, де розмір фрагмента (`7b`) і фактична довжина вмісту (`Content-Length: 4`) не збігаються.
- Фронтальний сервер, дотримуючись `Transfer-Encoding`, пересилає весь запит до бекенду.
- Фронтальний сервер, поважаючи `Transfer-Encoding`, пересилає весь запит до бекенду.
- Бекенд сервер, поважаючи `Content-Length`, обробляє лише початкову частину запиту (`7b` байтів), залишаючи решту частиною ненавмисного наступного запиту.
- **Приклад:**
@ -132,7 +133,7 @@ Transfer-Encoding
#### **Сценарій CL.CL (Content-Length використовується як фронтальним, так і бекендом)**
- Обидва сервери обробляють запит виключно на основі заголовка `Content-Length`.
- Цей сценарій зазвичай не призводить до смуглінгу, оскільки існує узгодженість у тому, як обидва сервери інтерпретують довжину запиту.
- Цей сценарій зазвичай не призводить до смуглінгу, оскільки є узгодженість у тому, як обидва сервери інтерпретують довжину запиту.
- **Приклад:**
```
@ -163,7 +164,7 @@ Non-Empty Body
- Як попередній, але з використанням TE
- Техніка [повідомлена тут](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
- **Приклад:**
- **Приклад**:
```
OPTIONS / HTTP/1.1
Host: {HOST}
@ -185,11 +186,11 @@ EMPTY_LINE_HERE
Ця техніка також корисна в сценаріях, де можливо **зламати веб-сервер під час читання початкових HTTP-даних**, але **без закриття з'єднання**. Таким чином, **тіло** HTTP-запиту буде вважатися **наступним HTTP-запитом**.
Наприклад, як пояснено в [**цьому описі**](https://mizu.re/post/twisty-python), у Werkzeug було можливо надіслати деякі **Unicode** символи, і це призведе до **зламу** сервера. Однак, якщо HTTP-з'єднання було створено з заголовком **`Connection: keep-alive`**, тіло запиту не буде прочитано, і з'єднання залишиться відкритим, тому **тіло** запиту буде розглядатися як **наступний HTTP-запит**.
Наприклад, як пояснено в [**цьому описі**](https://mizu.re/post/twisty-python), в Werkzeug було можливо надіслати деякі **Unicode** символи, і це призведе до **зламу** сервера. Однак, якщо HTTP-з'єднання було створено з заголовком **`Connection: keep-alive`**, тіло запиту не буде прочитано, і з'єднання залишиться відкритим, тому **тіло** запиту буде розглядатися як **наступний HTTP-запит**.
#### Примус через заголовки hop-by-hop
Зловживаючи заголовками hop-by-hop, ви можете вказати проксі **видалити заголовок Content-Length або Transfer-Encoding, щоб зловживання HTTP-запитом було можливим**.
Зловживаючи заголовками hop-by-hop, ви можете вказати проксі **видалити заголовок Content-Length або Transfer-Encoding, щоб зловживання HTTP-запитом стало можливим**.
```
Connection: Content-Length
```
@ -224,7 +225,7 @@ A
- **Спостереження:**
- Сервер на передньому плані обробляє запит на основі `Content-Length` і перериває повідомлення передчасно.
- Сервер на задньому плані, очікуючи на частину повідомлення, чекає на наступну частину, яка ніколи не приходить, що викликає затримку.
- Сервер на задньому плані, очікуючи на часткове повідомлення, чекає на наступну частину, яка ніколи не приходить, що викликає затримку.
- **Індикатори:**
- Тайм-аути або тривалі затримки у відповіді.
@ -257,15 +258,15 @@ X
- **Аналіз диференційних відповідей:**
- Надішліть трохи змінені версії запиту та спостерігайте, чи відповіді сервера відрізняються несподіваним чином, що вказує на розбіжність у парсингу.
- **Використання автоматизованих інструментів:**
- Інструменти, такі як розширення 'HTTP Request Smuggler' у Burp Suite, можуть автоматично перевіряти ці вразливості, надсилаючи різні форми неоднозначних запитів і аналізуючи відповіді.
- Інструменти, такі як розширення 'HTTP Request Smuggler' Burp Suite, можуть автоматично перевіряти ці вразливості, надсилаючи різні форми неоднозначних запитів і аналізуючи відповіді.
- **Тести на варіацію Content-Length:**
- Надішліть запити з різними значеннями `Content-Length`, які не відповідають фактичній довжині вмісту, і спостерігайте, як сервер обробляє такі невідповідності.
- Надсилайте запити з різними значеннями `Content-Length`, які не відповідають фактичній довжині вмісту, і спостерігайте, як сервер обробляє такі невідповідності.
- **Тести на варіацію Transfer-Encoding:**
- Надішліть запити з заплутаними або неправильно сформованими заголовками `Transfer-Encoding` і спостерігайте, як по-різному реагують сервери на передньому та задньому плані на такі маніпуляції.
- Надсилайте запити з обфусцированими або неправильно сформованими заголовками `Transfer-Encoding` і спостерігайте, як по-різному реагують сервери на передньому та задньому плані на такі маніпуляції.
### Тестування вразливостей HTTP Request Smuggling
Після підтвердження ефективності технік таймінгу важливо перевірити, чи можна маніпулювати запитами клієнта. Простий метод - спробувати отруїти свої запити, наприклад, зробивши запит до `/`, щоб отримати відповідь 404. Приклади `CL.TE` та `TE.CL`, обговорені раніше в [Основних прикладах](#basic-examples), демонструють, як отруїти запит клієнта, щоб викликати відповідь 404, незважаючи на те, що клієнт намагається отримати доступ до іншого ресурсу.
Після підтвердження ефективності технік таймінгу важливо перевірити, чи можна маніпулювати запитами клієнта. Простий метод - спробувати отруїти ваші запити, наприклад, зробивши запит до `/`, щоб отримати відповідь 404. Приклади `CL.TE` та `TE.CL`, обговорені раніше в [Basic Examples](#basic-examples), демонструють, як отруїти запит клієнта, щоб викликати відповідь 404, незважаючи на те, що клієнт намагається отримати доступ до іншого ресурсу.
**Ключові міркування**
@ -273,19 +274,125 @@ X
- **Відокремлені мережеві з'єднання:** "Атакуючі" та "нормальні" запити повинні надсилатися через окремі мережеві з'єднання. Використання одного й того ж з'єднання для обох не підтверджує наявність вразливості.
- **Послідовні URL та параметри:** Намагайтеся використовувати однакові URL та імена параметрів для обох запитів. Сучасні додатки часто маршрутизують запити до конкретних серверів на задньому плані на основі URL та параметрів. Відповідність цим підвищує ймовірність того, що обидва запити обробляються одним і тим же сервером, що є передумовою для успішної атаки.
- **Таймінг та умови гонки:** "Нормальний" запит, призначений для виявлення втручання з боку "атакуючого" запиту, конкурує з іншими одночасними запитами додатка. Тому надсилайте "нормальний" запит відразу після "атакуючого" запиту. Завантажені додатки можуть вимагати кількох спроб для підтвердження вразливості.
- **Виклики балансування навантаження:** Сервери на передньому плані, які виконують функції балансування навантаження, можуть розподіляти запити між різними системами на задньому плані. Якщо "атакуючі" та "нормальні" запити потрапляють на різні системи, атака не буде успішною. Цей аспект балансування навантаження може вимагати кількох спроб для підтвердження вразливості.
- **Непередбачуваний вплив на користувачів:** Якщо ваша атака ненавмисно впливає на запит іншого користувача (не "нормальний" запит, який ви надіслали для виявлення), це вказує на те, що ваша атака вплинула на іншого користувача додатка. Постійне тестування може порушити роботу інших користувачів, що вимагає обережного підходу.
- **Таймінг та умови гонки:** "Нормальний" запит, призначений для виявлення втручання з "атакуючого" запиту, змагається з іншими одночасними запитами додатка. Тому надсилайте "нормальний" запит відразу після "атакуючого" запиту. Завантажені додатки можуть вимагати кількох спроб для остаточного підтвердження вразливості.
- **Виклики балансування навантаження:** Сервери на передньому плані, які виконують функцію балансування навантаження, можуть розподіляти запити між різними системами на задньому плані. Якщо "атакуючі" та "нормальні" запити потрапляють на різні системи, атака не вдасться. Цей аспект балансування навантаження може вимагати кількох спроб для підтвердження вразливості.
- **Непередбачений вплив на користувачів:** Якщо ваша атака ненавмисно впливає на запит іншого користувача (не "нормальний" запит, який ви надіслали для виявлення), це вказує на те, що ваша атака вплинула на іншого користувача додатка. Постійне тестування може порушити роботу інших користувачів, що вимагає обережного підходу.
## Розрізнення артефактів HTTP/1.1 pipelining та справжнього request smuggling
Повторне використання з'єднань (keep-alive) та pipelining можуть легко створювати ілюзії "smuggling" в тестових інструментах, які надсилають кілька запитів на одному сокеті. Навчіться відокремлювати безпечні артефакти на стороні клієнта від справжнього десинхронізації на стороні сервера.
### Чому pipelining створює класичні хибнопозитивні результати
HTTP/1.1 повторно використовує одне TCP/TLS з'єднання та об'єднує запити та відповіді в одному потоці. У pipelining клієнт надсилає кілька запитів один за одним і покладається на відповіді в порядку надходження. Загальним хибнопозитивним результатом є повторна відправка неправильно сформованого навантаження CL.0 двічі на одному з'єднанні:
```
POST / HTTP/1.1
Host: hackxor.net
Content_Length: 47
GET /robots.txt HTTP/1.1
X: Y
```
Відповіді можуть виглядати так:
```
HTTP/1.1 200 OK
Content-Type: text/html
```
```
HTTP/1.1 200 OK
Content-Type: text/plain
User-agent: *
Disallow: /settings
```
Якщо сервер ігнорує неправильно сформований `Content_Length`, немає десинхронізації FE↔BE. При повторному використанні ваш клієнт фактично надіслав цей байтовий потік, який сервер розпізнав як два незалежні запити:
```
POST / HTTP/1.1
Host: hackxor.net
Content_Length: 47
GET /robots.txt HTTP/1.1
X: YPOST / HTTP/1.1
Host: hackxor.net
Content_Length: 47
GET /robots.txt HTTP/1.1
X: Y
```
Impact: жодного. Ви просто десинхронізували свого клієнта з серверним фреймуванням.
> [!TIP]
> Модулі Burp, які залежать від повторного використання/піпелінгу: Turbo Intruder з `requestsPerConnection>1`, Intruder з "HTTP/1 повторне використання з'єднання", Repeater "Відправити групу послідовно (одне з'єднання)" або "Увімкнути повторне використання з'єднання".
### Літмусові тести: піпелінг чи реальна десинхронізація?
1. Вимкніть повторне використання та повторно протестуйте
- У Burp Intruder/Repeater вимкніть повторне використання HTTP/1 та уникайте "Відправити групу послідовно".
- У Turbo Intruder встановіть `requestsPerConnection=1` та `pipeline=False`.
- Якщо поведінка зникне, це, ймовірно, було піпелінгом на стороні клієнта, якщо ви не маєте справу з цільовими системами, заблокованими за з'єднанням/станом, або десинхронізацією на стороні клієнта.
2. Перевірка вкладених відповідей HTTP/2
- Відправте запит HTTP/2. Якщо тіло відповіді містить повну вкладену відповідь HTTP/1, ви довели наявність помилки парсингу/десинхронізації на стороні бекенду, а не чистий артефакт клієнта.
3. Проба часткових запитів для фронтендів, заблокованих за з'єднанням
- Деякі ФЕ повторно використовують з'єднання з бекендом лише якщо клієнт повторно використовує своє. Використовуйте часткові запити, щоб виявити поведінку ФЕ, яка відображає повторне використання клієнта.
- Дивіться PortSwigger "Атаки десинхронізації, що використовують браузер" для техніки, заблокованої за з'єднанням.
4. Проби стану
- Шукайте відмінності між першим і наступними запитами на одному TCP-з'єднанні (маршрутизація/перевірка першого запиту).
- Burp "HTTP Request Smuggler" включає пробу стану з'єднання, яка автоматизує це.
5. Візуалізуйте з'єднання
- Використовуйте розширення Burp "HTTP Hacker", щоб безпосередньо перевіряти конкатенацію та фреймування повідомлень під час експериментів з повторним використанням та частковими запитами.
### Десинхронізація запитів, заблокованих за з'єднанням (вимагає повторного використання)
Деякі фронтенди повторно використовують з'єднання з бекендом лише тоді, коли клієнт повторно використовує своє. Реальна контрабанда існує, але залежить від повторного використання на стороні клієнта. Щоб відрізнити та довести вплив:
- Доведіть помилку на стороні сервера
- Використовуйте перевірку вкладених відповідей HTTP/2, або
- Використовуйте часткові запити, щоб показати, що ФЕ повторно використовує з'єднання з бекендом лише тоді, коли клієнт це робить.
- Показуйте реальний вплив, навіть якщо пряма зловживання сокетом між користувачами заблокована:
- Отруєння кешу: отруюйте спільні кеші через десинхронізацію, щоб відповіді впливали на інших користувачів.
- Внутрішнє розкриття заголовків: відображайте заголовки, інжектовані ФЕ (наприклад, заголовки автентифікації/достовірності) та переходьте до обходу автентифікації.
- Обхід контролю ФЕ: контрабандно пропускайте обмежені шляхи/методи повз фронтенд.
- Зловживання заголовком хоста: комбінуйте з особливостями маршрутизації хоста, щоб перейти до внутрішніх віртуальних хостів.
- Робочий процес оператора
- Відтворіть з контрольованим повторним використанням (Turbo Intruder `requestsPerConnection=2`, або група вкладок Burp Repeater → "Відправити групу послідовно (одне з'єднання)").
- Потім з'єднайте з примітивами отруєння кешу/розкриття заголовків/обходу контролю та продемонструйте вплив між користувачами або авторизацією.
> Дивіться також атаки на стан з'єднання, які тісно пов'язані, але технічно не є контрабандою:
>
>{{#ref}}
>../http-connection-request-smuggling.md
>{{#endref}}
### Обмеження десинхронізації на стороні клієнта
Якщо ви націлені на десинхронізацію, що викликана браузером/на стороні клієнта, зловмисний запит повинен бути відправлений браузером з крос-доменом. Трюки з обфускацією заголовків не спрацюють. Зосередьтеся на примітивах, доступних через навігацію/отримання, а потім переходьте до отруєння кешу, розкриття заголовків або обходу контролю фронтенду, де компоненти нижнього рівня відображають або кешують відповіді.
Для фону та кінцевих робочих процесів:
{{#ref}}
-browser-http-request-smuggling.md
{{#endref}}
### Інструменти для допомоги у прийнятті рішень
- HTTP Hacker (Burp BApp Store): відкриває низькорівневу поведінку HTTP та конкатенацію сокетів.
- "Контрабанда чи піпелінг?" Дія користувача Burp Repeater: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
- Turbo Intruder: точний контроль над повторним використанням з'єднання через `requestsPerConnection`.
- Burp HTTP Request Smuggler: включає пробу стану з'єднання для виявлення маршрутизації/перевірки першого запиту.
> [!NOTE]
> Вважайте ефекти лише з повторним використанням незначними, якщо ви не можете довести десинхронізацію на стороні сервера та прикріпити конкретний вплив (артефакт отруєного кешу, розкритий внутрішній заголовок, що дозволяє обхід привілеїв, обхід контролю ФЕ тощо).
## Зловживання HTTP Request Smuggling
### Обхід безпеки на передньому плані через HTTP Request Smuggling
### Обхід безпеки фронтенду через HTTP Request Smuggling
Іноді проксі-сервери на передньому плані впроваджують заходи безпеки, перевіряючи вхідні запити. Однак ці заходи можна обійти, експлуатуючи HTTP Request Smuggling, що дозволяє несанкціонований доступ до обмежених кінцевих точок. Наприклад, доступ до `/admin` може бути заборонений ззовні, а проксі на передньому плані активно блокує такі спроби. Проте цей проксі може не перевіряти вбудовані запити в межах прихованого HTTP запиту, залишаючи лазівку для обходу цих обмежень.
Іноді фронтенд-проксі впроваджують заходи безпеки, ретельно перевіряючи вхідні запити. Однак ці заходи можуть бути обійдені шляхом експлуатації HTTP Request Smuggling, що дозволяє несанкціонований доступ до обмежених кінцевих точок. Наприклад, доступ до `/admin` може бути заборонений зовні, при цьому фронтенд-проксі активно блокує такі спроби. Проте цей проксі може не перевіряти вбудовані запити в межах контрабандного HTTP-запиту, залишаючи лазівку для обходу цих обмежень.
Розгляньте наступні приклади, які ілюструють, як HTTP Request Smuggling може бути використано для обходу контролю безпеки на передньому плані, зокрема націлюючись на шлях `/admin`, який зазвичай охороняється проксі на передньому плані:
Розгляньте наступні приклади, які ілюструють, як HTTP Request Smuggling може бути використано для обходу контролю безпеки фронтенду, зокрема націлюючись на шлях `/admin`, який зазвичай охороняється фронтенд-проксі:
**Приклад CL.TE**
**CL.TE Приклад**
```
POST / HTTP/1.1
Host: [redacted].web-security-academy.net
@ -320,13 +427,13 @@ a=x
0
```
Навпаки, в атаці TE.CL початковий `POST` запит використовує `Transfer-Encoding: chunked`, а наступний вбудований запит обробляється на основі заголовка `Content-Length`. Подібно до атаки CL.TE, фронтальний проксі ігнорує підслуханий `GET /admin` запит, ненавмисно надаючи доступ до обмеженого `/admin` шляху.
Навпаки, в атаці TE.CL початковий `POST` запит використовує `Transfer-Encoding: chunked`, а наступний вбудований запит обробляється на основі заголовка `Content-Length`. Подібно до атаки CL.TE, фронтальний проксі ігнорує контрабандний запит `GET /admin`, ненавмисно надаючи доступ до обмеженого шляху `/admin`.
### Виявлення переписування запитів фронтального проксі <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
### Виявлення переписування запитів фронтального рівня <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
Додатки часто використовують **фронтальний сервер** для модифікації вхідних запитів перед їх передачею на бекенд-сервер. Типова модифікація включає додавання заголовків, таких як `X-Forwarded-For: <IP клієнта>`, для передачі IP клієнта на бекенд. Розуміння цих модифікацій може бути вирішальним, оскільки це може виявити способи **обійти захист** або **виявити приховану інформацію чи кінцеві точки**.
Додатки часто використовують **фронтальний сервер** для модифікації вхідних запитів перед їх передачею на сервер заднього плану. Типова модифікація включає додавання заголовків, таких як `X-Forwarded-For: <IP клієнта>`, для передачі IP клієнта на сервер заднього плану. Розуміння цих модифікацій може бути вирішальним, оскільки це може виявити способи **обійти захист** або **виявити приховану інформацію чи кінцеві точки**.
Щоб дослідити, як проксі змінює запит, знайдіть POST параметр, який бекенд відображає у відповіді. Потім створіть запит, використовуючи цей параметр останнім, подібно до наступного:
Щоб дослідити, як проксі змінює запит, знайдіть параметр POST, який сервер заднього плану відображає у відповіді. Потім створіть запит, використовуючи цей параметр останнім, подібно до наступного:
```
POST / HTTP/1.1
Host: vulnerable-website.com
@ -345,9 +452,9 @@ search=
```
У цій структурі наступні компоненти запиту додаються після `search=`, що є параметром, відображеним у відповіді. Це відображення відкриє заголовки наступного запиту.
Важливо узгодити заголовок `Content-Length` вкладеного запиту з фактичною довжиною вмісту. Рекомендується починати з невеликого значення і поступово збільшувати, оскільки занадто низьке значення обрізає відображені дані, а занадто високе може призвести до помилки запиту.
Важливо узгодити заголовок `Content-Length` вкладеного запиту з фактичною довжиною вмісту. Рекомендується починати з невеликого значення і поступово збільшувати його, оскільки занадто низьке значення обрізає відображені дані, а занадто високе може призвести до помилки запиту.
Ця техніка також застосовна в контексті вразливості TE.CL, але запит повинен закінчуватися `search=\r\n0`. Незалежно від символів нового рядка, значення будуть додаватися до параметра пошуку.
Ця техніка також застосовна в контексті вразливості TE.CL, але запит повинен закінчуватися на `search=\r\n0`. Незалежно від символів нового рядка, значення будуть додаватися до параметра пошуку.
Цей метод в основному служить для розуміння модифікацій запиту, зроблених проксі-сервером фронтенду, фактично виконуючи самостійне розслідування.
@ -377,7 +484,7 @@ csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40ema
```
У цьому сценарії **параметр коментаря** призначений для зберігання вмісту в секції коментарів поста на публічно доступній сторінці. Відповідно, вміст наступного запиту з'явиться як коментар.
Однак у цього методу є обмеження. Як правило, він захоплює дані лише до роздільника параметра, використаного в контрабандному запиті. Для URL-кодованих форм, цей роздільник - це символ `&`. Це означає, що захоплений вміст з запиту жертви зупиниться на першому `&`, який може бути навіть частиною рядка запиту.
Однак у цього методу є обмеження. Як правило, він захоплює дані лише до роздільника параметра, використаного в контрабандному запиті. Для URL-кодованих форм, цей роздільник - це символ `&`. Це означає, що захоплений вміст з запиту жертви зупиниться на першому `&`, який може бути частиною рядка запиту.
Крім того, варто зазначити, що цей підхід також є життєздатним з вразливістю TE.CL. У таких випадках запит має закінчуватися на `search=\r\n0`. Незалежно від символів нового рядка, значення будуть додані до параметра пошуку.
@ -385,8 +492,8 @@ csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40ema
HTTP Request Smuggling можна використовувати для експлуатації веб-сторінок, вразливих до **Reflected XSS**, що пропонує значні переваги:
- Взаємодія з цільовими користувачами **не потрібна**.
- Дозволяє експлуатувати XSS у частинах запиту, які **зазвичай недоступні**, таких як заголовки HTTP-запиту.
- Взаємодія з цільовими користувачами **необхідна**.
- Дозволяє експлуатувати XSS у частинах запиту, які **зазвичай недоступні**, такі як заголовки HTTP-запиту.
У сценаріях, коли веб-сайт вразливий до Reflected XSS через заголовок User-Agent, наступний payload демонструє, як експлуатувати цю вразливість:
```
@ -413,18 +520,18 @@ A=
1. Ініціювання `POST` запиту, що виглядає типовим, з заголовком `Transfer-Encoding: chunked`, щоб вказати на початок контрабанди.
2. Наступним є `0`, що позначає кінець тіла повідомлення з частинами.
3. Потім вводиться контрабандний `GET` запит, де заголовок `User-Agent` інжектується скриптом, `<script>alert(1)</script>`, що викликає XSS, коли сервер обробляє цей наступний запит.
3. Потім вводиться контрабандний `GET` запит, де заголовок `User-Agent` інжектується зі скриптом, `<script>alert(1)</script>`, що викликає XSS, коли сервер обробляє цей наступний запит.
Маніпулюючи `User-Agent` через контрабанду, payload обходить звичайні обмеження запитів, таким чином експлуатуючи вразливість Reflected XSS нестандартним, але ефективним способом.
#### HTTP/0.9
> [!CAUTION]
> У випадку, якщо вміст користувача відображається у відповіді з **`Content-type`** таким як **`text/plain`**, що запобігає виконанню XSS. Якщо сервер підтримує **HTTP/0.9, це може дозволити обійти це**!
> У разі, якщо вміст користувача відображається у відповіді з **`Content-type`** таким як **`text/plain`**, що запобігає виконанню XSS. Якщо сервер підтримує **HTTP/0.9, можливо, це можна обійти**!
Версія HTTP/0.9 була попередньою до 1.0 і використовує лише **GET** дієслова та **не** відповідає з **заголовками**, лише тілом.
У [**цьому описі**](https://mizu.re/post/twisty-python) це було зловжито з контрабандою запиту та **вразливим кінцевим пунктом, який відповідає на введення користувача**, щоб контрабандно надіслати запит з HTTP/0.9. Параметр, який буде відображено у відповіді, містив **фальшиву HTTP/1.1 відповідь (з заголовками та тілом)**, тому відповідь міститиме дійсний виконуваний JS код з `Content-Type` `text/html`.
У [**цьому описі**](https://mizu.re/post/twisty-python) це було зловжито з контрабандою запиту та **вразливим кінцевим пунктом, який відповість з вхідними даними користувача** для контрабанди запиту з HTTP/0.9. Параметр, який буде відображено у відповіді, містив **підроблену HTTP/1.1 відповідь (з заголовками та тілом)**, тому відповідь міститиме дійсний виконуваний JS код з `Content-Type` `text/html`.
### Експлуатація перенаправлень на сайті з допомогою HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
@ -472,9 +579,9 @@ Location: https://attacker-website.com/home/
Раніше ми спостерігали, як відповіді сервера можуть бути змінені, щоб повернути помилку 404 (див. [Основні приклади](#basic-examples)). Аналогічно, можливо обманути сервер, щоб він надав контент `/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`.
Ця техніка стає особливо потужною, якщо виявлено **вразливість Open Redirect** або якщо є **внутрішнє перенаправлення на відкритий редирект**. Такі вразливості можуть бути використані для заміни кешованого контенту `/static/include.js` на скрипт під контролем зловмисника, що фактично дозволяє здійснити масовану атаку Cross-Site Scripting (XSS) проти всіх клієнтів, які запитують оновлений `/static/include.js`.
Нижче наведено ілюстрацію використання **отруєння кешу в поєднанні з перенаправленням на сайті до відкритого перенаправлення**. Мета полягає в тому, щоб змінити кешований контент `/static/include.js`, щоб надати JavaScript-код, контрольований зловмисником:
Нижче наведено ілюстрацію використання **отруєння кешу в поєднанні з внутрішнім перенаправленням на відкритий редирект**. Мета полягає в тому, щоб змінити кешований контент `/static/include.js`, щоб надати JavaScript-код, контрольований зловмисником:
```
POST / HTTP/1.1
Host: vulnerable.net
@ -494,7 +601,7 @@ x=1
```
Зверніть увагу на вбудований запит, що націлений на `/post/next?postId=3`. Цей запит буде перенаправлено на `/post?postId=4`, використовуючи **значення заголовка Host** для визначення домену. Змінивши **заголовок Host**, зловмисник може перенаправити запит на свій домен (**внутрішнє перенаправлення на відкритий редирект**).
Після успішного **отруєння сокетів** слід ініціювати **GET запит** на `/static/include.js`. Цей запит буде забруднений попереднім запитом **внутрішнього перенаправлення на відкритий редирект** і отримає вміст скрипта, контрольованого зловмисником.
Після успішного **отруєння сокета** слід ініціювати **GET запит** на `/static/include.js`. Цей запит буде забруднений попереднім запитом **внутрішнього перенаправлення на відкритий редирект** і отримає вміст скрипта, контрольованого зловмисником.
В подальшому будь-який запит на `/static/include.js` буде подавати кешований вміст скрипта зловмисника, ефективно запускаючи широкий XSS-атаку.
@ -516,11 +623,11 @@ x=1
`GET /private/messages HTTP/1.1`\
`Foo: X`
```
Якщо цей підроблений запит отруює кеш-елемент, призначений для статичного контенту (наприклад, `/someimage.png`), чутливі дані жертви з `/private/messages` можуть бути кешовані під кеш-елементом статичного контенту. Внаслідок цього, зловмисник потенційно може отримати ці кешовані чутливі дані.
Якщо цей підроблений запит отруює кеш-енцію, призначену для статичного контенту (наприклад, `/someimage.png`), чутливі дані жертви з `/private/messages` можуть бути кешовані під кеш-енцією статичного контенту. Внаслідок цього, зловмисник потенційно може отримати ці кешовані чутливі дані.
### Зловживання TRACE через HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
[**У цьому пості**](https://portswigger.net/research/trace-desync-attack) пропонується, що якщо сервер має активований метод TRACE, його можна зловживати за допомогою HTTP Request Smuggling. Це пов'язано з тим, що цей метод відображатиме будь-який заголовок, надісланий на сервер, як частину тіла відповіді. Наприклад:
[**У цьому пості**](https://portswigger.net/research/trace-desync-attack) пропонується, що якщо сервер має метод TRACE увімкненим, його можна зловживати за допомогою HTTP Request Smuggling. Це пов'язано з тим, що цей метод відображатиме будь-який заголовок, надісланий на сервер, як частину тіла відповіді. Наприклад:
```
TRACE / HTTP/1.1
Host: example.com
@ -541,9 +648,9 @@ X-Forwarded-For: xxx.xxx.xxx.xxx
Оскільки відповідь на HEAD міститиме заголовок `Content-Length`, **відповідь на запит TRACE буде розглядатися як тіло відповіді на HEAD, отже, відображаючи довільні дані** у відповіді.\
Ця відповідь буде надіслана до наступного запиту через з'єднання, тому це може бути **використано, наприклад, у кешованому JS файлі для впровадження довільного JS коду**.
### Зловживання TRACE через HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
### Зловживання TRACE через розділення HTTP-відповідей <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
Продовжуючи слідувати [**цьому посту**](https://portswigger.net/research/trace-desync-attack), пропонується ще один спосіб зловживання методом TRACE. Як зазначено, зловживаючи запитом HEAD і запитом TRACE, можна **контролювати деякі відображені дані** у відповіді на запит HEAD. Довжина тіла запиту HEAD в основному вказується в заголовку Content-Length і формується відповіддю на запит TRACE.
Продовжуючи слідкувати за [**цим постом**](https://portswigger.net/research/trace-desync-attack), пропонується інший спосіб зловживання методом TRACE. Як зазначено, зловживаючи запитом HEAD і запитом TRACE, можна **контролювати деякі відображені дані** у відповіді на запит HEAD. Довжина тіла запиту HEAD в основному вказується в заголовку Content-Length і формується відповіддю на запит TRACE.
Отже, нова ідея полягає в тому, що, знаючи цей Content-Length і дані, надані у відповіді TRACE, можна зробити так, щоб відповідь TRACE містила дійсну HTTP-відповідь після останнього байта Content-Length, що дозволяє зловмиснику повністю контролювати запит до наступної відповіді (яка може бути використана для виконання отруєння кешу).
@ -566,7 +673,7 @@ Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>
```
Згенерує ці ці responses (зверніть увагу, як відповідь HEAD має Content-Length, що робить відповідь TRACE частиною тіла HEAD, і як тільки закінчується Content-Length HEAD, дійсна HTTP відповідь проникає):
Згенерує ці ці responses (зверніть увагу, що відповідь HEAD має Content-Length, що робить відповідь TRACE частиною тіла HEAD, і як тільки закінчується Content-Length HEAD, дійсна HTTP відповідь проникає):
```
HTTP/1.1 200 OK
Content-Type: text/html
@ -698,12 +805,14 @@ table.add(req)
```
## Інструменти
- HTTP Hacker (Burp BApp Store) – візуалізуйте конкатенацію/фреймування та низькорівнева HTTP поведінка
- https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Custom Action "Smuggling or pipelining?"
- [https://github.com/anshumanpattnaik/http-request-smuggling](https://github.com/anshumanpattnaik/http-request-smuggling)
- [https://github.com/PortSwigger/http-request-smuggler](https://github.com/PortSwigger/http-request-smuggler)
- [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py)
- [https://github.com/defparam/smuggler](https://github.com/defparam/smuggler)
- [https://github.com/Moopinger/smugglefuzz](https://github.com/Moopinger/smugglefuzz)
- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Цей інструмент є HTTP Fuzzer на основі граматики, корисний для виявлення дивних розбіжностей у запитах на контрабанду.
- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Цей інструмент є граматично-орієнтованим HTTP Fuzzer, корисним для виявлення дивних розбіжностей у запитах на контрабанду.
## Посилання
@ -716,6 +825,10 @@ table.add(req)
- [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/)
- [https://portswigger.net/research/trace-desync-attack](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/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
- Будьте обережні з хибнопозитивними результатами: як відрізнити HTTP фреймування від контрабанди запитів – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
- [https://http1mustdie.com/](https://http1mustdie.com/)
- Атаки Desync, що використовують браузер – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
- PortSwigger Academy – десинхронізація на стороні клієнта – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
{{#include ../../banners/hacktricks-training.md}}

18
src/pentesting-web/http-request-smuggling/browser-http-request-smuggling.md
View File

@ -2,6 +2,22 @@
{{#include ../../banners/hacktricks-training.md}}
**Перевірте пост [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)**
Browser-powered desync (також відомий як client-side request smuggling) використовує браузер жертви для додавання неправильно сформованого запиту в чергу на спільному з'єднанні, так що наступні запити обробляються асинхронно компонентом нижнього рівня. На відміну від класичного FE↔BE smuggling, корисні навантаження обмежені тим, що браузер може легально відправити між доменами.
Ключові обмеження та поради
- Використовуйте лише заголовки та синтаксис, які браузер може відправити через навігацію, fetch або відправку форм. Обфускації заголовків (LWS трюки, дублювання TE, недійсний CL) зазвичай не будуть відправлені.
- Орієнтуйтеся на кінцеві точки та проміжні елементи, які відображають введення або кешують відповіді. Корисні наслідки включають отруєння кешу, витік заголовків, інжектованих на фронт-енді, або обходження контролю шляхів/методів на фронт-енді.
- Повторне використання має значення: налаштуйте створений запит так, щоб він ділив те саме HTTP/1.1 або H2 з'єднання з запитом жертви високої цінності. Поведінка, що блокує з'єднання/стан, посилює вплив.
- Віддавайте перевагу примітивам, які не вимагають спеціальних заголовків: плутанина шляхів, ін'єкція рядка запиту та формування тіла через POST з кодуванням форм.
- Перевіряйте справжній серверний desync проти простих артефактів конвеєризації, повторно тестуючи без повторного використання або використовуючи перевірку вкладених відповідей HTTP/2.
Для технік від початку до кінця та PoC дивіться:
- PortSwigger Research – Browser‑Powered Desync Attacks: https://portswigger.net/research/browser-powered-desync-attacks
- PortSwigger Academy – client‑side desync: https://portswigger.net/web-security/request-smuggling/browser/client-side-desync
## References
- [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
- [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
- Distinguishing pipelining vs smuggling (background on reuse false-positives): https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling
{{#include ../../banners/hacktricks-training.md}}