Translated ['src/pentesting-web/http-connection-request-smuggling.md'] t

This commit is contained in:
Translator 2025-07-12 22:07:53 +00:00
parent 8000ee33ef
commit 49e30fe598

View File

@ -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}}