Translated ['src/pentesting-web/crlf-0d-0a.md'] to pl

2025-10-10 18:36:50 +00:00 · 2025-07-16 16:11:22 +00:00 · 2025-07-16 16:11:22 +00:00 · 61830c20e6
commit 61830c20e6
parent 2f66cc42af
1 changed files with 57 additions and 22 deletions
--- a/src/pentesting-web/crlf-0d-0a.md
+++ b/src/pentesting-web/crlf-0d-0a.md
@ -18,31 +18,31 @@ Rozważ plik dziennika w panelu administracyjnym, który ma format: `IP - Czas -
 ```
 123.123.123.123 - 08:15 - /index.php?page=home
 ```
-Napastnik może wykorzystać wstrzyknięcie CRLF do manipulacji tym logiem. Wprowadzając znaki CRLF do żądania HTTP, napastnik może zmienić strumień wyjściowy i sfałszować wpisy w logu. Na przykład, wstrzyknięta sekwencja może przekształcić wpis w logu w:
+Napastnik może wykorzystać wstrzyknięcie CRLF do manipulacji tym logiem. Wstrzykując znaki CRLF do żądania HTTP, napastnik może zmienić strumień wyjściowy i sfałszować wpisy w logu. Na przykład, wstrzyknięta sekwencja może przekształcić wpis w logu w:
 ```
 /index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
 ```
-Tutaj `%0d` i `%0a` reprezentują URL-enkodowane formy CR i LF. Po ataku, log wprowadzi w błąd, wyświetlając:
+Tutaj `%0d` i `%0a` reprezentują zakodowane w URL formy CR i LF. Po ataku, log wprowadzi w błąd, wyświetlając:
 ```
 IP - Time - Visited Path

 123.123.123.123 - 08:15 - /index.php?page=home&
 127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
 ```
-Atakujący w ten sposób ukrywa swoje złośliwe działania, sprawiając, że wydaje się, iż localhost (podmiot zazwyczaj zaufany w środowisku serwera) wykonał te działania. Serwer interpretuje część zapytania zaczynającą się od `%0d%0a` jako jeden parametr, podczas gdy parametr `restrictedaction` jest analizowany jako inny, oddzielny input. Manipulowane zapytanie skutecznie naśladuje legalne polecenie administracyjne: `/index.php?page=home&restrictedaction=edit`
+Atakujący w ten sposób ukrywa swoje złośliwe działania, sprawiając, że wydaje się, iż localhost (podmiot zazwyczaj zaufany w środowisku serwera) wykonał te akcje. Serwer interpretuje część zapytania zaczynającą się od `%0d%0a` jako jeden parametr, podczas gdy parametr `restrictedaction` jest analizowany jako inny, oddzielny input. Manipulowane zapytanie skutecznie naśladuje legalne polecenie administracyjne: `/index.php?page=home&restrictedaction=edit`

 ### HTTP Response Splitting

 #### Opis

-HTTP Response Splitting to luka w zabezpieczeniach, która powstaje, gdy atakujący wykorzystuje strukturę odpowiedzi HTTP. Ta struktura oddziela nagłówki od treści za pomocą określonej sekwencji znaków, Carriage Return (CR) następnie Line Feed (LF), zbiorczo określane jako CRLF. Jeśli atakujący zdoła wstawić sekwencję CRLF do nagłówka odpowiedzi, może skutecznie manipulować treścią następnej odpowiedzi. Tego typu manipulacja może prowadzić do poważnych problemów z bezpieczeństwem, w szczególności Cross-site Scripting (XSS).
+HTTP Response Splitting to luka w zabezpieczeniach, która powstaje, gdy atakujący wykorzystuje strukturę odpowiedzi HTTP. Ta struktura oddziela nagłówki od treści za pomocą określonej sekwencji znaków, Carriage Return (CR) po którym następuje Line Feed (LF), zbiorczo określane jako CRLF. Jeśli atakujący zdoła wstawić sekwencję CRLF do nagłówka odpowiedzi, może skutecznie manipulować następną treścią odpowiedzi. Tego typu manipulacja może prowadzić do poważnych problemów z bezpieczeństwem, w szczególności Cross-site Scripting (XSS).

 #### XSS przez HTTP Response Splitting

 1. Aplikacja ustawia niestandardowy nagłówek w ten sposób: `X-Custom-Header: UserInput`
 2. Aplikacja pobiera wartość dla `UserInput` z parametru zapytania, powiedzmy "user_input". W scenariuszach, w których brakuje odpowiedniej walidacji i kodowania wejścia, atakujący może stworzyć ładunek, który zawiera sekwencję CRLF, a następnie złośliwą treść.
 3. Atakujący tworzy URL z specjalnie przygotowanym 'user_input': `?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>`
- W tym URL, `%0d%0a%0d%0a` jest URL-encoded formą CRLFCRLF. Oszukuje to serwer, aby wstawić sekwencję CRLF, sprawiając, że serwer traktuje następną część jako treść odpowiedzi.
+- W tym URL, `%0d%0a%0d%0a` jest zakodowaną formą CRLFCRLF. Oszukuje to serwer, aby wstawił sekwencję CRLF, sprawiając, że serwer traktuje następną część jako treść odpowiedzi.
 4. Serwer odzwierciedla wejście atakującego w nagłówku odpowiedzi, prowadząc do niezamierzonej struktury odpowiedzi, w której złośliwy skrypt jest interpretowany przez przeglądarkę jako część treści odpowiedzi.

 #### Przykład HTTP Response Splitting prowadzący do przekierowania
@ -68,15 +68,13 @@ Możesz wysłać ładunek **wewnątrz ścieżki URL**, aby kontrolować **odpowi
 http://stagecafrstore.starbucks.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
 http://stagecafrstore.starbucks.com/%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3E
 ```
