<summary><strong>Naucz się hakować AWS od zera do bohatera z</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLANY SUBSKRYPCYJNE**](https://github.com/sponsors/carlospolop)!
* **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.
Dołącz do serwera [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy), aby komunikować się z doświadczonymi hakerami i łowcami nagród za błędy!
**Cross-Site Request Forgery (CSRF)** to rodzaj podatności na bezpieczeństwo występującej w aplikacjach internetowych. Umożliwia atakującym wykonywanie działań w imieniu niewiedzących użytkowników, wykorzystując ich uwierzytelnione sesje. Atak jest wykonywany, gdy użytkownik zalogowany na platformie ofiary odwiedza złośliwą witrynę. Następnie ta witryna wywołuje żądania do konta ofiary za pomocą metod takich jak wykonanie JavaScriptu, przesłanie formularzy lub pobranie obrazów.
1.**Zidentyfikuj Cenną Akcję**: Atakujący musi znaleźć akcję warta 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ą plików cookie lub nagłówka uwierzytelniania podstawowego HTTP, 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 **przechwycić żądanie w Burp** i sprawdzić zabezpieczenia CSRF oraz przetestować z przeglądarki, klikając na **Kopiuj jako fetch** i sprawdzając żądanie:
* [**Pliki cookie SameSite**](hacking-with-cookies/#samesite): Ta atrybut zapobiega przesyłaniu plików cookie przez przeglądarkę wraz z żądaniami między witrynami. [Więcej o plikach cookie SameSite](hacking-with-cookies/#samesite).
* [**Współdzielenie zasobów między domenami**](cors-bypass.md): Polityka CORS witryny ofiary może wpłynąć na wykonalność ataku, zwłaszcza jeśli atak wymaga odczytu odpowiedzi z witryny ofiary. [Dowiedz się więcej o omijaniu CORS](cors-bypass.md).
* **Weryfikacja Użytkownika**: Wymaganie podania hasła 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 w zapewnieniu, że żądania pochodzą od zaufanych źródeł. Jednak staranne tworzenie adresów URL może obejść słabo zaimplementowane sprawdzenia, takie jak:
* Użycie `http://mal.net?orig=http://example.com` (URL kończy się zaufanym adresem URL)
* Użycie `http://example.com.mal.net` (URL zaczyna się od zaufanego adresu URL)
* **Modyfikacja Nazw Parametrów**: Zmiana nazw parametrów w żądaniach POST lub GET może pomóc w zapobieganiu automatycznym atakom.
* **Tokeny CSRF**: Włączenie unikalnego tokenu CSRF w każdej sesji i wymaganie tego tokenu w kolejnych żądaniach może znacząco zmniejszyć ryzyko CSRF. Skuteczność tokenu można zwiększyć, wymuszając CORS.
Być może formularz, który chcesz wykorzystać, jest przygotowany do wysł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 jest wciąż weryfikowany**.
Aplikacje mogą wdrożyć mechanizm **weryfikacji tokenów**, gdy są obecne. Jednak pojawia się podatność, jeśli walidacja jest pomijana całkowicie, gdy token jest nieobecny. Atakujący mogą wykorzystać to, **usuwać parametr**, który przenosi token, a nie tylko jego wartość. Pozwala to im ominąć proces walidacji i skutecznie przeprowadzić atak typu Cross-Site Request Forgery (CSRF).
Aplikacje **niepowiązujące tokenów CSRF z sesjami użytkowników** stanowią znaczne **ryzyko bezpieczeństwa**. Te systemy weryfikują tokeny w oparciu o **globalny pulpit** zamiast zapewniać, że każdy token jest związany z sesją inicjującą.
Ta podatność pozwala atakującym na dokonywanie nieautoryzowanych żądań w imieniu ofiary, wykorzystując **niewystarczający mechanizm walidacji tokenów aplikacji**.
Jeśli żądanie używa "**dziwnej**" **metody**, sprawdź, czy funkcjonalność **nadpisywania 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 poprzez duplikowanie tokenu zarówno w pliku cookie, jak i parametrze żądania lub poprzez ustawienie pliku cookie CSRF i weryfikację, czy token wysłany w backendzie odpowiada plikowi cookie. Aplikacja weryfikuje żądania, sprawdzając, czy token w parametrze żądania zgadza się z wartością w pliku cookie.
Jednak ta metoda jest podatna na ataki CSRF, jeśli strona internetowa ma wady pozwalające atakującemu na ustawienie pliku cookie CSRF w przeglądarce ofiary, takie jak podatność CRLF. Atakujący mogą wykorzystać to, ładując wprowadzający w błąd obraz, który ustawia plik cookie, a następnie rozpoczynając atak CSRF.
Poniżej znajduje się przykład, jak można zbudować atak:
Zauważ, że jeśli **token csrf jest powiązany z ciasteczkiem sesji, ten atak nie zadziała**, ponieważ będziesz musiał ustawić ofierze swoją sesję, a więc będziesz atakować siebie.
Zgodnie z [**tym**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests), aby **uniknąć żądań wstępnych** przy użyciu metody **POST**, dozwolone są następujące wartości typu zawartości:
Jednak zauważ, że **logika serwera może się różnić** w zależności od użytego **typu zawartości**, dlatego powinieneś wypróbować wymienione wartości oraz inne, takie 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 zawartości inicjuje żądanie wstępne. Niemniej jednak istnieją strategie, aby potencjalnie ominąć to ograniczenie i sprawdzić, czy serwer przetwarza dane JSON niezależnie od Content-Type:
1.**Użyj alternatywnych typów zawartości**: Wykorzystaj `Content-Type: text/plain` lub `Content-Type: application/x-www-form-urlencoded`, ustawiając `enctype="text/plain"` w formularzu. Ten sposób testuje, czy serwer używa danych bez względu na Content-Type.
2.**Zmodyfikuj typ zawartości**: Aby uniknąć żądania wstępnego, jednocześnie zapewniając, że serwer rozpoznaje zawartość jako JSON, możesz wysłać dane z `Content-Type: text/plain; application/json`. To nie powoduje żądania wstępnego, ale może być poprawnie przetworzone przez serwer, jeśli jest skonfigurowany do akceptowania `application/json`.
3.**Wykorzystanie pliku SWF Flash**: Mniej popularna, ale możliwa metoda polega na użyciu pliku SWF flash do ominięcia takich ograniczeń. Aby uzyskać dogłębną wiedzę na temat tej techniki, zapoznaj się z [tym postem](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
Aplikacje mogą sprawdzać nagłówek 'Referer' tylko wtedy, gdy jest obecny. Aby uniemożliwić przeglądarce wysłanie tego nagłówka, 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 Oak](https://github.com/oakserver/oak/blob/main/router.ts#L281), router jest ustawiony do **obsługi żądań HEAD jako żądań GET** bez ciała odpowiedzi - powszechne obejście, które nie jest unikalne dla Oak. Zamiast konkretnego obsługującego, który zajmuje się żądaniami HEAD, są one po prostu **przekazywane do obsługującego GET, ale aplikacja po prostu usuwa ciało odpowiedzi**.
Jeśli **token CSRF** jest używany jako **obrona**, można spróbować go **wyciec** wykorzystując podatność [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) lub podatność [**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 Brut Force formularza logowania przy użyciu tokenu CSRF (Wykorzystuje również nagłówek X-Forwarded-For w celu próby obejścia ewentualnego czarnolistowania adresów IP):
<summary><strong>Dowiedz się, jak hakować AWS od zera do bohatera z</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLANY SUBSKRYPCYJNE**](https://github.com/sponsors/carlospolop)!
* **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.