# CSRF (Cross Site Request Forgery)
{% hint style="success" %}
Learn & practice AWS Hacking:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\
Learn & practice GCP Hacking: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Support HackTricks
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
{% endhint %}
Join [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) server to communicate with experienced hackers and bug bounty hunters!
**Hacking Insights**\
Engage with content that delves into the thrill and challenges of hacking
**Real-Time Hack News**\
Keep up-to-date with fast-paced hacking world through real-time news and insights
**Latest Announcements**\
Stay informed with the newest bug bounties launching and crucial platform updates
**Join us on** [**Discord**](https://discord.com/invite/N3FrSbmwdy) and start collaborating with top hackers today!
## Cross-Site Request Forgery (CSRF) Explained
**Cross-Site Request Forgery (CSRF)** to rodzaj luki w zabezpieczeniach występującej 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.
### Prerequisites for a CSRF Attack
Aby wykorzystać lukę CSRF, musi być spełnionych kilka warunków:
1. **Identify a Valuable Action**: Atakujący musi znaleźć działanie warte wykorzystania, takie jak zmiana hasła użytkownika, adresu e-mail lub podniesienie uprawnień.
2. **Session Management**: 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. **Absence of Unpredictable Parameters**: Żądanie nie powinno zawierać nieprzewidywalnych parametrów, ponieważ mogą one uniemożliwić atak.
### Quick Check
Możesz **złapać żądanie w Burp** i sprawdzić zabezpieczenia CSRF, a aby przetestować z przeglądarki, możesz kliknąć **Copy as fetch** i sprawdzić żądanie:
### Defending Against CSRF
Można wdrożyć kilka środków zaradczych, aby chronić przed atakami CSRF:
* [**SameSite cookies**](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).
* [**Cross-origin resource sharing**](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).
* **User Verification**: Prośba o hasło użytkownika lub rozwiązanie captcha może potwierdzić intencje użytkownika.
* **Checking Referrer or Origin Headers**: Walidacja tych nagłówków może pomóc zapewnić, że żądania pochodzą z zaufanych źródeł. Jednak staranne konstruowanie adresów URL może obejść źle wdrożone kontrole, takie jak:
* Użycie `http://mal.net?orig=http://example.com` (adres URL kończy się zaufanym adresem URL)
* Użycie `http://example.com.mal.net` (adres URL zaczyna się zaufanym adresem URL)
* **Modifying Parameter Names**: Zmiana nazw parametrów w żądaniach POST lub GET może pomóc w zapobieganiu zautomatyzowanym atakom.
* **CSRF Tokens**: 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.
Zrozumienie i wdrożenie tych zabezpieczeń jest kluczowe dla utrzymania bezpieczeństwa i integralności aplikacji internetowych.
## Defences Bypass
### From POST to GET
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**.
### Lack of token
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ść. Umożliwia to obejście procesu walidacji i skuteczne przeprowadzenie ataku Cross-Site Request Forgery (CSRF).
### CSRF token is not tied to the user session
Aplikacje **niewią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 zapewniać, że każdy token jest powiązany z inicjującą sesją.
Oto jak atakujący to wykorzystują:
1. **Authenticate** używając swojego konta.
2. **Obtain a valid CSRF token** z globalnej puli.
3. **Use this token** w ataku CSRF przeciwko ofierze.
Ta luka pozwala atakującym na składanie nieautoryzowanych żądań w imieniu ofiary, wykorzystując **niewystarczający mechanizm walidacji tokenów** aplikacji.
### Method bypass
Jeśli żądanie używa "**dziwnej**" **metody**, sprawdź, czy funkcjonalność **przełamania 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**_
Może to również działać, wysyłając **parametr \_method wewnątrz żądania POST** lub używając **nagłówków**:
* _X-HTTP-Method_
* _X-HTTP-Method-Override_
* _X-Method-Override_
### Custom header token bypass
Jeśli żądanie dodaje **niestandardowy nagłówek** z **tokenem** do żądania jako **metodę ochrony CSRF**, to:
* Przetestuj żądanie bez **spersonalizowanego tokena i nagłówka.**
* Przetestuj żądanie z dokładnie **taką samą długością, ale innym tokenem**.
### CSRF token is verified by a cookie
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 odpowiada wartości w ciasteczku.
Jednak ta metoda jest podatna na ataki CSRF, jeśli witryna ma luki umożliwiające atakującemu 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.
Poniżej znajduje się przykład, jak atak mógłby być skonstruowany:
```html
```
{% hint style="info" %}
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.
{% endhint %}
### Zmiana Content-Type
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:
* **`application/x-www-form-urlencoded`**
* **`multipart/form-data`**
* **`text/plain`**
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`**_._
Przykład (z [tutaj](https://brycec.me/posts/corctf\_2021\_challenges)) wysyłania danych JSON jako text/plain:
```html
```
### Ominięcie żądań wstępnych dla danych JSON
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 zrozumienie tej techniki, zapoznaj się z [tym postem](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
### Ominięcie sprawdzania Referrer / Origin
**Unikaj nagłówka Referrer**
Aplikacje mogą weryfikować nagłówek 'Referer' tylko wtedy, gdy jest on obecny. Aby zapobiec przeglądarce wysyłaniu tego nagłówka, można użyć następującego tagu meta HTML:
```xml
```
To zapewnia, że nagłówek 'Referer' jest pomijany, co potencjalnie omija kontrole walidacji w niektórych aplikacjach.
**Obejścia Regexp**
{% content-ref url="ssrf-server-side-request-forgery/url-format-bypass.md" %}
[url-format-bypass.md](ssrf-server-side-request-forgery/url-format-bypass.md)
{% endcontent-ref %}
Aby ustawić nazwę domeny serwera w URL, który Referrer ma wysłać w parametrach, możesz to zrobić:
```html
```
### **Obejście metody HEAD**
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**.
Dlatego, jeśli żądanie GET jest ograniczone, możesz po prostu **wysłać żądanie HEAD, które zostanie przetworzone jako żądanie GET**.
## **Przykłady Eksploatacji**
### **Ekstrakcja tokena CSRF**
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/).
### **GET przy użyciu tagów HTML**
```xml
404 - Page not found
The URL you are requesting is no longer available
```
Inne tagi HTML5, które można wykorzystać do automatycznego wysyłania żądania GET, to:
```html