mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/http-connection-request-smuggling.md'] t
This commit is contained in:
parent
8000ee33ef
commit
49e30fe598
@ -2,33 +2,82 @@
|
|||||||
|
|
||||||
{{#include ../banners/hacktricks-training.md}}
|
{{#include ../banners/hacktricks-training.md}}
|
||||||
|
|
||||||
**Це резюме посту** [**https://portswigger.net/research/browser-powered-desync-attacks**](https://portswigger.net/research/browser-powered-desync-attacks)
|
**Ця сторінка узагальнює, розширює та оновлює** основоположне дослідження PortSwigger про [Browser-Powered Desync Attacks](https://portswigger.net/research/browser-powered-desync-attacks) та подальшу роботу з зловживанням станом з'єднання HTTP/2. Вона зосереджується на вразливостях, де **походження визначається лише один раз на з'єднанні TCP/TLS**, що дозволяє зловмиснику "переправляти" запити до іншого внутрішнього хоста після встановлення каналу.
|
||||||
|
|
||||||
## Атаки на стан з'єднання <a href="#state" id="state"></a>
|
## Connection-State Attacks <a href="#state" id="state"></a>
|
||||||
|
|
||||||
### Валідація першого запиту
|
### First-request Validation
|
||||||
|
|
||||||
При маршрутизації запитів зворотні проксі можуть покладатися на **заголовок Host**, щоб визначити сервер на задньому плані, часто спираючись на білий список хостів, яким дозволено доступ. Однак у деяких проксі існує вразливість, де білий список застосовується лише до початкового запиту в з'єднанні. Внаслідок цього зловмисники можуть скористатися цим, спочатку зробивши запит до дозволеного хоста, а потім запитуючи внутрішній сайт через те ж з'єднання:
|
При маршрутизації запитів зворотні проксі можуть покладатися на заголовок **Host** (або **:authority** в HTTP/2), щоб визначити сервер призначення, часто спираючись на білий список хостів, яким дозволено доступ. Однак існує вразливість у ряді проксі, де білий список **застосовується лише до самого першого запиту в з'єднанні**. Внаслідок цього зловмисники можуть отримати доступ до внутрішніх віртуальних хостів, спочатку надіславши дозволений запит, а потім повторно використовуючи те ж саме підключення:
|
||||||
```
|
```http
|
||||||
GET / HTTP/1.1
|
GET / HTTP/1.1
|
||||||
Host: [allowed-external-host]
|
Host: allowed-external-host.example
|
||||||
|
|
||||||
GET / HTTP/1.1
|
GET /admin HTTP/1.1
|
||||||
Host: [internal-host]
|
Host: internal-only.example
|
||||||
```
|
```
|
||||||
### First-request Routing
|
### First-request Routing
|
||||||
|
|
||||||
В деяких конфігураціях, фронтальний сервер може використовувати **заголовок Host першого запиту** для визначення маршрутизації на бекенді для цього запиту, а потім постійно маршрутизувати всі наступні запити з того ж клієнтського з'єднання до того ж бекенд-з'єднання. Це можна продемонструвати як:
|
Багато HTTP/1.1 зворотних проксі відображають вихідне з'єднання до пулу бекенду **виключно на основі першого запиту, який вони пересилають**. Усі наступні запити, надіслані через той же фронтальний сокет, безшумно повторно використовуються, незалежно від їх заголовка Host. Це можна поєднати з класичними [атаками на заголовок Host](https://portswigger.net/web-security/host-header), такими як отруєння скидання пароля або [отруєння веб-кешу](https://portswigger.net/web-security/web-cache-poisoning), щоб отримати доступ, подібний до SSRF, до інших віртуальних хостів:
|
||||||
```
|
```http
|
||||||
GET / HTTP/1.1
|
GET / HTTP/1.1
|
||||||
Host: example.com
|
Host: public.example
|
||||||
|
|
||||||
POST /pwreset HTTP/1.1
|
POST /pwreset HTTP/1.1
|
||||||
Host: psres.net
|
Host: private.internal
|
||||||
```
|
```
|
||||||
Цю проблему можна потенційно поєднати з [атаками на заголовок Host](https://portswigger.net/web-security/host-header), такими як отруєння скидання пароля або [отруєння веб-кешу](https://portswigger.net/web-security/web-cache-poisoning), щоб експлуатувати інші вразливості або отримати несанкціонований доступ до додаткових віртуальних хостів.
|
> [!TIP]
|
||||||
|
> У Burp Suite Professional ≥2022.10 ви можете увімкнути **HTTP Request Smuggler → Connection-state probe** для автоматичного виявлення цих вразливостей.
|
||||||
|
|
||||||
> [!NOTE]
|
---
|
||||||
> Для виявлення цих вразливостей можна використовувати функцію 'connection-state probe' у HTTP Request Smuggler.
|
|
||||||
|
## НОВЕ у 2023-2025 – Зловживання з'єднаннями HTTP/2/3
|
||||||
|
|
||||||
|
Сучасні браузери регулярно **об'єднують** запити HTTP/2 та HTTP/3 в одне TLS-з'єднання, коли сертифікат, протокол ALPN та IP-адреса збігаються. Якщо фронтенд авторизує лише перший запит, кожен наступний об'єднаний запит успадковує цю авторизацію – **навіть якщо змінюється Host/:authority**.
|
||||||
|
|
||||||
|
### Сценар експлуатації
|
||||||
|
1. Зловмисник контролює `evil.com`, який розв'язується до того ж краєвого вузла CDN, що й цільовий `internal.company`.
|
||||||
|
2. Браузер жертви вже має відкрите HTTP/2 з'єднання з `evil.com`.
|
||||||
|
3. Зловмисник вбудовує прихований `<img src="https://internal.company/…">` на свою сторінку.
|
||||||
|
4. Оскільки параметри з'єднання збігаються, браузер повторно використовує **існуюче** TLS-з'єднання та мультиплексує запит для `internal.company`.
|
||||||
|
5. Якщо CDN/маршрутизатор лише перевіряв перший запит, внутрішній хост стає доступним.
|
||||||
|
|
||||||
|
PoCs для Chrome/Edge/Firefox доступні в доповіді Джеймса Кеттла *“HTTP/2: The Sequel is Always Worse”* (Black Hat USA 2023).
|
||||||
|
|
||||||
|
### Інструменти
|
||||||
|
* **Burp Suite 2023.12** представив експериментальну точку вставки **HTTP/2 Smuggler**, яка автоматично намагається об'єднувати та використовувати техніки TE/CL.
|
||||||
|
* **smuggleFuzz** (https://github.com/microsoft/smugglefuzz) – Фреймворк на Python, випущений у 2024 році для брутфорсу векторів десинхронізації фронтенду/бекенду через HTTP/2 та HTTP/3, включаючи перестановки стану з'єднання.
|
||||||
|
|
||||||
|
### Заходи пом'якшення
|
||||||
|
* Завжди **повторно перевіряйте Host/:authority на кожному запиті**, а не лише під час створення з'єднання.
|
||||||
|
* Вимкніть або строго обмежте **об'єднання за походженням** на шарах CDN/балансувальника навантаження (наприклад, `http2_origin_cn` вимкнено в NGINX).
|
||||||
|
* Використовуйте окремі сертифікати або IP-адреси для внутрішніх та зовнішніх імен хостів, щоб браузер не міг легально їх об'єднувати.
|
||||||
|
* Віддавайте перевагу **connection: close** або `proxy_next_upstream` після кожного запиту, де це можливо.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Реальні випадки (2022-2025)
|
||||||
|
|
||||||
|
| Рік | Компонент | CVE | Примітки |
|
||||||
|
|------|-----------|-----|-------|
|
||||||
|
| 2022 | AWS Application Load Balancer | – | Заголовок Host перевірявся лише на першому запиті; виправлено шляхом патчування правил двигуна (розкрито SecurityLabs). |
|
||||||
|
| 2023 | Apache Traffic Server < 9.2.2 | CVE-2023-39852 | Дозволяв зловживання запитами через повторне використання з'єднання HTTP/2, коли було встановлено `CONFIG proxy.config.http.parent_proxy_routing_enable`. |
|
||||||
|
| 2024 | Envoy Proxy < 1.29.0 | CVE-2024-2470 | Неправильна перевірка :authority після першого потоку дозволила зловживання запитами між орендарями в спільних мережах. |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Чек-лист для виявлення
|
||||||
|
|
||||||
|
1. Надішліть два запити в **одному** TCP/TLS з'єднанні з різними заголовками Host або :authority.
|
||||||
|
2. Спостерігайте, чи другий відповідь походить з першого хоста (безпечний) або з другого хоста (вразливий).
|
||||||
|
3. У Burp: `Repeat → keep-alive → Send → Follow`.
|
||||||
|
4. При тестуванні HTTP/2 відкрийте **окремий** потік (ID 1) для безпечного хоста, потім мультиплексуйте другий потік (ID 3) до внутрішнього хоста та шукайте відповідь.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Посилання
|
||||||
|
|
||||||
|
* PortSwigger Research – *HTTP/2: The Sequel is Always Worse* (Black Hat USA 2023)
|
||||||
|
* Envoy Security Advisory CVE-2024-2470 – Неправильна перевірка авторитету
|
||||||
|
|
||||||
{{#include ../banners/hacktricks-training.md}}
|
{{#include ../banners/hacktricks-training.md}}
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user