-Sprawdź więcej przykładów w:
-
 {{#ref}}
 https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md
 {{#endref}}

 ### Wstrzykiwanie nagłówków HTTP

-Wstrzykiwanie nagłówków HTTP, często wykorzystywane poprzez wstrzykiwanie CRLF (Carriage Return and Line Feed), pozwala atakującym na wstawianie nagłówków HTTP. Może to podważyć mechanizmy zabezpieczeń, takie jak filtry XSS (Cross-Site Scripting) lub SOP (Same-Origin Policy), co potencjalnie prowadzi do nieautoryzowanego dostępu do wrażliwych danych, takich jak tokeny CSRF, lub manipulacji sesjami użytkowników poprzez osadzanie ciasteczek.
+Wstrzykiwanie nagłówków HTTP, często wykorzystywane poprzez wstrzykiwanie CRLF (Carriage Return and Line Feed), pozwala atakującym na wstawianie nagłówków HTTP. Może to osłabić mechanizmy zabezpieczeń, takie jak filtry XSS (Cross-Site Scripting) lub SOP (Same-Origin Policy), co potencjalnie prowadzi do nieautoryzowanego dostępu do wrażliwych danych, takich jak tokeny CSRF, lub manipulacji sesjami użytkowników poprzez osadzanie ciasteczek.

 #### Wykorzystywanie CORS poprzez wstrzykiwanie nagłówków HTTP

@ -84,7 +82,7 @@ Atakujący może wstrzykiwać nagłówki HTTP, aby włączyć CORS (Cross-Origin

 #### SSRF i wstrzykiwanie żądań HTTP poprzez CRLF

-Wstrzykiwanie CRLF może być wykorzystane do skonstruowania i wstrzyknięcia całkowicie nowego żądania HTTP. Znaczącym przykładem jest luka w klasie `SoapClient` w PHP, szczególnie w parametrze `user_agent`. Manipulując tym parametrem, atakujący może wstawić dodatkowe nagłówki i treść ciała, a nawet wstrzyknąć całkowicie nowe żądanie HTTP. Poniżej znajduje się przykład PHP demonstrujący to wykorzystanie:
+Wstrzykiwanie CRLF może być wykorzystane do skonstruowania i wstrzyknięcia całkowicie nowego żądania HTTP. Znaczącym przykładem tego jest luka w klasie `SoapClient` w PHP, szczególnie w parametrze `user_agent`. Manipulując tym parametrem, atakujący może wstawić dodatkowe nagłówki i treść ciała, a nawet wstrzyknąć całkowicie nowe żądanie HTTP. Poniżej znajduje się przykład PHP demonstrujący to wykorzystanie:
 ```php
 $target = 'http://127.0.0.1:9090/test';
 $post_string = 'variable=post value';
@ -109,7 +107,7 @@ array(
 # Put a netcat listener on port 9090
 $client->__soapCall("test", []);
 ```
-### Wstrzykiwanie nagłówków do przemycania żądań
+### Wstrzykiwanie nagłówków do oszustwa żądań

 Aby uzyskać więcej informacji na temat tej techniki i potencjalnych problemów [**sprawdź oryginalne źródło**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning).

@ -139,13 +137,13 @@ Memcache to **magazyn klucz-wartość, który używa protokołu tekstowego**. Wi

 **Aby uzyskać pełne informacje, przeczytaj**[ **oryginalny artykuł**](https://www.sonarsource.com/blog/zimbra-mail-stealing-clear-text-credentials-via-memcache-injection/)

-Jeśli platforma pobiera **dane z żądania HTTP i używa ich bez sanitizacji** do wykonywania **żądań** do serwera **memcache**, atakujący może wykorzystać to zachowanie do **wstrzykiwania nowych poleceń memcache**.
+Jeśli platforma pobiera **dane z żądania HTTP i używa ich bez sanitizacji** do wykonywania **żądań** do serwera **memcache**, atakujący może nadużyć tego zachowania, aby **wstrzyknąć nowe komendy memcache**.

-Na przykład, w pierwotnie odkrytej luce, klucze pamięci podręcznej były używane do zwracania adresu IP i portu, do którego użytkownik powinien się połączyć, a atakujący mogli **wstrzykiwać polecenia memcache**, które **zanieczyszczały** **pamięć podręczną, aby wysłać szczegóły ofiar** (w tym nazwy użytkowników i hasła) do serwerów atakującego:
+Na przykład, w pierwotnie odkrytej luce, klucze pamięci podręcznej były używane do zwracania adresu IP i portu, do którego użytkownik powinien się połączyć, a atakujący byli w stanie **wstrzyknąć komendy memcache**, które **zanieczyszczały** **pamięć podręczną, aby wysłać szczegóły ofiar** (w tym nazwy użytkowników i hasła) do serwerów atakującego:

 <figure><img src="../images/image (659).png" alt="https://assets-eu-01.kc-usercontent.com/d0f02280-9dfb-0116-f970-137d713003b6/ba72cd16-2ca0-447b-aa70-5cde302a0b88/body-578d9f9f-1977-4e34-841c-ad870492328f_10.png?w=1322&h=178&auto=format&fit=crop"><figcaption></figcaption></figure>

-Ponadto, badacze odkryli również, że mogą desynchronizować odpowiedzi memcache, aby wysłać adresy IP i porty atakującego do użytkowników, których e-mail atakujący nie znał:
+Co więcej, badacze odkryli również, że mogą desynchronizować odpowiedzi memcache, aby wysłać adresy IP i porty atakujących do użytkowników, których e-mail atakujący nie znał:

 <figure><img src="../images/image (637).png" alt="https://assets-eu-01.kc-usercontent.com/d0f02280-9dfb-0116-f970-137d713003b6/c6c1f3c4-d244-4bd9-93f7-2c88f139acfa/body-3f9ceeb9-3d6b-4867-a23f-e0e50a46a2e9_14.png?w=1322&h=506&auto=format&fit=crop"><figcaption></figcaption></figure>

@ -153,8 +151,8 @@ Ponadto, badacze odkryli również, że mogą desynchronizować odpowiedzi memca

 Aby zminimalizować ryzyko wstrzyknięć CRLF (Carriage Return and Line Feed) lub HTTP Header w aplikacjach internetowych, zaleca się następujące strategie:

-1. **Unikaj bezpośredniego wprowadzania danych od użytkownika w nagłówkach odpowiedzi:** Najbezpieczniejszym podejściem jest powstrzymanie się od włączania danych dostarczonych przez użytkownika bezpośrednio do nagłówków odpowiedzi.
-2. **Koduj znaki specjalne:** Jeśli unikanie bezpośredniego wprowadzania danych od użytkownika nie jest możliwe, upewnij się, że używasz funkcji dedykowanej do kodowania znaków specjalnych, takich jak CR (Carriage Return) i LF (Line Feed). Ta praktyka zapobiega możliwości wstrzyknięcia CRLF.
+1. **Unikaj bezpośredniego wprowadzania danych od użytkowników w nagłówkach odpowiedzi:** Najbezpieczniejszym podejściem jest powstrzymanie się od włączania danych dostarczonych przez użytkowników bezpośrednio do nagłówków odpowiedzi.
+2. **Koduj znaki specjalne:** Jeśli unikanie bezpośredniego wprowadzania danych od użytkowników nie jest możliwe, upewnij się, że używasz funkcji dedykowanej do kodowania znaków specjalnych, takich jak CR (Carriage Return) i LF (Line Feed). Ta praktyka zapobiega możliwości wstrzyknięcia CRLF.
 3. **Aktualizuj język programowania:** Regularnie aktualizuj język programowania używany w swoich aplikacjach internetowych do najnowszej wersji. Wybierz wersję, która z zasady zabrania wstrzykiwania znaków CR i LF w funkcjach odpowiedzialnych za ustawianie nagłówków HTTP.

 ### CHEATSHEET
@ -181,20 +179,57 @@ Aby zminimalizować ryzyko wstrzyknięć CRLF (Carriage Return and Line Feed) lu
 • %E5%98%BC = %3C = \u563c (<)
 • Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test
 ```
+### Ostatnie luki (2023 – 2025)
+
+Ostatnie kilka lat przyniosło kilka luk CRLF/HTTP header-injection o dużym wpływie w szeroko stosowanych komponentach po stronie serwera i klienta. Reprodukcja i badanie ich lokalnie to doskonały sposób na zrozumienie rzeczywistych wzorców eksploatacji.
+
+| Rok  | Komponent | CVE / Zawiadomienie | Przyczyna | Podkreślenie PoC |
+|------|-----------|---------------------|-----------|------------------|
+| 2024 | RestSharp (≥110.0.0 <110.2.0) | **CVE-2024-45302** | Pomocnik `AddHeader()` nie oczyszczał CR/LF, co pozwalało na konstrukcję wielu nagłówków żądania, gdy RestSharp był używany jako klient HTTP w usługach backendowych. Systemy downstream mogły być zmuszane do SSRF lub request smuggling. | `client.AddHeader("X-Foo","bar%0d%0aHost:evil")` |
+| 2024 | Refit (≤ 7.2.101) | **CVE-2024-51501** | Atrybuty nagłówków w metodach interfejsu były kopiowane dosłownie do żądania. Poprzez osadzenie `%0d%0a`, atakujący mogli dodać dowolne nagłówki lub nawet drugie żądanie, gdy Refit był używany przez zadania robocze po stronie serwera. | `[Headers("X: a%0d%0aContent-Length:0%0d%0a%0d%0aGET /admin HTTP/1.1")]` |
+| 2023 | Apache APISIX Dashboard | **GHSA-4h3j-f5x9-r6x3** | Parametr `redirect` dostarczony przez użytkownika był echoowany do nagłówka `Location:` bez kodowania, co umożliwiało otwarte przekierowanie + zanieczyszczenie pamięci podręcznej. | `/login?redirect=%0d%0aContent-Type:text/html%0d%0a%0d%0a<script>alert(1)</script>` |
+
+Te luki są ważne, ponieważ są wyzwalane **wewnątrz kodu na poziomie aplikacji** i nie tylko na krawędzi serwera WWW. Każdy wewnętrzny komponent, który wykonuje żądania HTTP lub ustawia nagłówki odpowiedzi, musi zatem egzekwować filtrowanie CR/LF.
+
+### Zaawansowane obejścia Unicode / znaków kontrolnych
+
+Nowoczesne stosy WAF/rewriter często usuwają dosłowne `\r`/`\n`, ale zapominają o innych znakach, które wiele backendów traktuje jako zakończenia linii. Gdy CRLF jest filtrowany, spróbuj:
+
+* `%E2%80%A8` (`U+2028` – SEPARATOR LINI)
+* `%E2%80%A9` (`U+2029` – SEPARATOR PARAGRAFU)
+* `%C2%85`  (`U+0085` – NEXT LINE)
+
+Niektóre frameworki Java, Python i Go konwertują je na `\n` podczas analizy nagłówków (zobacz badania Praetorian z 2023 roku). Połącz je z klasycznymi ładunkami:
+```
+/%0A%E2%80%A8Set-Cookie:%20admin=true
+```
+Jeśli filtr najpierw normalizuje UTF-8, znak kontrolny zostaje przekształcony w zwykły znak nowej linii, a wstrzyknięty nagłówek jest akceptowany.
+
+### WAF Evasion via Duplicate `Content-Encoding` Trick (2023)
+
+Badacze z Praetorian również pokazali, że poprzez wstrzyknięcie:
+```
+%0d%0aContent-Encoding:%20identity%0d%0aContent-Length:%2030%0d%0a
+```
+do nagłówka odzwierciedlonego, przeglądarki zignorują treść dostarczoną przez serwer i wyświetlą HTML dostarczony przez atakującego, co prowadzi do przechowywanego XSS, nawet gdy własna zawartość aplikacji jest nieaktywna. Ponieważ `Content-Encoding: identity` jest dozwolone przez RFC 9110, wiele reverse-proxy przesyła je bez zmian.
+
 ## Narzędzia automatyczne

- [https://github.com/Raghavd3v/CRLFsuite](https://github.com/Raghavd3v/CRLFsuite)
- [https://github.com/dwisiswant0/crlfuzz](https://github.com/dwisiswant0/crlfuzz)
+* [CRLFsuite](https://github.com/Raghavd3v/CRLFsuite) – szybki aktywny skaner napisany w Go.
+* [crlfuzz](https://github.com/dwisiswant0/crlfuzz) – fuzzer oparty na liście słów, który obsługuje ładunki nowej linii Unicode.
+* [crlfix](https://github.com/glebarez/crlfix) – narzędzie z 2024 roku, które poprawia żądania HTTP generowane przez programy Go i może być używane samodzielnie do testowania usług wewnętrznych.

 ## Lista wykrywania brute-force

- [https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt](https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt)
+- [carlospolop/Auto_Wordlists – crlf.txt](https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt)

 ## Odniesienia

- [**https://www.invicti.com/blog/web-security/crlf-http-header/**](https://www.invicti.com/blog/web-security/crlf-http-header/)
- [**https://www.acunetix.com/websitesecurity/crlf-injection/**](https://www.acunetix.com/websitesecurity/crlf-injection/)
- [**https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning)
- [**https://www.netsparker.com/blog/web-security/crlf-http-header/**](https://www.netsparker.com/blog/web-security/crlf-http-header/)
+- [https://www.invicti.com/blog/web-security/crlf-http-header/](https://www.invicti.com/blog/web-security/crlf-http-header/)
+- [https://www.acunetix.com/websitesecurity/crlf-injection/](https://www.acunetix.com/websitesecurity/crlf-injection/)
+- [https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning)
+- [https://www.netsparker.com/blog/web-security/crlf-http-header/](https://www.netsparker.com/blog/web-security/crlf-http-header/)
+- [https://nvd.nist.gov/vuln/detail/CVE-2024-45302](https://nvd.nist.gov/vuln/detail/CVE-2024-45302)
+- [https://security.praetorian.com/blog/2023-unicode-newlines-bypass/](https://security.praetorian.com/blog/2023-unicode-newlines-bypass/)

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