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

2025-10-10 18:36:50 +00:00 · 2025-08-20 19:29:06 +00:00 · 2025-08-20 19:29:06 +00:00 · 057533e269
commit 057533e269
parent 9b49ba9c5b
1 changed files with 57 additions and 57 deletions
--- a/src/pentesting-web/http-request-smuggling/README.md
+++ b/src/pentesting-web/http-request-smuggling/README.md
@ -11,7 +11,7 @@ To pozwala użytkownikowi na **zmodyfikowanie następnego żądania, które dotr

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

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

 **Content-Length**

@ -24,15 +24,15 @@ 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** 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** 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-gie 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 **nowy znak linii składa się z 2 bajtów:**
+Pamiętaj, że w HTTP **znak nowej linii składa się z 2 bajtów:**

- **Content-Length**: Ten nagłówek używa **liczby dziesiętnej** 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`
+- **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 smugglingu żądań.

 ## Podstawowe przykłady
@ -40,7 +40,7 @@ Pamiętaj, że w HTTP **nowy znak linii składa się z 2 bajtów:**
 > [!TIP]
 > 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 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.
+Ataki na smuggling żą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 wyników.

 ### Podstawowe przykłady typów luk

@ -56,7 +56,7 @@ Ataki smugglingu żądań HTTP 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 back-endu, opierając się na wartości `Content-Length`.
+- Serwer front-end przesyła całe żądanie do back-endu, na podstawie 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:**

@ -108,7 +108,7 @@ x=
 - **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że zostać wykorzystana luka CL.TE lub TE.CL.
+- W zależności od tego, który serwer (front-end czy back-end) nie rozpozna obfuskacji, może być 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:**

@ -181,15 +181,15 @@ x: X
 EMPTY_LINE_HERE
 EMPTY_LINE_HERE
 ```
-#### Breaking the web server
+#### Łamanie serwera WWW

-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**.
+Ta technika jest również przydatna w scenariuszach, w których możliwe jest **złamanie serwera WWW 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 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 powodował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
+#### Wymuszanie przez nagłówki hop-by-hop

-Wykorzystując nagłówki hop-by-hop, możesz wskazać proxy, aby **usunęło nagłówek Content-Length lub Transfer-Encoding, aby możliwe było nadużycie smugglingu żądań HTTP**.
+Wykorzystując nagłówki hop-by-hop, możesz wskazać serwerowi proxy, aby **usunął nagłówek Content-Length lub Transfer-Encoding, aby możliwe było nadużycie smugglingu żądań HTTP**.
 ```
 Connection: Content-Length
 ```
@ -227,7 +227,7 @@ A
 - Serwer zaplecza, oczekując na wiadomość w formacie chunked, czeka na następny kawałek, który nigdy nie nadchodzi, co powoduje opóźnienie.

 - **Wskaźniki:**
- Przekroczenia czasu oczekiwania lub długie opóźnienia w odpowiedzi.
+- Przekroczenia czasu lub długie opóźnienia w odpowiedzi.
 - Otrzymanie błędu 400 Bad Request od serwera zaplecza, czasami z szczegółowymi informacjami o serwerze.

 ### Znajdowanie podatności TE.CL za pomocą technik czasowych
@ -273,13 +273,13 @@ 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ó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.
+- **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 "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.

 ## Rozróżnianie artefaktów pipeliningu HTTP/1.1 a prawdziwe 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.
+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 prawdziwego desynchronizacji po stronie serwera.

 ### Dlaczego pipelining tworzy klasyczne fałszywe pozytywy

@ -320,7 +320,7 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Impact: brak. Po prostu odłączyłeś swojego klienta od ramki serwera.
+Impact: brak. Po prostu odłączyłeś swojego klienta od ramowania 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".
@ -335,12 +335,12 @@ Impact: brak. Po prostu odłączyłeś swojego klienta od ramki serwera.
 - 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.
+- Zobacz PortSwigger "Ataki desync zasilane przez 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.
+- Użyj rozszerzenia Burp "HTTP Hacker", aby bezpośrednio sprawdzić konkatenację i ramowanie wiadomości podczas eksperymentowania z ponownym użyciem i częściowymi żądaniami.

 ### Smuggling żądań zablokowanych na połączeniu (wymagane ponowne użycie)

@ -354,8 +354,8 @@ Niektóre front-endy ponownie używają połączenia upstream tylko wtedy, gdy k
 - 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.
+- Powtórz z kontrolowanym ponownym użyciem (Turbo Intruder `requestsPerConnection=2`, lub grupa zakładek Burp Repeater → "Wyślij grupę w kolejności (pojedyncze połączenie)").
+- Następnie połącz z prymitywami zatrucia pamięci podręcznej/ujawnienia nagłówków/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:
 >
@ -365,15 +365,15 @@ Niektóre front-endy ponownie używają połączenia upstream tylko wtedy, gdy k

 ### 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.
