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

2025-10-10 18:36:50 +00:00 · 2025-08-20 16:35:32 +00:00 · 2025-08-20 16:35:32 +00:00 · 01c36a5e3c
commit 01c36a5e3c
parent 583c796381
2 changed files with 189 additions and 61 deletions
--- a/src/pentesting-web/http-request-smuggling/README.md
+++ b/src/pentesting-web/http-request-smuggling/README.md
@ -4,14 +4,14 @@

 ## Co to jest

-Ta luka występuje, gdy **desynchronizacja** między **proxy front-end** a **serwerem back-end** pozwala **atakującemu** na **wysłanie** żądania HTTP, które będzie **interpretowane** jako **jedno żądanie** przez **proxy front-end** (load balance/reverse-proxy) i **jako 2 żądania** przez **serwer back-end**.\
+Ta luka występuje, gdy **desynchronizacja** między **proxy front-end** a serwerem **back-end** pozwala **atakującemu** na **wysłanie** żądania HTTP, które będzie **interpretowane** jako **jedno żądanie** przez **proxy front-end** (load balance/reverse-proxy) i **jako 2 żądania** przez serwer **back-end**.\
 To pozwala użytkownikowi na **zmodyfikowanie następnego żądania, które dotrze do serwera back-end po jego**.

 ### Teoria

 [**Specyfikacja RFC (2161)**](https://tools.ietf.org/html/rfc2616)

-> Jeśli wiadomość zostanie odebrana z zarówno polem nagłówka Transfer-Encoding, jak i polem nagłówka Content-Length, to to drugie MUSI być zignorowane.
+> Jeśli wiadomość zostanie odebrana z nagłówkiem Transfer-Encoding oraz nagłówkiem Content-Length, ten ostatni MUSI zostać zignorowany.

 **Content-Length**

@ -24,29 +24,29 @@ To pozwala użytkownikowi na **zmodyfikowanie następnego żądania, które dotr

 ### Rzeczywistość

-**Front-End** (load-balance / Reverse Proxy) **przetwarza** nagłówek _**content-length**_ lub _**transfer-encoding**_ a **serwer Back-end** **przetwarza** ten drugi, co powoduje **desynchronizację** między 2 systemami.\
-Może to być bardzo krytyczne, ponieważ **atakujący będzie mógł 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** **2. wstrzyknięte żądanie** tak, jakby **pochodziło od następnego klienta**, a **prawdziwe żądanie** tego klienta będzie **częścią** **wstrzykniętego żądania**.
+**Front-End** (load-balance / Reverse Proxy) **przetwarza** nagłówek _**content-length**_ lub _**transfer-encoding**_ a serwer **Back-end** **przetwarza** drugi, co powoduje **desynchronizację** między 2 systemami.\
+Może to być bardzo krytyczne, ponieważ **atakujący będzie mógł 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** **2. wstrzyknięte żądanie** tak, jakby **pochodziło od następnego klienta**, a **prawdziwe żądanie** tego klienta będzie **częścią** **wstrzykniętego żądania**.

 ### Szczególności

-Pamiętaj, że w HTTP **znak nowej linii składa się z 2 bajtów:**
+Pamiętaj, że w HTTP **nowy znak linii składa się z 2 bajtów:**

- **Content-Length**: Ten nagłówek używa **liczby dziesiętnej** do wskazania **liczby** **bajtów** ciała żądania. Oczekuje się, że ciało zakończy się na ostatnim znaku, **znak nowej linii nie jest potrzebny na końcu żądania**.
- **Transfer-Encoding:** Ten nagłówek używa w **ciele** **liczby szesnastkowej** do wskazania **liczby** **bajtów** **następnego kawałka**. **Kawałek** musi **kończyć się** znakiem **nowej linii**, ale ten nowy znak **nie jest liczony** przez wskaźnik długości. Ta metoda transferu musi kończyć się **kawałkiem o rozmiarze 0, po którym następują 2 nowe linie**: `0`
- **Connection**: Na podstawie mojego doświadczenia zaleca się użycie **`Connection: keep-alive`** w pierwszym żądaniu w przypadku HTTP Request Smuggling.
+- **Content-Length**: Ten nagłówek używa **liczby dziesiętnej** do wskazania **liczby** **bajtów** ciała żądania. Oczekuje się, że ciało zakończy się na ostatnim znaku, **nowy znak nie jest potrzebny na końcu żądania**.
+- **Transfer-Encoding:** Ten nagłówek używa w **ciele** **liczby szesnastkowej** do wskazania **liczby** **bajtów** **następnego kawałka**. **Kawałek** musi **kończyć się** nowym znakiem, ale ten nowy znak **nie jest liczony** przez wskaźnik długości. Ta metoda transferu musi kończyć się **kawałkiem o rozmiarze 0, po którym następują 2 nowe linie**: `0`
+- **Connection**: Na podstawie mojego doświadczenia zaleca się użycie **`Connection: keep-alive`** w pierwszym żądaniu w smugglingu żądań.

 ## Podstawowe przykłady

 > [!TIP]
-> Podczas próby wykorzystania tego z Burp Suite **wyłącz `Update Content-Length` i `Normalize HTTP/1 line endings`** w repeaterze, ponieważ niektóre gadżety nadużywają znaków nowej linii, powrotów karetki i źle sformułowanych długości treści.
+> Próbując wykorzystać to z Burp Suite **wyłącz `Update Content-Length` i `Normalize HTTP/1 line endings`** w repeaterze, ponieważ niektóre gadżety nadużywają nowych linii, powrotów karetki i źle sformułowanych długości treści.

-Ataki HTTP request smuggling są tworzone poprzez wysyłanie niejednoznacznych żądań, które wykorzystują różnice w tym, jak serwery front-end i back-end interpretują nagłówki `Content-Length` (CL) i `Transfer-Encoding` (TE). Ataki te mogą manifestować się w różnych formach, głównie jako **CL.TE**, **TE.CL** i **TE.TE**. Każdy typ reprezentuje unikalną kombinację tego, jak serwery front-end i back-end priorytetują te nagłówki. Luka powstaje, gdy serwery przetwarzają to samo żądanie w różny sposób, prowadząc do nieoczekiwanych i potencjalnie złośliwych wyników.
+Ataki smugglingu żądań HTTP są tworzone poprzez wysyłanie niejednoznacznych żądań, które wykorzystują różnice w tym, jak serwery front-end i back-end interpretują nagłówki `Content-Length` (CL) i `Transfer-Encoding` (TE). Ataki te mogą manifestować się w różnych formach, głównie jako **CL.TE**, **TE.CL** i **TE.TE**. Każdy typ reprezentuje unikalną kombinację tego, jak serwery front-end i back-end priorytetują te nagłówki. Luka powstaje, gdy serwery przetwarzają to samo żądanie w różny sposób, prowadząc do nieoczekiwanych i potencjalnie złośliwych skutków.

 ### Podstawowe przykłady typów luk

 ![https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104](../../images/EKi5edAUUAAIPIK.jpg)

-> [!NOTE]
+> [!TIP]
 > Do poprzedniej tabeli powinieneś dodać technikę TE.0, jak technikę CL.0, ale używając Transfer Encoding.

 #### Luka CL.TE (Content-Length używany przez Front-End, Transfer-Encoding używany przez Back-End)
@ -56,7 +56,7 @@ Ataki HTTP request smuggling są tworzone poprzez wysyłanie niejednoznacznych
 - **Scenariusz ataku:**

 - Atakujący wysyła żądanie, w którym wartość nagłówka `Content-Length` nie odpowiada rzeczywistej długości treści.
- Serwer front-end przesyła całe żądanie do serwera back-end, opierając się na wartości `Content-Length`.
+- Serwer front-end przesyła całe żądanie do back-endu, opierając się na wartości `Content-Length`.
 - Serwer back-end przetwarza żądanie jako kawałkowe z powodu nagłówka `Transfer-Encoding: chunked`, interpretując pozostałe dane jako osobne, następne żądanie.
 - **Przykład:**

@ -80,7 +80,7 @@ Foo: x
 - **Scenariusz ataku:**

 - Atakujący wysyła żądanie kawałkowe, w którym rozmiar kawałka (`7b`) i rzeczywista długość treści (`Content-Length: 4`) nie są zgodne.
- Serwer front-end, honorując `Transfer-Encoding`, przesyła całe żądanie do serwera back-end.
+- Serwer front-end, honorując `Transfer-Encoding`, przesyła całe żądanie do back-endu.
 - Serwer back-end, respektując `Content-Length`, przetwarza tylko początkową część żądania (`7b` bajtów), pozostawiając resztę jako część niezamierzonego następnego żądania.
 - **Przykład:**

@ -102,13 +102,13 @@ x=

 ```

-#### Luka TE.TE (Transfer-Encoding używany przez oba, z obfuscacją)
+#### Luka TE.TE (Transfer-Encoding używany przez oba, z obfuskacją)

- **Serwery:** Oba wspierają `Transfer-Encoding`, ale jeden może być oszukany, aby go zignorować poprzez obfuscację.
+- **Serwery:** Oba wspierają `Transfer-Encoding`, ale jeden może być oszukany, aby go zignorować poprzez obfuskację.
 - **Scenariusz ataku:**

- Atakujący wysyła żądanie z obfuscowanymi nagłówkami `Transfer-Encoding`.
- W zależności od tego, który serwer (front-end lub back-end) nie rozpozna obfuscacji, może zostać wykorzystana luka CL.TE lub TE.CL.
+- 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że zostać wykorzystana luka CL.TE lub TE.CL.
 - Nieprzetworzona część żądania, widziana przez jeden z serwerów, staje się częścią następnego żądania, prowadząc do smugglingu.
 - **Przykład:**

@ -183,9 +183,9 @@ EMPTY_LINE_HERE
 ```
 #### Breaking the web server

-Ta technika jest również przydatna w scenariuszach, w których możliwe jest **złamanie serwera webowego podczas odczytywania początkowych danych HTTP**, ale **bez zamykania połączenia**. W ten sposób **ciało** żądania HTTP zostanie uznane za **następne żądanie HTTP**.
+Ta technika jest również przydatna w scenariuszach, w których możliwe jest **złamanie serwera webowego podczas odczytywania początkowych danych HTTP**, ale **bez zamykania połączenia**. W ten sposób **ciało** żądania HTTP będzie traktowane jako **następne żądanie HTTP**.

-Na przykład, jak wyjaśniono w [**tym opisie**](https://mizu.re/post/twisty-python), w Werkzeug możliwe było wysłanie niektórych **znaków Unicode**, co spowodowało **złamanie** serwera. Jednak jeśli połączenie HTTP zostało utworzone z nagłówkiem **`Connection: keep-alive`**, ciało żądania nie zostanie odczytane, a połączenie nadal będzie otwarte, więc **ciało** żądania zostanie potraktowane jako **następne żądanie HTTP**.
+Na przykład, jak wyjaśniono w [**tym opisie**](https://mizu.re/post/twisty-python), w Werkzeug możliwe było wysłanie niektórych **znaków Unicode**, co spowodowało **złamanie** serwera. Jednak jeśli połączenie HTTP zostało utworzone z nagłówkiem **`Connection: keep-alive`**, ciało żądania nie zostanie odczytane, a połączenie nadal będzie otwarte, więc **ciało** żądania będzie traktowane jako **następne żądanie HTTP**.

 #### Forcing via hop-by-hop headers

@ -255,7 +255,7 @@ X
 ### Inne metody znajdowania podatności

 - **Analiza różnic w odpowiedziach:**
- Wyślij nieco zmienione wersje żądania i obserwuj, czy odpowiedzi serwera różnią się w niespodziewany sposób, co wskazuje na niezgodność w analizie.
+- Wyślij nieco zmienione wersje żądania i obserwuj, czy odpowiedzi serwera różnią się w nieoczekiwany sposób, co wskazuje na niezgodność w analizie.
 - **Używanie 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.
 - **Testy zmienności Content-Length:**
@ -265,7 +265,7 @@ X

 ### Testowanie podatności na HTTP Request Smuggling

-Po potwierdzeniu skuteczności technik czasowych, kluczowe jest zweryfikowanie, czy żądania klienta mogą być manipulowane. Prosta metoda to próba zainfekowania swoich żądań, na przykład, aby żądanie do `/` zwróciło odpowiedź 404. Przykłady `CL.TE` i `TE.CL`, omówione wcześniej w [Podstawowych przykładach](#basic-examples), pokazują, jak zainfekować żądanie klienta, aby wywołać odpowiedź 404, mimo że klient dążył do uzyskania dostępu do innego zasobu.
+Po potwierdzeniu skuteczności technik czasowych, kluczowe jest zweryfikowanie, czy żądania klienta mogą być manipulowane. Prosta metoda to próba zainfekowania swoich żądań, na przykład, aby żądanie do `/` zwróciło odpowiedź 404. Przykłady `CL.TE` i `TE.CL` omówione wcześniej w [Podstawowych przykładach](#basic-examples) pokazują, jak zainfekować żądanie klienta, aby wywołać odpowiedź 404, mimo że klient dążył do uzyskania dostępu do innego zasobu.

 **Kluczowe uwagi**

@ -273,17 +273,123 @@ Podczas testowania podatności na request smuggling poprzez zakłócanie innych

 - **Oddzielnych połączeniach sieciowych:** "atak" i "normalne" żądania powinny być wysyłane przez oddzielne połączenia sieciowe. Wykorzystanie tego samego połączenia dla obu nie potwierdza obecności podatności.
 - **Spójnych URL i parametrów:** Staraj się używać identycznych URL i nazw parametrów dla obu żądań. Nowoczesne aplikacje często kierują żądania do konkretnych serwerów zaplecza na podstawie URL i parametrów. Dopasowanie ich zwiększa prawdopodobieństwo, że oba żądania będą przetwarzane przez ten sam serwer, co jest warunkiem udanego ataku.
- **Czasu i warunków wyścigu:** "normalne" żądanie, mające na celu wykrycie zakłóceń ze strony "atakującego" żądania, konkuruje z innymi równoległymi żądaniami aplikacji. Dlatego wyślij "normalne" żądanie natychmiast po "atakującym" żądaniu. Zajęte aplikacje mogą wymagać wielu prób, aby potwierdzić podatność.
- **Wyzwań związanych z równoważeniem obciążenia:** Serwery front-end działające jako równoważniki obciążenia mogą rozdzielać żądania między różne systemy zaplecza. Jeśli "atakujące" i "normalne" żądania trafią na różne systemy, atak nie powiedzie się. Ten aspekt równoważenia obciążenia może wymagać kilku prób, aby potwierdzić podatność.
- **Niezamierzony wpływ na użytkowników:** Jeśli twój atak niezamierzenie wpływa na żądanie innego użytkownika (nie "normalne" żądanie, które wysłałeś w celu wykrycia), oznacza to, że twój atak wpłynął na innego użytkownika aplikacji. Ciągłe testowanie może zakłócać innych użytkowników, co wymaga ostrożnego podejścia.
+- **Czasu i warunków wyścigu:** "normalne" żądanie, mające na celu wykrycie zakłóceń ze strony "atakującego" żądania, konkuruje z innymi równoczesnymi żądaniami aplikacji. Dlatego wyślij "normalne" żądanie natychmiast po "atakującym" żądaniu. Zajęte aplikacje mogą wymagać wielu prób dla jednoznacznego potwierdzenia podatności.
+- **Wyzwań związanych z równoważeniem obciążenia:** Serwery front-end działające jako równoważniki obciążenia mogą rozdzielać żądania między różne systemy zaplecza. Jeśli "atak" i "normalne" żądania trafią na różne systemy, atak nie powiedzie się. Ten aspekt równoważenia obciążenia może wymagać kilku prób, aby potwierdzić podatność.
+- **Niezamierzonego wpływu na użytkowników:** Jeśli twój atak niezamierzenie wpływa na żądanie innego użytkownika (nie "normalne" żądanie, które wysłałeś w celu wykrycia), oznacza to, że twój atak wpłynął na innego użytkownika aplikacji. Ciągłe testowanie może zakłócać innych użytkowników, co wymaga ostrożnego podejścia.

-## Wykorzystywanie HTTP Request Smuggling
+## Rozróżnianie artefaktów pipeliningu HTTP/1.1 a prawdziwe request smuggling

-### Ominięcie zabezpieczeń front-end za pomocą HTTP Request Smuggling
+Ponowne użycie połączenia (keep-alive) i pipelining mogą łatwo wytworzyć iluzje "smugglingu" w narzędziach testowych, które wysyłają wiele żądań na tym samym gnieździe. Naucz się oddzielać nieszkodliwe artefakty po stronie klienta od rzeczywistego desynchronizacji po stronie serwera.

-Czasami proxy front-end wymuszają środki bezpieczeństwa, analizując przychodzące żądania. Jednak te środki mogą być obejście poprzez wykorzystanie HTTP Request Smuggling, co pozwala na nieautoryzowany dostęp do zastrzeżonych punktów końcowych. Na przykład, dostęp do `/admin` może być zabroniony z zewnątrz, a proxy front-end aktywnie blokuje takie próby. Niemniej jednak, to proxy może zaniedbać sprawdzenie osadzonych żądań w ramach zafałszowanego żądania HTTP, pozostawiając lukę do ominięcia tych ograniczeń.
+### Dlaczego pipelining tworzy klasyczne fałszywe pozytywy

-Rozważ następujące przykłady ilustrujące, jak HTTP Request Smuggling może być używane do ominięcia zabezpieczeń front-end, szczególnie celując w ścieżkę `/admin`, która jest zazwyczaj chroniona przez proxy front-end:
+HTTP/1.1 ponownie wykorzystuje jedno połączenie TCP/TLS i łączy żądania i odpowiedzi w tym samym strumieniu. W pipeliningu klient wysyła wiele żądań jedno po drugim i polega na odpowiedziach w kolejności. Typowym fałszywym pozytywem jest ponowne wysłanie źle sformułowanego ładunku w stylu CL.0 dwa razy na jednym połączeniu:
+```
+POST / HTTP/1.1
+Host: hackxor.net
+Content_Length: 47
+
+GET /robots.txt HTTP/1.1
+X: Y
+```
+Odpowiedzi mogą wyglądać następująco:
+```
+HTTP/1.1 200 OK
+Content-Type: text/html
+
+```
+
+```
+HTTP/1.1 200 OK
+Content-Type: text/plain
+
+User-agent: *
+Disallow: /settings
+```
+Jeśli serwer zignorował źle sformatowany `Content_Length`, nie ma desynchronizacji FE↔BE. Przy ponownym użyciu, twój klient faktycznie wysłał ten strumień bajtów, który serwer zinterpretował jako dwa niezależne żądania:
+```
+POST / HTTP/1.1
+Host: hackxor.net
+Content_Length: 47
+
+GET /robots.txt HTTP/1.1
+X: YPOST / HTTP/1.1
+Host: hackxor.net
+Content_Length: 47
+
+GET /robots.txt HTTP/1.1
+X: Y
+```
+Impact: brak. Po prostu odłączyłeś swojego klienta od ramki serwera.
+
+> [!TIP]
+> Moduły Burp, które zależą od ponownego użycia/pipeliningu: Turbo Intruder z `requestsPerConnection>1`, Intruder z "HTTP/1 connection reuse", Repeater "Wyślij grupę w kolejności (pojedyncze połączenie)" lub "Włącz ponowne użycie połączenia".
+
+### Testy litmusowe: pipelining czy prawdziwy desync?
+
+1. Wyłącz ponowne użycie i przetestuj ponownie
+- W Burp Intruder/Repeater, wyłącz ponowne użycie HTTP/1 i unikaj "Wyślij grupę w kolejności".
+- W Turbo Intruder, ustaw `requestsPerConnection=1` i `pipeline=False`.
+- Jeśli zachowanie zniknie, prawdopodobnie było to pipelining po stronie klienta, chyba że masz do czynienia z celami zablokowanymi na połączeniu/stanu lub desynkronizacją po stronie klienta.
+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, udowodniłeś błąd parsowania/desync w backendzie, a nie czysty artefakt klienta.
+3. Proba częściowych żądań dla front-endów zablokowanych na połączeniu
+- Niektóre FEs ponownie używają połączenia BE tylko wtedy, gdy klient ponownie używa swojego. Użyj częściowych żądań, aby wykryć zachowanie FE, które odzwierciedla ponowne użycie klienta.
+- Zobacz PortSwigger "Ataki Desync zasilane przeglądarką" dla techniki zablokowanej na połączeniu.
+4. Proby stanu
+- Szukaj różnic między pierwszym a kolejnymi żądaniami na tym samym połączeniu TCP (routing/walidacja pierwszego żądania).
+- Burp "HTTP Request Smuggler" zawiera sondę stanu połączenia, która automatyzuje to.
+5. Wizualizuj połączenie
+- Użyj rozszerzenia Burp "HTTP Hacker", aby bezpośrednio sprawdzić konkatenację i ramki wiadomości podczas eksperymentowania z ponownym użyciem i częściowymi żądaniami.
+
+### Smuggling żądań zablokowanych na połączeniu (wymagane ponowne użycie)
+
+Niektóre front-endy ponownie używają połączenia upstream tylko wtedy, gdy klient ponownie używa swojego. Prawdziwy smuggling istnieje, ale jest uzależniony od ponownego użycia po stronie klienta. Aby odróżnić i udowodnić wpływ:
+- Udowodnij błąd po stronie serwera
+- Użyj sprawdzenia zagnieżdżonej odpowiedzi HTTP/2, lub
+- Użyj częściowych żądań, aby pokazać, że FE ponownie używa upstream tylko wtedy, gdy klient to robi.
+- Pokaż rzeczywisty wpływ, nawet jeśli bezpośrednie nadużycie gniazd między użytkownikami jest zablokowane:
+- Zatrucie pamięci podręcznej: truj współdzielone pamięci podręczne za pomocą desync, aby odpowiedzi wpływały na innych użytkowników.
+- Ujawnienie nagłówków wewnętrznych: odzwierciedl nagłówki wstrzyknięte przez FE (np. nagłówki auth/trust) i przejdź do obejścia autoryzacji.
+- Obejście kontroli FE: przemyć zastrzeżone ścieżki/metody przez front-end.
+- Nadużycie nagłówka hosta: połącz z osobliwościami routingu hosta, aby przejść do wewnętrznych vhosts.
+- Przepływ pracy operatora
+- Powtórz z kontrolowanym ponownym użyciem (Turbo Intruder `requestsPerConnection=2`, lub grupa zakładki Burp Repeater → "Wyślij grupę w kolejności (pojedyncze połączenie)").
+- Następnie połącz z prymitywami zatrucia pamięci podręcznej/nagłówka/obejścia kontroli i pokaż wpływ między użytkownikami lub autoryzacji.
+
+> Zobacz także ataki stanu połączenia, które są ściśle związane, ale nie są technicznie smugglingiem:
+>
+>{{#ref}}
+>../http-connection-request-smuggling.md
+>{{#endref}}
+
+### Ograniczenia desync po stronie klienta
+
+Jeśli celujesz w desync zasilany przeglądarką/po stronie klienta, złośliwe żądanie musi być wysyłane przez przeglądarkę z innego źródła. Sztuczki z obfuskacją nagłówków nie zadziałają. Skup się na prymitywach dostępnych przez nawigację/fetch, a następnie przejdź do zatrucia pamięci podręcznej, ujawnienia nagłówków lub obejścia kontroli front-endu, gdzie komponenty downstream odzwierciedlają lub buforują odpowiedzi.
+
+Dla tła i end-to-end workflow:
+
+{{#ref}}
+-browser-http-request-smuggling.md
+{{#endref}}
+
+### Narzędzia do pomocy w decyzji
+
+- HTTP Hacker (Burp BApp Store): ujawnia niskopoziomowe zachowanie HTTP i konkatenację gniazd.
+- "Smuggling czy pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
+- Turbo Intruder: precyzyjna kontrola nad ponownym użyciem połączenia za pomocą `requestsPerConnection`.
+- Burp HTTP Request Smuggler: zawiera sondę stanu połączenia, aby wykryć routing/walidację pierwszego żądania.
+
+> [!NOTE]
+> Traktuj efekty tylko z ponownym użyciem jako nieistotne, chyba że możesz udowodnić desync po stronie serwera i dołączyć konkretne skutki (zatruty artefakt pamięci podręcznej, ujawniony wewnętrzny nagłówek umożliwiający obejście uprawnień, obejście kontroli FE itp.).
+
+## Nadużywanie HTTP Request Smuggling
+
+### Obejście zabezpieczeń front-endu za pomocą HTTP Request Smuggling
+
+Czasami, front-endowe proxy egzekwują środki bezpieczeństwa, skrupulatnie analizując przychodzące żądania. Jednak te środki mogą być obejście poprzez wykorzystanie HTTP Request Smuggling, co pozwala na nieautoryzowany dostęp do zastrzeżonych punktów końcowych. Na przykład, dostęp do `/admin` może być zabroniony z zewnątrz, a front-endowe proxy aktywnie blokuje takie próby. Niemniej jednak, to proxy może zaniedbać sprawdzenie osadzonych żądań w ramach zmyślonego żądania HTTP, pozostawiając lukę do obejścia tych ograniczeń.
+
+Rozważ następujące przykłady ilustrujące, jak HTTP Request Smuggling może być używane do obejścia kontroli bezpieczeństwa front-endu, szczególnie celując w ścieżkę `/admin`, która jest zazwyczaj chroniona przez front-endowe proxy:

 **Przykład CL.TE**
 ```
@ -320,13 +426,13 @@ a=x
 0

 ```
-W przeciwnym razie, w ataku TE.CL, początkowe żądanie `POST` używa `Transfer-Encoding: chunked`, a następne osadzone żądanie jest przetwarzane na podstawie nagłówka `Content-Length`. Podobnie jak w ataku CL.TE, frontowy proxy pomija przemycone żądanie `GET /admin`, nieumyślnie przyznając dostęp do zastrzeżonej ścieżki `/admin`.
+Przeciwnie, w ataku TE.CL początkowe żądanie `POST` używa `Transfer-Encoding: chunked`, a następne osadzone żądanie jest przetwarzane na podstawie nagłówka `Content-Length`. Podobnie jak w ataku CL.TE, proxy front-endowe pomija oszukańcze żądanie `GET /admin`, nieumyślnie przyznając dostęp do zastrzeżonej ścieżki `/admin`.

-### Revealing front-end request rewriting <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
+### Odkrywanie przepisywania żądań front-endowych <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>

-Aplikacje często wykorzystują **serwer frontowy** do modyfikacji przychodzących żądań przed ich przekazaniem do serwera zaplecza. Typowa modyfikacja polega na dodaniu nagłówków, takich jak `X-Forwarded-For: <IP klienta>`, aby przekazać IP klienta do zaplecza. Zrozumienie tych modyfikacji może być kluczowe, ponieważ może ujawnić sposoby na **obejście zabezpieczeń** lub **ujawnienie ukrytych informacji lub punktów końcowych**.
+Aplikacje często wykorzystują **serwer front-endowy** do modyfikacji przychodzących żądań przed ich przekazaniem do serwera back-endowego. Typowa modyfikacja polega na dodawaniu nagłówków, takich jak `X-Forwarded-For: <IP klienta>`, aby przekazać IP klienta do serwera back-endowego. Zrozumienie tych modyfikacji może być kluczowe, ponieważ może ujawnić sposoby na **obejście zabezpieczeń** lub **ujawnienie ukrytych informacji lub punktów końcowych**.

-Aby zbadać, jak proxy zmienia żądanie, zlokalizuj parametr POST, który zaplecze odzwierciedla w odpowiedzi. Następnie stwórz żądanie, używając tego parametru jako ostatniego, podobnie jak w poniższym przykładzie:
+Aby zbadać, jak proxy zmienia żądanie, zlokalizuj parametr POST, który serwer back-endowy odzwierciedla w odpowiedzi. Następnie stwórz żądanie, używając tego parametru na końcu, podobnie jak w poniższym przykładzie:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@ -347,13 +453,13 @@ W tej strukturze kolejne komponenty żądania są dołączane po `search=`, któ

 Ważne jest, aby dostosować nagłówek `Content-Length` zagnieżdżonego żądania do rzeczywistej długości treści. Zaleca się rozpoczęcie od małej wartości i stopniowe zwiększanie, ponieważ zbyt niska wartość obetnie odzwierciedlone dane, podczas gdy zbyt wysoka wartość może spowodować błąd żądania.

-Ta technika ma również zastosowanie w kontekście podatności TE.CL, ale żądanie powinno kończyć się na `search=\r\n0`. Niezależnie od znaków nowej linii, wartości będą dołączane do parametru search.
+Ta technika jest również stosowana w kontekście podatności TE.CL, ale żądanie powinno kończyć się na `search=\r\n0`. Niezależnie od znaków nowej linii, wartości będą dołączane do parametru search.

-Metoda ta służy głównie do zrozumienia modyfikacji żądania dokonywanych przez proxy front-endowe, zasadniczo przeprowadzając samodzielne dochodzenie.
+Metoda ta służy głównie do zrozumienia modyfikacji żądania dokonywanych przez proxy front-end, zasadniczo przeprowadzając samodzielne dochodzenie.

 ### Capturing other users' requests <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>

-Możliwe jest przechwycenie żądań następnego użytkownika, dołączając konkretne żądanie jako wartość parametru podczas operacji POST. Oto jak można to osiągnąć:
+Możliwe jest przechwycenie żądań następnego użytkownika, dołączając określone żądanie jako wartość parametru podczas operacji POST. Oto jak można to osiągnąć:

 Dołączając następujące żądanie jako wartość parametru, możesz przechować żądanie kolejnego klienta:
 ```
@ -377,7 +483,7 @@ csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40ema
 ```
 W tym scenariuszu **parametr komentarza** ma na celu przechowywanie treści w sekcji komentarzy posta na publicznie dostępnym stronie. W związku z tym, zawartość kolejnego żądania pojawi się jako komentarz.

-Jednak ta technika ma ograniczenia. Zazwyczaj przechwytuje dane tylko do ogranicznika parametru używanego w przemycanym żądaniu. Dla formularzy zakodowanych w URL, tym ogranicznikiem jest znak `&`. Oznacza to, że przechwycona zawartość z żądania użytkownika ofiary zatrzyma się na pierwszym `&`, który może być nawet częścią ciągu zapytania.
+Jednak ta technika ma ograniczenia. Zazwyczaj przechwytuje dane tylko do ogranicznika parametru używanego w przemyconym żądaniu. Dla formularzy przesyłanych w formacie URL-encoded, tym ogranicznikiem jest znak `&`. Oznacza to, że przechwycona zawartość z żądania użytkownika ofiary zatrzyma się na pierwszym `&`, który może być nawet częścią ciągu zapytania.

 Dodatkowo warto zauważyć, że podejście to jest również wykonalne w przypadku 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 będą dołączane do parametru wyszukiwania.

@ -412,8 +518,8 @@ A=
 Ten ładunek jest skonstruowany w celu wykorzystania luki poprzez:

 1. Inicjowanie żądania `POST`, które wydaje się typowe, z nagłówkiem `Transfer-Encoding: chunked`, aby wskazać początek smugglingu.
-2. Następnie, po nim, znajduje się `0`, oznaczający koniec ciała wiadomości chunked.
-3. Potem wprowadzane jest smuggled `GET` żądanie, w którym nagłówek `User-Agent` jest wstrzykiwany z skryptem, `<script>alert(1)</script>`, co wywołuje XSS, gdy serwer przetwarza to kolejne żądanie.
+2. Następnie, z `0`, oznaczającym koniec ciała wiadomości chunked.
+3. Potem wprowadzane jest smuggled `GET` żądanie, w którym nagłówek `User-Agent` jest wstrzykiwany z skryptem, `<script>alert(1)</script>`, wywołującym XSS, gdy serwer przetwarza to kolejne żądanie.

 Manipulując `User-Agent` poprzez smuggling, ładunek omija normalne ograniczenia żądań, wykorzystując w ten sposób lukę Reflected XSS w niestandardowy, ale skuteczny sposób.

@ -422,9 +528,9 @@ Manipulując `User-Agent` poprzez smuggling, ładunek omija normalne ograniczeni
 > [!CAUTION]
 > W przypadku, gdy zawartość użytkownika jest odzwierciedlana w odpowiedzi z **`Content-type`** takim jak **`text/plain`**, co uniemożliwia wykonanie XSS. Jeśli serwer obsługuje **HTTP/0.9, może być możliwe ominięcie tego**!

-Wersja HTTP/0.9 była wcześniejsza od 1.0 i używa tylko czasowników **GET** oraz **nie** odpowiada nagłówkami, tylko ciałem.
+Wersja HTTP/0.9 była wcześniejsza od 1.0 i używa tylko czasowników **GET** oraz **nie** odpowiada z **nagłówkami**, tylko ciałem.

-W [**tym opisie**](https://mizu.re/post/twisty-python) to zostało nadużyte z wykorzystaniem smugglingu żądań i **vulnerable endpoint, który odpowie na dane wejściowe użytkownika**, aby smuggled żądanie z HTTP/0.9. Parametr, który będzie odzwierciedlony w odpowiedzi, zawierał **fałszywą odpowiedź HTTP/1.1 (z nagłówkami i ciałem)**, więc odpowiedź będzie zawierać ważny wykonawczy kod JS z `Content-Type` równym `text/html`.
+W [**tym opisie**](https://mizu.re/post/twisty-python) to zostało nadużyte z wykorzystaniem smugglingu żądań i **vulnerable endpoint, który odpowie na dane wejściowe użytkownika**, aby smuggled żądanie z HTTP/0.9. Parametr, który będzie odzwierciedlony w odpowiedzi, zawierał **fałszywą odpowiedź HTTP/1.1 (z nagłówkami i ciałem)**, więc odpowiedź będzie zawierać ważny wykonywalny kod JS z `Content-Type` równym `text/html`.

 ### Wykorzystywanie przekierowań na stronie z użyciem HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>

@ -464,17 +570,17 @@ Wyniki w:
 HTTP/1.1 301 Moved Permanently
 Location: https://attacker-website.com/home/
 ```
-W tym scenariuszu żądanie użytkownika dotyczące pliku JavaScript jest przechwytywane. Atakujący może potencjalnie skompromitować użytkownika, dostarczając złośliwy JavaScript w odpowiedzi.
+W tym scenariuszu żądanie użytkownika dotyczące pliku JavaScript jest przejmowane. Atakujący może potencjalnie skompromitować użytkownika, serwując złośliwy JavaScript w odpowiedzi.

-### Wykorzystywanie zanieczyszczenia pamięci podręcznej w sieci za pomocą HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
+### Wykorzystywanie złośliwego zatrucia pamięci podręcznej przez HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

-Zanieczyszczenie pamięci podręcznej w sieci może być realizowane, jeśli jakikolwiek komponent **infrastruktury front-endowej buforuje treści**, zazwyczaj w celu poprawy wydajności. Manipulując odpowiedzią serwera, możliwe jest **zatrucie pamięci podręcznej**.
+Zatrucie pamięci podręcznej w sieci może być zrealizowane, jeśli jakikolwiek komponent **infrastruktury front-endowej buforuje treści**, zazwyczaj w celu poprawy wydajności. Manipulując odpowiedzią serwera, możliwe jest **zatrucie pamięci podręcznej**.

 Wcześniej zaobserwowaliśmy, jak odpowiedzi serwera mogą być zmieniane, aby zwracały błąd 404 (zobacz [Podstawowe przykłady](#basic-examples)). Podobnie, możliwe jest oszukanie serwera, aby dostarczył treść `/index.html` w odpowiedzi na żądanie dotyczące `/static/include.js`. W konsekwencji treść `/static/include.js` zostaje zastąpiona w pamięci podręcznej treścią `/index.html`, co sprawia, że `/static/include.js` staje się niedostępne dla użytkowników, co potencjalnie prowadzi do Denial of Service (DoS).

 Technika ta staje się szczególnie potężna, jeśli zostanie odkryta **vulnerabilność Open Redirect** lub jeśli występuje **przekierowanie na stronie do otwartego przekierowania**. Takie luki mogą być wykorzystywane do zastąpienia buforowanej treści `/static/include.js` skryptem kontrolowanym przez atakującego, co zasadniczo umożliwia szeroką atak Cross-Site Scripting (XSS) przeciwko wszystkim klientom żądającym zaktualizowanego `/static/include.js`.

-Poniżej znajduje się ilustracja wykorzystywania **zatrucia pamięci podręcznej w połączeniu z przekierowaniem na stronie do otwartego przekierowania**. Celem jest zmiana treści pamięci podręcznej `/static/include.js`, aby dostarczyć kod JavaScript kontrolowany przez atakującego:
+Poniżej znajduje się ilustracja wykorzystywania **zatrucia pamięci podręcznej w połączeniu z przekierowaniem na stronie do otwartego przekierowania**. Celem jest zmiana treści pamięci podręcznej `/static/include.js`, aby serwować kod JavaScript kontrolowany przez atakującego:
 ```
 POST / HTTP/1.1
 Host: vulnerable.net
@ -492,20 +598,20 @@ Content-Length: 10

 x=1
 ```
-Zauważ osadzony żądanie kierujące do `/post/next?postId=3`. To żądanie zostanie przekierowane do `/post?postId=4`, wykorzystując **wartość nagłówka Host** do określenia domeny. Zmieniając **nagłówek Host**, atakujący może przekierować żądanie do swojej domeny (**przekierowanie na stronie do otwartego przekierowania**).
+Zauważ osadzony żądanie kierujące do `/post/next?postId=3`. To żądanie zostanie przekierowane do `/post?postId=4`, wykorzystując wartość **Host header** do określenia domeny. Zmieniając **Host header**, atakujący może przekierować żądanie do swojej domeny (**on-site redirect to open redirect**).

-Po udanym **truciu gniazdka**, powinno zostać zainicjowane **żądanie GET** dla `/static/include.js`. To żądanie zostanie zanieczyszczone przez wcześniejsze żądanie **przekierowania na stronie do otwartego przekierowania** i pobierze zawartość skryptu kontrolowanego przez atakującego.
+Po udanym **socket poisoning**, powinno zostać zainicjowane **GET request** dla `/static/include.js`. To żądanie zostanie zanieczyszczone przez wcześniejsze żądanie **on-site redirect to open redirect** i pobierze zawartość skryptu kontrolowanego przez atakującego.

-Następnie każde żądanie dla `/static/include.js` będzie serwować pamiętaną zawartość skryptu atakującego, skutecznie uruchamiając szeroką atak XSS.
+Następnie każde żądanie dla `/static/include.js` będzie serwować pamiętaną zawartość skryptu atakującego, skutecznie uruchamiając szeroki atak XSS.

-### Wykorzystanie smugglingu żądań HTTP do przeprowadzenia oszustwa w pamięci podręcznej <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 truciem pamięci podręcznej a oszustwem w pamięci podręcznej?**
+> **Jaka jest różnica między web cache poisoning a web cache deception?**
 >
-> - W **truciu pamięci podręcznej**, atakujący powoduje, że aplikacja przechowuje w pamięci podręcznej złośliwą zawartość, a ta zawartość jest serwowana z pamięci podręcznej innym użytkownikom aplikacji.
-> - W **oszustwie w pamięci podręcznej**, atakujący powoduje, że aplikacja przechowuje w pamięci podręcznej wrażliwą zawartość należącą do innego użytkownika, a następnie atakujący pobiera tę zawartość z pamięci podręcznej.
+> - W **web cache poisoning**, atakujący powoduje, że aplikacja przechowuje złośliwą zawartość w pamięci podręcznej, a ta zawartość jest serwowana z pamięci podręcznej innym użytkownikom aplikacji.
+> - W **web cache deception**, atakujący powoduje, że aplikacja przechowuje w pamięci podręcznej wrażliwą zawartość należącą do innego użytkownika, a następnie atakujący pobiera tę zawartość z pamięci podręcznej.

-Atakujący tworzy przemyślane żądanie, które pobiera wrażliwą zawartość specyficzną dla użytkownika. Rozważ następujący przykład:
+Atakujący tworzy przemycone żądanie, które pobiera wrażliwą zawartość specyficzną dla użytkownika. Rozważ następujący przykład:
 ```markdown
 `POST / HTTP/1.1`\
 `Host: vulnerable-website.com`\
@ -520,7 +626,7 @@ Jeśli ten przemycony żądanie zanieczyści wpis w pamięci podręcznej przezna

 ### Wykorzystywanie TRACE za pomocą HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

-[**W tym poście**](https://portswigger.net/research/trace-desync-attack) zasugerowano, że jeśli serwer ma włączoną metodę TRACE, może być możliwe jej nadużycie za pomocą HTTP Request Smuggling. Dzieje się tak, ponieważ ta metoda odzwierciedli każdy nagłówek wysłany do serwera jako część treści 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że być możliwe jej wykorzystanie za pomocą HTTP Request Smuggling. Dzieje się tak, ponieważ ta metoda odzwierciedli każdy nagłówek wysłany do serwera jako część treści odpowiedzi. Na przykład:
 ```
 TRACE / HTTP/1.1
 Host: example.com
@ -537,15 +643,15 @@ Host: vulnerable.com
 XSS: <script>alert("TRACE")</script>
 X-Forwarded-For: xxx.xxx.xxx.xxx
 ```
-Przykład, jak nadużyć to zachowanie, polega na **przemyceniu najpierw żądania HEAD**. To żądanie zostanie odpowiedziane tylko **nagłówkami** żądania GET (**`Content-Type`** wśród nich). A następnie przemycić **natychmiast po HEAD żądanie TRACE**, które będzie **odzwierciedlać wysłane dane**.\
+Przykładem nadużycia tego zachowania byłoby **przemycenie najpierw żądania HEAD**. To żądanie zostanie odpowiedziane tylko **nagłówkami** żądania GET (**`Content-Type`** wśród nich). A następnie przemycić **natychmiast po HEAD żądanie TRACE**, które będzie **odzwierciedlać wysłane dane**.\
 Ponieważ odpowiedź HEAD będzie zawierać nagłówek `Content-Length`, **odpowiedź żądania TRACE będzie traktowana jako ciało odpowiedzi HEAD, co zatem odzwierciedli dowolne dane** w odpowiedzi.\
-Ta odpowiedź zostanie wysłana do następnego żądania przez połączenie, więc może to być **użyte w pamiętanym pliku JS, na przykład do wstrzyknięcia dowolnego kodu JS**.
+Ta odpowiedź zostanie wysłana do następnego żądania przez połączenie, więc mogłoby to być **użyte w pamiętanym pliku JS, na przykład do wstrzyknięcia dowolnego kodu JS**.

 ### Nadużywanie TRACE poprzez HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

-Kontynuując [**ten post**](https://portswigger.net/research/trace-desync-attack), sugerowana jest inna metoda nadużywania metody TRACE. Jak wspomniano, przemycając żądanie HEAD i żądanie TRACE, możliwe jest **kontrolowanie niektórych odzwierciedlonych danych** w odpowiedzi na żądanie HEAD. Długość ciała żądania HEAD jest zasadniczo wskazywana w nagłówku Content-Length i jest tworzona przez odpowiedź na żądanie TRACE.
+Kontynuując [**ten post**](https://portswigger.net/research/trace-desync-attack), sugeruje się inny sposób nadużycia metody TRACE. Jak wspomniano, przemycając żądanie HEAD i żądanie TRACE, możliwe jest **kontrolowanie niektórych odzwierciedlonych danych** w odpowiedzi na żądanie HEAD. Długość ciała żądania HEAD jest zasadniczo wskazywana w nagłówku Content-Length i jest tworzona przez odpowiedź na żądanie TRACE.

-Dlatego nowy pomysł polega na tym, że, znając ten Content-Length i dane podane w odpowiedzi TRACE, możliwe jest sprawienie, aby odpowiedź TRACE zawierała ważną odpowiedź HTTP po ostatnim bajcie Content-Length, co pozwala atakującemu całkowicie kontrolować żądanie do następnej odpowiedzi (co mogłoby być użyte do przeprowadzenia zanieczyszczenia pamięci podręcznej).
+Dlatego nowy pomysł polegałby na tym, że, znając ten Content-Length i dane podane w odpowiedzi TRACE, możliwe jest sprawienie, aby odpowiedź TRACE zawierała ważną odpowiedź HTTP po ostatnim bajcie Content-Length, co pozwalałoby atakującemu całkowicie kontrolować żądanie do następnej odpowiedzi (co mogłoby być użyte do przeprowadzenia zanieczyszczenia pamięci podręcznej).

 Przykład:
 ```
@ -566,7 +672,7 @@ Content-Length: 44\r\n
 \r\n
 <script>alert("response splitting")</script>
 ```
-Wygeneruje te odpowiedzi (zauważ, jak odpowiedź HEAD ma Content-Length, co sprawia, że odpowiedź TRACE jest częścią ciała HEAD, a po zakończeniu Content-Length HEAD smuggled jest ważna odpowiedź HTTP):
+Wygeneruje te odpowiedzi (zauważ, jak odpowiedź HEAD ma Content-Length, co sprawia, że odpowiedź TRACE jest częścią ciała HEAD, a po zakończeniu Content-Length HEAD, ważna odpowiedź HTTP jest przemycana):
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@ -597,7 +703,7 @@ Czy znalazłeś jakąś podatność na HTTP Request Smuggling i nie wiesz, jak j

 ### Inne techniki HTTP Request Smuggling

- HTTP Request Smuggling w przeglądarkach (strona klienta)
+- HTTP Request Smuggling w przeglądarce (strona klienta)

 {{#ref}}
 browser-http-request-smuggling.md
@ -698,12 +804,14 @@ table.add(req)
 ```
 ## Narzędzia

+- HTTP Hacker (Burp BApp Store) – wizualizacja konkatenacji/ramkowania i niskopoziomowego zachowania HTTP
+- https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Custom Action "Smuggling or pipelining?"
 - [https://github.com/anshumanpattnaik/http-request-smuggling](https://github.com/anshumanpattnaik/http-request-smuggling)
 - [https://github.com/PortSwigger/http-request-smuggler](https://github.com/PortSwigger/http-request-smuggler)
 - [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py)
 - [https://github.com/defparam/smuggler](https://github.com/defparam/smuggler)
 - [https://github.com/Moopinger/smugglefuzz](https://github.com/Moopinger/smugglefuzz)
- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): To narzędzie to fuzzer HTTP oparty na gramatyce, przydatne do znajdowania dziwnych niezgodności w smugglingu żądań.
+- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): To narzędzie to gramatyczny HTTP Fuzzer przydatny do znajdowania dziwnych rozbieżności w smugglingu żądań.

 ## Odniesienia

@ -716,6 +824,10 @@ table.add(req)
 - [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/)
 - [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack)
 - [https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
+- Uważaj na fałszywe 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/)
+- Ataki Desync zasilane przez przeglądarkę – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
+- PortSwigger Academy – desync po stronie klienta – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)


 {{#include ../../banners/hacktricks-training.md}}
--- a/src/pentesting-web/http-request-smuggling/browser-http-request-smuggling.md
+++ b/src/pentesting-web/http-request-smuggling/browser-http-request-smuggling.md
@ -2,6 +2,22 @@

 {{#include ../../banners/hacktricks-training.md}}

-**Sprawdź post [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)**
+Browser-powered desync (aka client-side request smuggling) wykorzystuje przeglądarkę ofiary do dodania źle sformatowanego żądania do wspólnego połączenia, tak aby kolejne żądania były analizowane w sposób niesynchronizowany przez komponent downstream. W przeciwieństwie do klasycznego smugglingu FE↔BE, ładunki są ograniczone przez to, co przeglądarka może legalnie wysłać między różnymi źródłami.
+
+Kluczowe ograniczenia i wskazówki
+- Używaj tylko nagłówków i składni, które przeglądarka może wysłać za pomocą nawigacji, fetch lub przesyłania formularzy. Obfuskacje nagłówków (triki LWS, duplikaty TE, nieprawidłowy CL) zazwyczaj nie będą wysyłane.
+- Celuj w punkty końcowe i pośredników, którzy odzwierciedlają dane wejściowe lub buforują odpowiedzi. Przydatne skutki obejmują zanieczyszczenie pamięci podręcznej, wyciek nagłówków wstrzykiwanych przez front-end lub obejście kontroli ścieżki/metody front-end.
+- Powtórne użycie ma znaczenie: dostosuj skonstruowane żądanie, aby dzieliło to samo połączenie HTTP/1.1 lub H2 z żądaniem ofiary o wysokiej wartości. Zachowania zablokowane na połączeniu/stanu wzmacniają wpływ.
+- Preferuj prymitywy, które nie wymagają niestandardowych nagłówków: mylenie ścieżek, wstrzykiwanie ciągu zapytania i kształtowanie ciała za pomocą POST-ów zakodowanych w formularzu.
+- Waliduj prawdziwe desynchronizacje po stronie serwera w porównaniu do jedynie artefaktów pipeliningu, ponownie testując bez ponownego użycia lub używając sprawdzenia zagnieżdżonej odpowiedzi HTTP/2.
+
+Dla technik end-to-end i PoC zobacz:
+- PortSwigger Research – Browser‑Powered Desync Attacks: https://portswigger.net/research/browser-powered-desync-attacks
+- PortSwigger Academy – client‑side desync: https://portswigger.net/web-security/request-smuggling/browser/client-side-desync
+
+## References
+- [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
+- [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
+- Distinguishing pipelining vs smuggling (background on reuse false-positives): https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling

 {{#include ../../banners/hacktricks-training.md}}