Ucz się i ćwicz Hacking AWS:<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">\
Ucz się i ćwicz Hacking GCP: <imgsrc="../.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="../.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Podziel się trikami hackingowymi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repozytoriów na githubie.
**Cross-Site Request Forgery (CSRF)** to rodzaj luki w zabezpieczeniach, która występuje w aplikacjach internetowych. Umożliwia atakującym wykonywanie działań w imieniu nieświadomych użytkowników, wykorzystując ich uwierzytelnione sesje. Atak jest realizowany, gdy użytkownik, który jest zalogowany na platformie ofiary, odwiedza złośliwą stronę. Strona ta następnie wywołuje żądania do konta ofiary za pomocą metod takich jak wykonywanie JavaScript, przesyłanie formularzy lub pobieranie obrazów.
1.**Zidentyfikuj cenną akcję**: Atakujący musi znaleźć akcję wartą wykorzystania, taką jak zmiana hasła użytkownika, adresu e-mail lub podniesienie uprawnień.
2.**Zarządzanie sesją**: Sesja użytkownika powinna być zarządzana wyłącznie za pomocą ciasteczek lub nagłówka HTTP Basic Authentication, ponieważ inne nagłówki nie mogą być manipulowane w tym celu.
3.**Brak nieprzewidywalnych parametrów**: Żądanie nie powinno zawierać nieprzewidywalnych parametrów, ponieważ mogą one uniemożliwić atak.
Możesz **złapać żądanie w Burp** i sprawdzić zabezpieczenia CSRF, a aby przetestować z przeglądarki, możesz kliknąć **Kopiuj jako fetch** i sprawdzić żądanie:
* [**Ciasteczka SameSite**](hacking-with-cookies/#samesite): Atrybut ten zapobiega przeglądarce w wysyłaniu ciasteczek wraz z żądaniami między witrynami. [Więcej o ciasteczkach SameSite](hacking-with-cookies/#samesite).
* [**Udostępnianie zasobów między źródłami**](cors-bypass.md): Polityka CORS witryny ofiary może wpływać na wykonalność ataku, szczególnie jeśli atak wymaga odczytania odpowiedzi z witryny ofiary. [Dowiedz się o obejściu CORS](cors-bypass.md).
* **Weryfikacja użytkownika**: Prośba o hasło użytkownika lub rozwiązanie captcha może potwierdzić intencje 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 konstruowanie adresów URL może obejść źle wdrożone kontrole, takie jak:
* **Modyfikacja nazw parametrów**: Zmiana nazw parametrów w żądaniach POST lub GET może pomóc w zapobieganiu zautomatyzowanym atakom.
* **Tokeny CSRF**: Wprowadzenie unikalnego tokena CSRF w każdej sesji i wymaganie tego tokena w kolejnych żądaniach może znacznie zmniejszyć ryzyko CSRF. Skuteczność tokena można zwiększyć, egzekwując CORS.
Może się zdarzyć, że formularz, który chcesz wykorzystać, jest przygotowany do wysyłania **żądania POST z tokenem CSRF, ale** powinieneś **sprawdzić**, czy **GET** jest również **ważny** i czy podczas wysyłania żądania GET **token CSRF nadal jest weryfikowany**.
Aplikacje mogą wdrożyć mechanizm do **walidacji tokenów**, gdy są obecne. Jednak luka powstaje, jeśli walidacja jest całkowicie pomijana, gdy token jest nieobecny. Atakujący mogą to wykorzystać, **usuwając parametr**, który przenosi token, a nie tylko jego wartość. Pozwala to na ominięcie procesu walidacji i skuteczne przeprowadzenie ataku Cross-Site Request Forgery (CSRF).
Aplikacje **niepowiązujące tokenów CSRF z sesjami użytkowników** stanowią znaczące **ryzyko bezpieczeństwa**. Te systemy weryfikują tokeny w stosunku do **globalnej puli**, zamiast zapewnić, że każdy token jest związany z inicjującą sesją.
Ta luka pozwala atakującym na składanie nieautoryzowanych żądań w imieniu ofiary, wykorzystując **niewystarczający mechanizm walidacji tokenów** aplikacji.
Jeśli żądanie używa "**dziwnej**" **metody**, sprawdź, czy funkcjonalność **przełamywania metody** działa. 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**_
Aplikacje mogą wdrożyć ochronę CSRF, duplikując token zarówno w ciasteczku, jak i w parametrze żądania lub ustawiając ciasteczko CSRF i weryfikując, czy token wysłany w backendzie odpowiada wartości w ciasteczku. Aplikacja weryfikuje żądania, sprawdzając, czy token w parametrze żądania zgadza się z wartością w ciasteczku.
Jednak ta metoda jest podatna na ataki CSRF, jeśli witryna ma luki pozwalające atakującemu na ustawienie ciasteczka CSRF w przeglądarce ofiary, takie jak luka CRLF. Atakujący mogą to wykorzystać, ładując zwodniczy obraz, który ustawia ciasteczko, a następnie inicjując atak CSRF.
Zauważ, że jeśli **token csrf jest powiązany z ciasteczkiem sesji, ta atak nie zadziała**, ponieważ będziesz musiał ustawić sesję ofiary, a tym samym będziesz atakować siebie.
Zgodnie z [**tym**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests), aby **uniknąć zapytań preflight** używając metody **POST**, dozwolone wartości Content-Type to:
Jednakże, zauważ, że **logika serwera może się różnić** w zależności od używanego **Content-Type**, więc powinieneś spróbować wymienionych wartości oraz innych, takich jak **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._
Podczas próby wysłania danych JSON za pomocą żądania POST, użycie `Content-Type: application/json` w formularzu HTML nie jest bezpośrednio możliwe. Podobnie, wykorzystanie `XMLHttpRequest` do wysłania tego typu treści inicjuje żądanie wstępne. Niemniej jednak, istnieją strategie, które mogą potencjalnie obejść to ograniczenie i sprawdzić, czy serwer przetwarza dane JSON niezależnie od Content-Type:
1.**Użyj alternatywnych typów treści**: Zastosuj `Content-Type: text/plain` lub `Content-Type: application/x-www-form-urlencoded`, ustawiając `enctype="text/plain"` w formularzu. To podejście testuje, czy backend wykorzystuje dane niezależnie od Content-Type.
2.**Zmień typ treści**: Aby uniknąć żądania wstępnego, zapewniając jednocześnie, że serwer rozpoznaje treść jako JSON, możesz wysłać dane z `Content-Type: text/plain; application/json`. To nie wywołuje żądania wstępnego, ale może być poprawnie przetwarzane przez serwer, jeśli jest skonfigurowany do akceptacji `application/json`.
3.**Wykorzystanie pliku SWF Flash**: Mniej powszechny, ale wykonalny sposób polega na użyciu pliku SWF flash, aby obejść takie ograniczenia. Aby uzyskać szczegółowe informacje na temat tej techniki, zapoznaj się z [tym postem](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
Aplikacje mogą weryfikować nagłówek 'Referer' tylko wtedy, gdy jest obecny. Aby zapobiec wysyłaniu tego nagłówka przez przeglądarkę, można użyć następującego tagu meta HTML:
Pierwsza część [**tego opisu CTF**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) wyjaśnia, że [kod źródłowy Oaka](https://github.com/oakserver/oak/blob/main/router.ts#L281), router jest ustawiony na **obsługę żądań HEAD jako żądań GET** bez ciała odpowiedzi - powszechne obejście, które nie jest unikalne dla Oaka. Zamiast konkretnego handlera, który zajmuje się żądaniami HEAD, są one po prostu **przekazywane do handlera GET, ale aplikacja po prostu usuwa ciało odpowiedzi**.
Jeśli **token CSRF** jest używany jako **ochrona**, możesz spróbować **ekstrahować go**, wykorzystując lukę [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) lub lukę [**Dangling Markup**](dangling-markup-html-scriptless-injection/).
xh.setRequestHeader('Content-type', 'application/x-www-form-urlencoded'); //to send proper header info (optional, but good to have as it may sometimes not work without this)
Kod może być użyty do przeprowadzenia ataku brute force na formularz logowania z użyciem tokena CSRF (używa również nagłówka X-Forwarded-For, aby spróbować obejść ewentualne czarne listy IP):
Ucz się i ćwicz Hacking AWS:<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">\
Ucz się i ćwicz Hacking GCP: <imgsrc="../.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="../.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Dziel się trikami hackingowymi, przesyłając PR-y do repozytoriów** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).