+Jeśli celujesz w desync zasilany przez 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
+browser-http-request-smuggling.md
 {{#endref}}

-### Narzędzia do pomocy w decyzji
+### Narzędzia do pomocy w podejmowaniu 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
@ -381,13 +381,13 @@ Dla tła i end-to-end workflow:
 - 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.).
+> Traktuj efekty tylko ponownego użycia 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ń, ominięta kontrola 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ń.
+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 zmyconego żą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:

@ -428,11 +428,11 @@ a=x
 ```
 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`.

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

-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**.
+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 back-endu. 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 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:
+Aby zbadać, jak proxy zmienia żądanie, zlokalizuj parametr POST, który back-end 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
@ -455,7 +455,7 @@ Ważne jest, aby dostosować nagłówek `Content-Length` zagnieżdżonego żąda

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

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

@ -483,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 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.
+Jednak ta technika ma ograniczenia. Zazwyczaj przechwytuje dane tylko do ogranicznika parametru używanego w przemycanym żą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.

@ -517,11 +517,11 @@ 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, 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.
+1. Inicjowanie żądania `POST`, które wydaje się typowe, z nagłówkiem `Transfer-Encoding: chunked`, aby wskazać początek przemytu.
+2. Następnie, po nim, znajduje się `0`, oznaczający koniec ciała wiadomości chunked.
+3. Potem wprowadzane jest przemytowe żądanie `GET`, 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.

-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.
+Manipulując `User-Agent` poprzez przemyt, ładunek omija normalne ograniczenia żądań, wykorzystując w ten sposób lukę Reflected XSS w niestandardowy, ale skuteczny sposób.

 #### HTTP/0.9

@ -530,9 +530,9 @@ Manipulując `User-Agent` poprzez smuggling, ładunek omija normalne ograniczeni

 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 wykonywalny kod JS z `Content-Type` równym `text/html`.
+W [**tym opisie**](https://mizu.re/post/twisty-python) to zostało nadużyte z przemytowym żądaniem i **wrażliwym punktem końcowym, który odpowiada na dane wejściowe użytkownika**, aby przemycić żądanie z HTTP/0.9. Parametr, który będzie odzwierciedlany 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`.

-### 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>
+### Wykorzystywanie przekierowań na stronie z przemytowym żądaniem HTTP <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 do drugiego, używając nazwy hosta z nagłówka `Host` w URL przekierowania. Jest to powszechne w serwerach internetowych, takich jak Apache i IIS. Na przykład, żądanie folderu bez ukośnika na końcu skutkuje przekierowaniem, aby dodać ukośnik:
 ```
@ -572,13 +572,13 @@ Location: https://attacker-website.com/home/
 ```
 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 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>
+### 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>

-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**.
+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**.

 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`.
+Technika ta staje się szczególnie potężna, jeśli zostanie odkryta **vulnerabilność Open Redirect** lub jeśli istnieje **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 serwować kod JavaScript kontrolowany przez atakującego:
 ```
@ -598,7 +598,7 @@ 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ść **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**).
+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. Poprzez zmianę **Host header**, atakujący może przekierować żądanie do swojej domeny (**on-site redirect to open redirect**).

 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.

@ -606,12 +606,12 @@ Następnie każde żądanie dla `/static/include.js` będzie serwować pamiętan

 ### Using HTTP request smuggling to perform web cache deception <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>

-> **Jaka jest różnica między web cache poisoning a web cache deception?**
+> **Jaka jest różnica między złośliwym przechowywaniem w pamięci podręcznej a oszustwem 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.
+> - W **złośliwym przechowywaniu w 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 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.

-Atakujący tworzy przemycone żądanie, które pobiera wrażliwą zawartość specyficzną dla użytkownika. Rozważ następujący przykład:
+Atakujący tworzy przemyślane żą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`\
@ -626,13 +626,13 @@ 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 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:
+[**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:
 ```
 TRACE / HTTP/1.1
 Host: example.com
 XSS: <script>alert("TRACE")</script>
 ```
-Sure, please provide the text you would like me to translate.
+Please provide the text you would like me to translate.
 ```
 HTTP/1.1 200 OK
 Content-Type: message/http
@ -643,15 +643,15 @@ Host: vulnerable.com
 XSS: <script>alert("TRACE")</script>
 X-Forwarded-For: xxx.xxx.xxx.xxx
 ```
-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**.\
+Przykład, jak wykorzystać 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**.\
 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 mogłoby 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 może 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>
+### Wykorzystywanie 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), 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.
+Kontynuując [**ten post**](https://portswigger.net/research/trace-desync-attack), sugeruje się inny sposób wykorzystania 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ł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).
+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).

 Przykład:
 ```
@ -672,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, ważna odpowiedź HTTP jest przemycana):
+Wygeneruje te odpowiedzi (zauważ, jak odpowiedź HEAD ma Content-Length, co sprawia, że odpowiedź TRACE jest częścią ciała HEAD, a gdy kończy się Content-Length HEAD, smuggled jest ważna odpowiedź HTTP):
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@ -703,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ądarce (strona klienta)
+- HTTP Request Smuggling w przeglądarkach (strona klienta)

 {{#ref}}
 browser-http-request-smuggling.md
@ -760,7 +760,7 @@ table.add(req)
 ```
 ### TE.CL

-Z: [https://hipotermia.pw/bb/http-desync-account-takeover](https://hipotermia.pw/bb/http-desync-account-takeover)
+From: [https://hipotermia.pw/bb/http-desync-account-takeover](https://hipotermia.pw/bb/http-desync-account-takeover)
 ```python
 def queueRequests(target, wordlists):
 engine = RequestEngine(endpoint=target.endpoint,
@ -824,7 +824,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/)
- 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)
+- Uważaj na fałszywe fałszywe pozytywy: jak odróżnić HTTP pipelining od smugglingu żądań – [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)