# CSRF (Cross Site Request Forgery)
{% hint style="success" %}
AWS Hacking'i öğrenin ve pratik yapın:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\
GCP Hacking'i öğrenin ve pratik yapın: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
HackTricks'i Destekleyin
* [**abonelik planlarını**](https://github.com/sponsors/carlospolop) kontrol edin!
* **💬 [**Discord grubuna**](https://discord.gg/hRep4RUj7f) veya [**telegram grubuna**](https://t.me/peass) katılın ya da **Twitter'da** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**'i takip edin.**
* **Hacking ipuçlarını paylaşmak için** [**HackTricks**](https://github.com/carlospolop/hacktricks) ve [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github reposuna PR gönderin.
{% endhint %}
Deneyimli hackerlar ve bug bounty avcıları ile iletişim kurmak için [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) sunucusuna katılın!
**Hacking İçgörüleri**\
Hacking'in heyecanı ve zorluklarına dalan içeriklerle etkileşimde bulunun
**Gerçek Zamanlı Hacking Haberleri**\
Hızla değişen hacking dünyasında gerçek zamanlı haberler ve içgörülerle güncel kalın
**Son Duyurular**\
Yeni başlayan bug bounty'ler ve kritik platform güncellemeleri hakkında bilgi sahibi olun
Bugün [**Discord**](https://discord.com/invite/N3FrSbmwdy) üzerinden bize katılın ve en iyi hackerlarla işbirliği yapmaya başlayın!
## Cross-Site Request Forgery (CSRF) Açıklaması
**Cross-Site Request Forgery (CSRF)**, web uygulamalarında bulunan bir güvenlik açığı türüdür. Bu, saldırganların, kimlik doğrulaması yapılmış oturumları istismar ederek, habersiz kullanıcılar adına eylemler gerçekleştirmesine olanak tanır. Saldırı, bir kullanıcının, bir kurbanın platformuna giriş yaptıktan sonra kötü niyetli bir siteyi ziyaret etmesiyle gerçekleştirilir. Bu site, JavaScript çalıştırma, formları gönderme veya resimleri alma gibi yöntemlerle kurbanın hesabına istekler tetikler.
### CSRF Saldırısı için Ön Koşullar
CSRF açığını istismar etmek için birkaç koşulun sağlanması gerekir:
1. **Değerli Bir Eylemi Belirleme**: Saldırgan, kullanıcının şifresini, e-posta adresini değiştirmek veya yetkileri yükseltmek gibi istismar etmeye değer bir eylem bulmalıdır.
2. **Oturum Yönetimi**: Kullanıcının oturumu yalnızca çerezler veya HTTP Temel Kimlik Doğrulama başlığı aracılığıyla yönetilmelidir, çünkü diğer başlıklar bu amaçla manipüle edilemez.
3. **Tahmin Edilemez Parametrelerin Yokluğu**: İstek, tahmin edilemez parametreler içermemelidir, çünkü bunlar saldırıyı engelleyebilir.
### Hızlı Kontrol
İsteği **Burp'ta yakalayabilir** ve CSRF korumalarını kontrol edebilir, tarayıcıdan test etmek için **Fetch olarak Kopyala** seçeneğine tıklayarak isteği kontrol edebilirsiniz:
### CSRF'ye Karşı Savunma
CSRF saldırılarına karşı korunmak için birkaç önlem uygulanabilir:
* [**SameSite çerezleri**](hacking-with-cookies/#samesite): Bu özellik, tarayıcının çerezleri çapraz site istekleriyle göndermesini engeller. [SameSite çerezleri hakkında daha fazla bilgi](hacking-with-cookies/#samesite).
* [**Çapraz kaynak paylaşımı**](cors-bypass.md): Kurban sitesinin CORS politikası, saldırının uygulanabilirliğini etkileyebilir, özellikle saldırı kurban sitesinden yanıt okumayı gerektiriyorsa. [CORS atlatma hakkında bilgi edinin](cors-bypass.md).
* **Kullanıcı Doğrulaması**: Kullanıcının şifresini istemek veya bir captcha çözmek, kullanıcının niyetini doğrulayabilir.
* **Referans veya Kaynak Başlıklarını Kontrol Etme**: Bu başlıkların doğrulanması, isteklerin güvenilir kaynaklardan geldiğinden emin olmaya yardımcı olabilir. Ancak, URL'lerin dikkatlice hazırlanması, kötü uygulanmış kontrolleri atlatabilir, örneğin:
* `http://mal.net?orig=http://example.com` kullanmak (URL güvenilir URL ile bitiyor)
* `http://example.com.mal.net` kullanmak (URL güvenilir URL ile başlıyor)
* **Parametre İsimlerini Değiştirme**: POST veya GET isteklerindeki parametre isimlerini değiştirmek, otomatik saldırıları önlemeye yardımcı olabilir.
* **CSRF Tokenleri**: Her oturumda benzersiz bir CSRF tokeni eklemek ve bu tokeni sonraki isteklere zorunlu kılmak, CSRF riskini önemli ölçüde azaltabilir. Tokenin etkinliği, CORS'un zorunlu kılınmasıyla artırılabilir.
Bu savunmaları anlamak ve uygulamak, web uygulamalarının güvenliğini ve bütünlüğünü korumak için kritik öneme sahiptir.
## Savunma Atlatma
### POST'tan GET'e
Kötüye kullanmak istediğiniz form, bir **CSRF tokeni ile POST isteği göndermek üzere hazırlanmış olabilir, ancak** bir **GET** isteğinin de **geçerli olup olmadığını kontrol etmelisiniz** ve GET isteği gönderdiğinizde **CSRF tokeninin hala doğrulandığını** kontrol etmelisiniz.
### Token Eksikliği
Uygulamalar, tokenler mevcut olduğunda **tokenleri doğrulamak için bir mekanizma** uygulayabilir. Ancak, token yokken doğrulamanın tamamen atlanması durumunda bir güvenlik açığı ortaya çıkar. Saldırganlar, tokeni taşıyan **parametreyi kaldırarak** bunu istismar edebilir, sadece değerini değil. Bu, doğrulama sürecini atlatmalarına ve etkili bir Cross-Site Request Forgery (CSRF) saldırısı gerçekleştirmelerine olanak tanır.
### CSRF tokeni kullanıcı oturumuna bağlı değil
Uygulamalar **CSRF tokenlerini kullanıcı oturumlarına bağlamıyorsa**, bu önemli bir **güvenlik riski** oluşturur. Bu sistemler, her tokenin başlatan oturumla bağlı olmasını sağlamak yerine, tokenleri **küresel bir havuz** ile doğrular.
Saldırganların bunu nasıl istismar ettiğine dair:
1. **Kendi hesaplarıyla kimlik doğrulama** yaparlar.
2. **Küresel havuzdan geçerli bir CSRF tokeni** alırlar.
3. **Bu tokeni** bir kurbana karşı CSRF saldırısında kullanırlar.
Bu güvenlik açığı, saldırganların kurban adına yetkisiz istekler yapmasına olanak tanır ve uygulamanın **yetersiz token doğrulama mekanizmasını** istismar eder.
### Yöntem Atlatma
Eğer istek "**garip**" bir **yöntem** kullanıyorsa, **yöntem** **aşırı yükleme işlevinin** çalışıp çalışmadığını kontrol edin. Örneğin, eğer **PUT** yöntemi kullanıyorsa, **POST** yöntemini kullanmayı deneyebilir ve **gönderebilirsiniz**: _https://example.com/my/dear/api/val/num?**\_method=PUT**_
Bu, **POST isteği içinde \_method parametresini** göndererek veya **başlıkları** kullanarak da çalışabilir:
* _X-HTTP-Method_
* _X-HTTP-Method-Override_
* _X-Method-Override_
### Özel başlık token atlatma
Eğer istek, **CSRF koruma yöntemi** olarak isteğe bir **token** ile **özel başlık** ekliyorsa, o zaman:
* **Özelleştirilmiş Token ve başlık olmadan isteği test edin.**
* **Tam aynı uzunlukta ama farklı bir token ile isteği test edin.**
### CSRF tokeni bir çerezle doğrulanıyor
Uygulamalar, tokeni hem bir çerezde hem de bir istek parametresinde kopyalayarak veya bir CSRF çerezi ayarlayarak ve arka uçta gönderilen tokenin çerezle eşleşip eşleşmediğini doğrulayarak CSRF koruması uygulayabilir. Uygulama, istek parametresindeki tokenin çerezdeki değerle uyumlu olup olmadığını kontrol ederek istekleri doğrular.
Ancak, bu yöntem, bir saldırganın kurbanın tarayıcısında bir CSRF çerezi ayarlamasına izin veren hatalar varsa CSRF saldırılarına karşı savunmasızdır, örneğin bir CRLF açığı. Saldırgan, çerezi ayarlayan yanıltıcı bir resmi yükleyerek bunu istismar edebilir ve ardından CSRF saldırısını başlatabilir.
Aşağıda bir saldırının nasıl yapılandırılabileceğine dair bir örnek bulunmaktadır:
```html
```
{% hint style="info" %}
Not edin ki eğer **csrf token oturum çerezi ile ilişkiliyse bu saldırı çalışmayacaktır** çünkü kurbanın oturumunu ayarlamanız gerekecek ve dolayısıyla kendinizi hedef almış olacaksınız.
{% endhint %}
### Content-Type değişikliği
[**şuna**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests) göre, **ön uç** isteklerini **POST** yöntemi kullanarak önlemek için izin verilen Content-Type değerleri şunlardır:
* **`application/x-www-form-urlencoded`**
* **`multipart/form-data`**
* **`text/plain`**
Ancak, kullanılan **Content-Type**'a bağlı olarak **sunucu mantığı değişebilir** bu yüzden belirtilen değerleri ve **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._ gibi diğerlerini denemelisiniz.
Örnek ( [buradan](https://brycec.me/posts/corctf\_2021\_challenges) ) JSON verisini text/plain olarak göndermenin:
```html
```
### JSON Verileri için Ön Uç İsteklerini Aşma
POST isteği aracılığıyla JSON verisi göndermeye çalışırken, bir HTML formunda `Content-Type: application/json` kullanmak doğrudan mümkün değildir. Benzer şekilde, bu içerik türünü göndermek için `XMLHttpRequest` kullanmak bir ön uç isteği başlatır. Yine de, bu sınırlamayı aşmanın ve sunucunun JSON verilerini Content-Type'a bakılmaksızın işleyip işlemediğini kontrol etmenin stratejileri vardır:
1. **Alternatif İçerik Türlerini Kullanma**: Formda `enctype="text/plain"` ayarlayarak `Content-Type: text/plain` veya `Content-Type: application/x-www-form-urlencoded` kullanın. Bu yaklaşım, arka ucun verileri Content-Type'a bakılmaksızın kullanıp kullanmadığını test eder.
2. **İçerik Türünü Değiştirme**: Sunucunun içeriği JSON olarak tanımasını sağlarken ön uç isteğinden kaçınmak için veriyi `Content-Type: text/plain; application/json` ile gönderebilirsiniz. Bu, bir ön uç isteği tetiklemez ancak sunucu `application/json` kabul edecek şekilde yapılandırılmışsa doğru bir şekilde işlenebilir.
3. **SWF Flash Dosyası Kullanımı**: Daha az yaygın ama uygulanabilir bir yöntem, bu tür kısıtlamaları aşmak için bir SWF flash dosyası kullanmaktır. Bu tekniği daha derinlemesine anlamak için [bu gönderiye](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937) bakın.
### Referrer / Origin kontrolünü aşma
**Referrer başlığından kaçının**
Uygulamalar, 'Referer' başlığı yalnızca mevcut olduğunda doğrulama yapabilir. Bir tarayıcının bu başlığı göndermesini önlemek için aşağıdaki HTML meta etiketi kullanılabilir:
```xml
```
Bu, 'Referer' başlığının hariç tutulmasını sağlar ve bazı uygulamalardaki doğrulama kontrollerinin atlanmasına neden olabilir.
**Regexp atlamaları**
{% 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 %}
Referrer'ın parametreler içinde göndereceği URL'deki sunucunun alan adını ayarlamak için şunları yapabilirsiniz:
```html
```
### **HEAD yöntemi atlatma**
[**Bu CTF yazısı**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) kısmında, [Oak'ın kaynak kodu](https://github.com/oakserver/oak/blob/main/router.ts#L281) bir yönlendiricinin **HEAD isteklerini GET istekleri olarak** yanıt gövdesi olmadan işlemek üzere ayarlandığı açıklanmaktadır - bu, Oak'a özgü olmayan yaygın bir geçici çözümdür. HEAD istekleriyle ilgilenen belirli bir işleyici yerine, bunlar basitçe **GET işleyicisine verilir, ancak uygulama yanıt gövdesini kaldırır**.
Bu nedenle, bir GET isteği sınırlıysa, **GET isteği olarak işlenecek bir HEAD isteği gönderebilirsiniz**.
## **Sömürü Örnekleri**
### **CSRF Token'ı Sızdırma**
Eğer bir **CSRF token'ı** **savunma** olarak kullanılıyorsa, bir [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) açığını veya bir [**Dangling Markup**](dangling-markup-html-scriptless-injection/) açığını kullanarak **sızdırmayı** deneyebilirsiniz.
### **HTML etiketleri kullanarak GET**
```xml
404 - Page not found
The URL you are requesting is no longer available
```
Diğer HTML5 etiketleri, otomatik olarak bir GET isteği göndermek için kullanılabilir:
```html