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:
Translator
parent
f27c803114
commit
feb7c4901b
@ -2,33 +2,82 @@
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
**To jest podsumowanie posta** [**https://portswigger.net/research/browser-powered-desync-attacks**](https://portswigger.net/research/browser-powered-desync-attacks)
|
||||
**Ta strona podsumowuje, rozszerza i aktualizuje** przełomowe badania PortSwigger na temat [Browser-Powered Desync Attacks](https://portswigger.net/research/browser-powered-desync-attacks) oraz późniejsze prace dotyczące nadużyć stanu połączenia HTTP/2. Skupia się na lukach, w których **pochodzenie jest ustalane tylko raz na połączenie TCP/TLS**, co umożliwia atakującemu „przemycenie” żądań do innego wewnętrznego hosta po nawiązaniu kanału.
|
||||
|
||||
## Ataki na stan połączenia <a href="#state" id="state"></a>
|
||||
|
||||
### Walidacja pierwszego żądania
|
||||
|
||||
Podczas routingu żądań, serwery proxy odwrotne mogą polegać na **nagłówku Host**, aby określić docelowy serwer zaplecza, często opierając się na białej liście hostów, które mają dostęp. Jednak w niektórych proxy istnieje luka, w której biała lista jest egzekwowana tylko w przypadku początkowego żądania w połączeniu. W związku z tym, atakujący mogą to wykorzystać, najpierw wysyłając żądanie do dozwolonego hosta, a następnie żądając dostępu do wewnętrznej strony przez to samo połączenie:
|
||||
```
|
||||
Podczas routingu żądań, serwery proxy odwrotne mogą polegać na nagłówku **Host** (lub **:authority** w HTTP/2), aby określić docelowy serwer zaplecza, często opierając się na białej liście hostów, które mają dostęp. Jednak w wielu proxy istnieje luka, w której biała lista jest **egzekwowana tylko przy bardzo pierwszym żądaniu w połączeniu**. W konsekwencji atakujący mogą uzyskać dostęp do wewnętrznych wirtualnych hostów, najpierw wysyłając dozwolone żądanie, a następnie ponownie wykorzystując to samo podstawowe połączenie:
|
||||
```http
|
||||
GET / HTTP/1.1
|
||||
Host: [allowed-external-host]
|
||||
Host: allowed-external-host.example
|
||||
|
||||
GET / HTTP/1.1
|
||||
Host: [internal-host]
|
||||
GET /admin HTTP/1.1
|
||||
Host: internal-only.example
|
||||
```
|
||||
### Routing pierwszego żądania
|
||||
|
||||
W niektórych konfiguracjach serwer front-end może używać **nagłówka Host pierwszego żądania** do określenia routingu back-end dla tego żądania, a następnie trwale kierować wszystkie kolejne żądania z tego samego połączenia klienta do tego samego połączenia back-end. Można to zademonstrować jako:
|
||||
```
|
||||
Wiele odwrotnych proxy HTTP/1.1 mapuje połączenie wychodzące do zaplecza **wyłącznie na podstawie pierwszego żądania, które przekazują**. Wszystkie kolejne żądania wysyłane przez ten sam front-end socket są cicho ponownie używane, niezależnie od ich nagłówka Host. Można to połączyć z klasycznymi [atakami na nagłówek Host](https://portswigger.net/web-security/host-header), takimi jak złośliwe resetowanie hasła lub [zatrucie pamięci podręcznej](https://portswigger.net/web-security/web-cache-poisoning), aby uzyskać dostęp podobny do SSRF do innych wirtualnych hostów:
|
||||
```http
|
||||
GET / HTTP/1.1
|
||||
Host: example.com
|
||||
Host: public.example
|
||||
|
||||
POST /pwreset HTTP/1.1
|
||||
Host: psres.net
|
||||
Host: private.internal
|
||||
```
|
||||
Ten problem może być potencjalnie połączony z [atakami na nagłówki Host](https://portswigger.net/web-security/host-header), takimi jak trucie resetu hasła lub [trucie pamięci podręcznej web](https://portswigger.net/web-security/web-cache-poisoning), aby wykorzystać inne luki lub uzyskać nieautoryzowany dostęp do dodatkowych wirtualnych hostów.
|
||||
> [!TIP]
|
||||
> W Burp Suite Professional ≥2022.10 możesz włączyć **HTTP Request Smuggler → Connection-state probe**, aby automatycznie wykrywać te słabości.
|
||||
|
||||
> [!NOTE]
|
||||
> Aby zidentyfikować te luki, można wykorzystać funkcję 'connection-state probe' w HTTP Request Smuggler.
|
||||
---
|
||||
|
||||
## NOWOŚĆ w 2023-2025 – Nadużycie koalescencji połączeń HTTP/2/3
|
||||
|
||||
Nowoczesne przeglądarki rutynowo **koalescują** żądania HTTP/2 i HTTP/3 na jednym połączeniu TLS, gdy certyfikat, protokół ALPN i adres IP są zgodne. Jeśli front-end autoryzuje tylko pierwsze żądanie, każde kolejne koalescowane żądanie dziedziczy tę autoryzację – **nawet jeśli Host/:authority się zmienia**.
|
||||
|
||||
### Scenariusz wykorzystania
|
||||
1. Atakujący kontroluje `evil.com`, które rozwiązuje się do tego samego węzła krawędzi CDN co cel `internal.company`.
|
||||
2. Przeglądarka ofiary ma już otwarte połączenie HTTP/2 do `evil.com`.
|
||||
3. Atakujący osadza ukryty `<img src="https://internal.company/…">` na swojej stronie.
|
||||
4. Ponieważ parametry połączenia są zgodne, przeglądarka ponownie wykorzystuje **istniejące** połączenie TLS i multiplexuje żądanie do `internal.company`.
|
||||
5. Jeśli CDN/router tylko walidował pierwsze żądanie, wewnętrzny host jest ujawniony.
|
||||
|
||||
PoC dla Chrome/Edge/Firefox są dostępne w wystąpieniu Jamesa Kettle’a *“HTTP/2: The Sequel is Always Worse”* (Black Hat USA 2023).
|
||||
|
||||
### Narzędzia
|
||||
* **Burp Suite 2023.12** wprowadził eksperymentalny punkt wstawiania **HTTP/2 Smuggler**, który automatycznie próbuje koalescencji i technik TE/CL.
|
||||
* **smuggleFuzz** (https://github.com/microsoft/smugglefuzz) – Framework Pythona wydany w 2024 roku do brutalnego wymuszania wektorów desynchronizacji front-end/back-end przez HTTP/2 i HTTP/3, w tym permutacji stanu połączenia.
|
||||
|
||||
### Środki zaradcze
|
||||
* Zawsze **ponownie waliduj Host/:authority przy każdym żądaniu**, a nie tylko przy tworzeniu połączenia.
|
||||
* Wyłącz lub ściśle ogranicz **koalescencję pochodzenia** na warstwach CDN/ładowania balansu (np. `http2_origin_cn` wyłączone w NGINX).
|
||||
* Wdrażaj oddzielne certyfikaty lub adresy IP dla wewnętrznych i zewnętrznych nazw hostów, aby przeglądarka nie mogła ich legalnie koalescować.
|
||||
* Preferuj **connection: close** lub `proxy_next_upstream` po każdym żądaniu, gdzie to możliwe.
|
||||
|
||||
---
|
||||
|
||||
## Przykłady z życia (2022-2025)
|
||||
|
||||
| Rok | Komponent | CVE | Uwagi |
|
||||
|------|-----------|-----|-------|
|
||||
| 2022 | AWS Application Load Balancer | – | Nagłówek Host był walidowany tylko przy pierwszym żądaniu; naprawione przez poprawki silnika reguł (ujawnione przez SecurityLabs). |
|
||||
| 2023 | Apache Traffic Server < 9.2.2 | CVE-2023-39852 | Umożliwił smuggling żądań przez ponowne użycie połączenia HTTP/2, gdy `CONFIG proxy.config.http.parent_proxy_routing_enable` było ustawione. |
|
||||
| 2024 | Envoy Proxy < 1.29.0 | CVE-2024-2470 | Niewłaściwa walidacja :authority po pierwszym strumieniu umożliwiła smuggling żądań między najemcami w współdzielonych sieciach. |
|
||||
|
||||
---
|
||||
|
||||
## Arkusz wykrywania
|
||||
|
||||
1. Wyślij dwa żądania w **tym samym** połączeniu TCP/TLS z różnymi nagłówkami Host lub :authority.
|
||||
2. Obserwuj, czy druga odpowiedź pochodzi z pierwszego hosta (bezpieczne) czy drugiego hosta (wrażliwe).
|
||||
3. W Burp: `Repeat → keep-alive → Send → Follow`.
|
||||
4. Podczas testowania HTTP/2 otwórz **dedykowany** strumień (ID 1) dla nieszkodliwego hosta, a następnie multiplexuj drugi strumień (ID 3) do wewnętrznego hosta i szukaj odpowiedzi.
|
||||
|
||||
---
|
||||
|
||||
## Odniesienia
|
||||
|
||||
* PortSwigger Research – *HTTP/2: The Sequel is Always Worse* (Black Hat USA 2023)
|
||||
* Envoy Security Advisory CVE-2024-2470 – Niewłaściwa walidacja autorytetu
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user