HTTP Request Smuggling / HTTP Desync Attack
Last updated
Last updated
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
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.
Jeśli wiadomość jest odbierana z zarówno polem nagłówka Transfer-Encoding, jak i polem nagłówka Content-Length, to to drugie MUSI być zignorowane.
Content-Length
Nagłówek Content-Length wskazuje rozmiar ciała encji, w bajtach, wysłanego do odbiorcy.
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.
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-gie wstrzyknięte żądanie tak, jakby pochodziło od następnego klienta, a prawdziwe żądanie tego klienta będzie częścią wstrzykniętego żądania.
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, znak nowej linii nie jest potrzebny na końcu żądania.
Transfer-Encoding: Ten nagłówek używa w ciele liczby szesnastkowej do wskazania liczby bajtów następnego kawałka. Kawałek musi kończyć się znakiem nowej linii, ale ten nowy znak nie jest liczony przez wskaźnik długości. Ta metoda transferu musi kończyć się kawałkiem o rozmiarze 0, po którym następują 2 nowe linie: 0
Connection: Na podstawie mojego doświadczenia zaleca się użycie Connection: keep-alive w pierwszym żądaniu w request Smuggling.
Próbując wykorzystać to z Burp Suite wyłącz Update Content-Length i Normalize HTTP/1 line endings w repeaterze, ponieważ niektóre gadżety nadużywają nowych linii, powrotów karetki i źle sformułowanych długości treści.
Ataki HTTP request smuggling są tworzone poprzez wysyłanie niejednoznacznych żądań, które wykorzystują różnice w tym, jak serwery front-end i back-end interpretują nagłówki Content-Length (CL) i Transfer-Encoding (TE). Ataki te mogą manifestować się w różnych formach, głównie jako CL.TE, TE.CL i TE.TE. Każdy typ reprezentuje unikalną kombinację tego, jak serwery front-end i back-end priorytetują te nagłówki. Luka powstaje, gdy serwery przetwarzają to samo żądanie w różny sposób, prowadząc do nieoczekiwanych i potencjalnie złośliwych skutków.
Do poprzedniej tabeli powinieneś dodać technikę TE.0, jak technikę CL.0, ale używając Transfer Encoding.
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.
Przykład:
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.
Przykład:
Serwery: Oba wspierają Transfer-Encoding, ale jeden może być oszukany, aby go zignorować poprzez obfuscację.
Scenariusz ataku:
Atakujący wysyła żądanie z obfuscowanymi nagłówkami Transfer-Encoding.
W zależności od tego, który serwer (front-end lub back-end) nie rozpozna obfuscacji, może zostać wykorzystana luka CL.TE lub TE.CL.
Niezrealizowana część żądania, widziana przez jeden z serwerów, staje się częścią następnego żądania, prowadząc do smugglingu.
Przykład:
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.
Przykład:
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.
Przykład:
Podobnie jak poprzedni, ale używając TE.
Technika zgłoszona tutaj
Przykład:
Ta technika jest również przydatna w scenariuszach, w których możliwe jest złamanie serwera WWW podczas odczytywania początkowych danych HTTP, ale bez zamykania połączenia. W ten sposób ciało żądania HTTP będzie traktowane jako następne żądanie HTTP.
Na przykład, jak wyjaśniono w tym opisie, 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.
Wykorzystując nagłówki hop-by-hop, można wskazać proxy, aby usunęło nagłówek Content-Length lub Transfer-Encoding, aby możliwe było nadużycie HTTP request smuggling.
For więcej informacji o nagłówkach hop-by-hop odwiedź:
hop-by-hop headersIdentyfikacja 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:
Metoda:
Wyślij żądanie, które, jeśli aplikacja jest podatna, spowoduje, że serwer zaplecza będzie czekał na dodatkowe dane.
Przykład:
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.
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.
Metoda:
Wyślij żądanie, które, jeśli aplikacja jest podatna, spowoduje, że serwer zaplecza będzie czekał na dodatkowe dane.
Przykład:
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.
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:
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.
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.
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 pokazują, jak zainfekować żądanie klienta, aby wywołać odpowiedź 404, mimo że klient dążył do uzyskania dostępu do innego zasobu.
Kluczowe uwagi
Podczas testowania podatności na request smuggling poprzez zakłócanie innych żądań, pamiętaj o:
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.
Warunków czasowych i wyścigowych: "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 ostatecznego potwierdzenia podatności.
Wyzwania związane 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ść.
Niezamierzony wpływ na użytkowników: Jeśli twój atak niezamierzenie wpływa na żądanie innego użytkownika (nie "normalne" żądanie, które wysłałeś w celu wykrycia), wskazuje 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.
Czasami proxy front-end wprowadza środki bezpieczeństwa, analizując przychodzące żądania. Jednak te środki mogą być obejście poprzez wykorzystanie HTTP Request Smuggling, co pozwala na nieautoryzowany dostęp do zastrzeżonych punktów końcowych. Na przykład, dostęp do /admin może być zabroniony z zewnątrz, a proxy front-end aktywnie blokuje takie próby. Niemniej jednak, to proxy może zaniedbać sprawdzenie osadzonych żądań w ramach przemyconego żądania HTTP, pozostawiając lukę do ominięcia tych ograniczeń.
Rozważ następujące przykłady ilustrujące, jak HTTP Request Smuggling może być używane do ominięcia zabezpieczeń front-end, szczególnie celując w ścieżkę /admin, która jest zazwyczaj chroniona przez proxy front-end:
Przykład CL.TE
W ataku CL.TE nagłówek Content-Length jest wykorzystywany w początkowym żądaniu, podczas gdy osadzone żądanie wykorzystuje nagłówek Transfer-Encoding: chunked. Proxy front-end przetwarza początkowe żądanie POST, ale nie sprawdza osadzonego żądania GET /admin, co pozwala na nieautoryzowany dostęp do ścieżki /admin.
TE.CL Przykład
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.
Aplikacje często wykorzystują serwer front-endowy do modyfikacji przychodzących żądań przed ich przekazaniem do serwera back-endowego. Typowa modyfikacja polega na dodawaniu nagłówków, takich jak X-Forwarded-For: <IP klienta>, aby przekazać IP klienta do back-endu. Zrozumienie tych modyfikacji może być kluczowe, ponieważ może ujawnić sposoby na obejście zabezpieczeń lub ujawnienie ukrytych informacji lub punktów końcowych.
Aby zbadać, jak proxy zmienia żądanie, zlokalizuj parametr POST, który 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:
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.
Ważne jest, aby dostosować nagłówek Content-Length zagnieżdżonego żądania do rzeczywistej długości treści. Zaleca się rozpoczęcie od małej wartości i stopniowe zwiększanie, ponieważ zbyt niska wartość obetnie odzwierciedlone dane, podczas gdy zbyt wysoka wartość może spowodować błąd żądania.
Ta technika ma również zastosowanie w kontekście podatności TE.CL, ale żądanie powinno kończyć się na search=\r\n0. Niezależnie od znaków nowej linii, wartości będą dołączane do parametru wyszukiwania.
Metoda ta służy głównie do zrozumienia modyfikacji żądania dokonywanych przez proxy front-end, zasadniczo przeprowadzając samodzielne dochodzenie.
Możliwe jest przechwycenie żądań następnego użytkownika, dołączając konkretne żądanie jako wartość parametru podczas operacji POST. Oto jak można to osiągnąć:
Dołączając następujące żądanie jako wartość parametru, możesz przechować żądanie kolejnego klienta:
W tym scenariuszu, parametr komentarza ma na celu przechowywanie treści w sekcji komentarzy posta na publicznie dostępnym stronie. W związku z tym, zawartość kolejnego żądania pojawi się jako komentarz.
Jednak ta technika ma ograniczenia. Zazwyczaj przechwytuje dane tylko do ogranicznika parametru używanego w przemycanym żądaniu. Dla 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.
Dodatkowo, warto zauważyć, że podejście to jest również wykonalne w przypadku podatności TE.CL. W takich przypadkach, żądanie powinno kończyć się na search=\r\n0. Niezależnie od znaków nowej linii, wartości będą dodawane do parametru wyszukiwania.
Przemycanie żądań HTTP może być wykorzystane do eksploatacji stron internetowych podatnych na odzwierciedlone XSS, oferując znaczące 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.
W scenariuszach, w których strona internetowa jest podatna na odzwierciedlone XSS poprzez nagłówek User-Agent, poniższy ładunek demonstruje, jak wykorzystać tę podatność:
Ten ładunek jest skonstruowany w celu wykorzystania luki poprzez:
Inicjowanie żądania POST, które wydaje się typowe, z nagłówkiem Transfer-Encoding: chunked, aby wskazać początek smugglingu.
Następnie, po nim, pojawia się 0, oznaczające koniec ciała wiadomości chunked.
Następnie wprowadzane jest smuggled GET żądanie, w którym nagłówek User-Agent jest wstrzykiwany z skryptem, <script>alert(1)</script>, co wywołuje XSS, gdy serwer przetwarza to kolejne żądanie.
Manipulując User-Agent poprzez smuggling, ładunek omija normalne ograniczenia żądań, wykorzystując w ten sposób lukę Reflected XSS w niestandardowy, ale skuteczny sposób.
W przypadku, gdy zawartość użytkownika jest odzwierciedlana w odpowiedzi z Content-type takim jak text/plain, co uniemożliwia wykonanie XSS. Jeśli serwer obsługuje HTTP/0.9, może być możliwe ominięcie tego!
Wersja HTTP/0.9 była wcześniejsza od 1.0 i używa tylko czasowników GET oraz nie odpowiada z nagłówkami, tylko ciałem.
W tym opisie to zostało nadużyte z wykorzystaniem smugglingu żądań i wrażliwego punktu końcowego, który odpowiada na dane użytkownika, aby smuggled żądanie z HTTP/0.9. Parametr, który będzie odzwierciedlany w odpowiedzi, zawierał fałszywą odpowiedź HTTP/1.1 (z nagłówkami i ciałem), więc odpowiedź będzie zawierać ważny wykonawczy kod JS z Content-Type równym text/html.
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:
Wyniki w:
Choć na pozór nieszkodliwe, to zachowanie można wykorzystać za pomocą HTTP request smuggling do przekierowywania użytkowników na zewnętrzną stronę. Na przykład:
Ten przemycony żądanie może spowodować, że następne przetworzone żądanie użytkownika zostanie przekierowane na stronę kontrolowaną przez atakującego:
Wyniki w:
W tym scenariuszu żądanie użytkownika dotyczące pliku JavaScript jest przechwytywane. Atakujący może potencjalnie skompromitować użytkownika, dostarczając złośliwy JavaScript w odpowiedzi.
Zatrucie pamięci podręcznej w sieci może być zrealizowane, jeśli jakikolwiek komponent infrastruktury front-endowej buforuje treści, zazwyczaj w celu poprawy wydajności. Manipulując odpowiedzią serwera, możliwe jest zatrucie pamięci podręcznej.
Wcześniej zaobserwowaliśmy, jak odpowiedzi serwera mogą być zmieniane, aby zwracały błąd 404 (zobacz Podstawowe przykłady). Podobnie, możliwe jest oszukanie serwera, aby dostarczył treść /index.html w odpowiedzi na żądanie dotyczące /static/include.js. W konsekwencji treść /static/include.js zostaje zastąpiona w pamięci podręcznej treścią /index.html, co sprawia, że /static/include.js staje się niedostępne dla użytkowników, co potencjalnie prowadzi do Denial of Service (DoS).
Technika ta staje się szczególnie potężna, jeśli zostanie odkryta vulnerabilność Open Redirect lub jeśli istnieje przekierowanie na stronie do otwartego przekierowania. Takie luki mogą być wykorzystywane do zastąpienia buforowanej treści /static/include.js skryptem kontrolowanym przez atakującego, co zasadniczo umożliwia szeroką atak Cross-Site Scripting (XSS) przeciwko wszystkim klientom żądającym zaktualizowanego /static/include.js.
Poniżej znajduje się ilustracja wykorzystywania zatrucia pamięci podręcznej w połączeniu z przekierowaniem na stronie do otwartego przekierowania. Celem jest zmiana treści pamięci podręcznej /static/include.js, aby dostarczyć kod JavaScript kontrolowany przez atakującego:
Zauważ osadzony żądanie skierowane do /post/next?postId=3. To żądanie zostanie przekierowane do /post?postId=4, wykorzystując wartość nagłówka Host do określenia domeny. Zmieniając nagłówek Host, atakujący może przekierować żądanie do swojej domeny (przekierowanie na miejscu do otwartego przekierowania).
Po udanym zatruciu gniazda, powinno zostać zainicjowane żądanie GET dla /static/include.js. To żądanie zostanie zanieczyszczone przez wcześniejsze przekierowanie na miejscu do otwartego przekierowania i pobierze zawartość skryptu kontrolowanego przez atakującego.
Następnie każde żądanie dla /static/include.js będzie serwować pamiętaną zawartość skryptu atakującego, skutecznie uruchamiając szeroką akcję XSS.
Jaka jest różnica między zatruciem pamięci podręcznej a oszustwem w pamięci podręcznej?
W zatruciu pamięci podręcznej, atakujący powoduje, że aplikacja przechowuje w pamięci podręcznej złośliwą zawartość, a ta zawartość jest serwowana z pamięci podręcznej innym użytkownikom aplikacji.
W oszustwie w pamięci podręcznej, atakujący powoduje, że aplikacja przechowuje w pamięci podręcznej wrażliwą zawartość należącą do innego użytkownika, a następnie atakujący pobiera tę zawartość z pamięci podręcznej.
Atakujący tworzy przemyślane żądanie, które pobiera wrażliwą zawartość specyficzną dla użytkownika. Rozważ następujący przykład:
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.
W tym poście 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:
Będzie wysyłać odpowiedź taką jak:
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.
Kontynuując ten post, sugeruje się inny sposób wykorzystania metody TRACE. Jak wspomniano, przemycając żądanie HEAD i żądanie TRACE, możliwe jest kontrolowanie niektórych odzwierciedlonych danych w odpowiedzi na żądanie HEAD. Długość ciała żądania HEAD jest zasadniczo wskazywana w nagłówku Content-Length i jest tworzona przez odpowiedź na żądanie TRACE.
Dlatego nowy pomysł polega 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).
Przykład:
Wygeneruje te odpowiedzi (zauważ, że 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):
Czy znalazłeś jakąś podatność na HTTP Request Smuggling i nie wiesz, jak ją wykorzystać? Spróbuj tych innych metod eksploatacji:
HTTP Response Smuggling / DesyncHTTP Request Smuggling w przeglądarkach (strona klienta)
Request Smuggling w downgrade'ach HTTP/2
Z https://hipotermia.pw/bb/http-desync-idor
Z: https://hipotermia.pw/bb/http-desync-account-takeover
https://github.com/bahruzjabiyev/t-reqs-http-fuzzer: To narzędzie to gramatyczny HTTP Fuzzer przydatny do znajdowania dziwnych rozbieżności w request smuggling.
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
