# CSRF (Cross Site Request Forgery)
AWS hacklemeyi sıfırdan kahraman olmaya öğreninhtARTE (HackTricks AWS Kırmızı Takım Uzmanı) ile!
HackTricks'ı desteklemenin diğer yolları:
* **Şirketinizi HackTricks'te reklamınızı görmek istiyorsanız** veya **HackTricks'i PDF olarak indirmek istiyorsanız** [**ABONELİK PLANLARI**](https://github.com/sponsors/carlospolop)'na göz atın!
* [**Resmi PEASS & HackTricks ürünlerini**](https://peass.creator-spring.com) edinin
* [**PEASS Ailesi'ni**](https://opensea.io/collection/the-peass-family) keşfedin, özel [**NFT'lerimiz**](https://opensea.io/collection/the-peass-family) koleksiyonumuz
* **Bize katılın** 💬 [**Discord grubunda**](https://discord.gg/hRep4RUj7f) veya [**telegram grubunda**](https://t.me/peass) veya bizi **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)** takip edin.**
* **Hacking püf noktalarınızı göndererek HackTricks ve HackTricks Cloud** github depolarına PR göndererek paylaşın.
Deneyimli hackerlar ve ödül 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ına ve zorluklarına inen içeriklerle etkileşime girin
**Gerçek Zamanlı Hack Haberleri**\
Hızla değişen hacking dünyasında gerçek zamanlı haberler ve içgörülerle güncel kalın
**En Son Duyurular**\
Yayınlanan en yeni ödül avı başlangıçlarını ve önemli platform güncellemelerini takip edin
**Bize katılın** [**Discord**](https://discord.com/invite/N3FrSbmwdy) ve bugün en iyi hackerlarla işbirliğine 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 açık, saldırganların kimlik doğrulanmış oturumlarını sömürerek habersiz kullanıcılar adına eylemler gerçekleştirmesine olanak tanır. Saldırı, bir kullanıcının, bir kurbanın platformuna oturum açmış olduğu sırada kötü niyetli bir siteyi ziyaret etmesiyle gerçekleştirilir. Bu site daha sonra JavaScript çalıştırarak, formlar göndererek veya resimler getirerek kurbanın hesabına istekler gönderir.
### CSRF Saldırısı için Önkoşullar
CSRF açığından yararlanmak için birkaç koşulun sağlanması gerekir:
1. **Değerli Bir Eylemi Tanımlama**: Saldırganın, kullanıcının şifresini, e-postasını değiştirmek veya ayrıcalıkları yükseltmek gibi sömürülmeye değer bir eylem bulması gerekir.
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, diğer başlıklar bu amaçla manipüle edilemez.
3. **Tahmin Edilemeyen Parametrelerin Eksikliği**: İstek, tahmin edilemeyen parametreler içermemelidir, çünkü bunlar saldırıyı engelleyebilir.
### Hızlı Kontrol
**Burp'ta isteği yakalayabilir** ve CSRF korumalarını kontrol edebilir ve tarayıcıdan test etmek için **Kopyala ve fetch olarak yap**'a tıklayabilirsiniz ve isteği kontrol edebilirsiniz:
### CSRF'ye Karşı Savunma
CSRF saldırılarına karşı korunmak için birkaç karşı önlem alınabilir:
* [**SameSite çerezleri**](hacking-with-cookies/#samesite): Bu özellik, tarayıcının çerezleri çapraz site istekleriyle birlikte göndermesini engeller. [SameSite çerezleri hakkında daha fazla bilgi](hacking-with-cookies/#samesite).
* [**Çapraz kaynak kaynağı paylaşımı**](cors-bypass.md): Kurban sitesinin CORS politikası, saldırının gerçekleştirilmesi için kurban sitesinden yanıtın okunmasını gerektiriyorsa saldırının uygulanabilirliğini etkileyebilir. [CORS atlatma hakkında bilgi edinin](cors-bypass.md).
* **Kullanıcı Doğrulaması**: Kullanıcının niyetini doğrulamak için şifresini sormak veya bir captcha çözdürmek önemli olabilir.
* **Referrer veya Origin Başlıklarını Kontrol Etme**: Bu başlıkları doğrulamak, isteklerin güvenilir kaynaklardan geldiğinden emin olmaya yardımcı olabilir. Ancak, URL'lerin dikkatli bir şekilde oluşturulması, kötü uygulanmış kontrolleri atlatmaya olanak tanır, örneğin:
* `http://mal.net?orig=http://example.com` (URL güvenilir URL ile biter)
* `http://example.com.mal.net` (URL güvenilir URL ile başlar)
* **Parametre Adlarını Değiştirme**: POST veya GET isteklerinde parametre adlarını değiştirmek, otomatik saldırıları önlemede yardımcı olabilir.
* **CSRF Token'ları**: Her oturuma benzersiz bir CSRF token eklemek ve bu token'ı sonraki isteklerde gerektirmek, CSRF riskini önemli ölçüde azaltabilir. Token'ın 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 hayati önem taşır.
## Savunmaları Atlatma
### POST'tan GET'e
Belki de istismar etmek istediğiniz form, bir **CSRF token ile POST isteği göndermeye hazırlanmıştır ancak**, bir **GET**'in de **geçerli olup olmadığını kontrol etmelisiniz** ve GET isteği gönderdiğinizde **CSRF token'ın hala doğrulandığını kontrol edin**.
### Token eksikliği
Uygulamalar, var olduklarında **token'ları doğrulamak** için bir mekanizma uygulayabilir. Ancak, token yokken doğrulamanın tamamen atlandığı bir güvenlik açığı ortaya çıkabilir. Saldırganlar, token'ı taşıyan parametreyi sadece değerini değil, parametreyi kaldırarak doğrulama sürecini atlayabilir. Bu, saldırganların doğrulama sürecini atlayarak Cross-Site Request Forgery (CSRF) saldırısını etkili bir şekilde gerçekleştirmesine olanak tanır.
### CSRF token'ı kullanıcı oturumuna bağlı değil
Uygulamalar, CSRF token'larını kullanıcı oturumlarına bağlamayarak önemli bir **güvenlik riski** oluşturabilir. Bu sistemler, her token'ın başlatan oturuma bağlı olmasını sağlamak yerine token'ları genel bir havuzda doğrular.
Saldırganların bunu nasıl sömürdüğü:
1. Kendi hesaplarıyla **kimlik doğrulama** yaparlar.
2. Genel havuzdan geçerli bir CSRF token **alırlar**.
3. Bu token'ı bir kurban üzerindeki CSRF saldırısında **kullanırlar**.
Bu zayıf nokta, saldırganların, uygulamanın **yetersiz token doğrulama mekanizmasını** sömürerek kurban adına yetkisiz istekler yapmasına olanak tanır.
### Yöntem atlatma
Eğer istek "**garip**" bir **yöntem** kullanıyorsa, **yöntem geçersizleştirme işlevinin çalışıp çalışmadığını kontrol edin**. Örneğin, **PUT** yöntemi kullanılıyorsa **POST** yöntemini deneyebilir ve şunu gönderebilirsiniz: _https://example.com/my/dear/api/val/num?**\_method=PUT**_
Bu ayrıca **\_method parametresini bir POST isteği içine yerleştirerek** veya **başlıkları kullanarak** ç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 bir token ile özel bir başlık ekliyorsa**, o zaman:
* **Özel Token ve başlığı olmadan** isteği test edin.
* Aynı uzunlukta fakat farklı bir token ile isteği test edin.
### CSRF token'ı bir çerez tarafından doğrulanıyor
Uygulamalar, CSRF korumasını, hem bir çerezde hem de bir istek parametresinde token'ı çoğaltarak veya bir CSRF çerezi ayarlayarak ve backend'de gönderilen token'ın çerezle eşleşip eşleşmediğini doğrulayarak uygulayabilir. Uygulama, isteğin token'ının, çerezdeki değerle uyumlu olup olmadığını kontrol ederek istekleri doğrular.
Ancak, bu yöntem, web sitesinin, bir saldırganın kurbanın tarayıcısına bir CSRF çerezi yerleştirmesine izin veren hatalara sahip olması durumunda CSRF saldırılarına karşı savunmasızdır. Saldırgan, çerezi ayarlayan aldatıcı bir resim yükleyerek ve ardından CSRF saldırısını başlatarak bunu sömürebilir.
Aşağıda, bir saldırının nasıl yapılandırılabileceğine dair bir örnek bulunmaktadır:
```html
```
{% hint style="info" %}
**csrf belirteci oturum çerezi ile ilişkilendirilmişse bu saldırı çalışmayacaktır** çünkü kurbanın oturumunu ayarlamanız gerekecek ve dolayısıyla kendinize saldıracaksınız.
{% endhint %}
### Content-Type değişikliği
[**Buna**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests) göre, **POST** yöntemini kullanarak **önyükleme** isteklerini **önlemek** için izin verilen Content-Type değerleri şunlardır:
* **`application/x-www-form-urlencoded`**
* **`multipart/form-data`**
* **`text/plain`**
Ancak, **Sunucunun mantığı** kullanılan **Content-Type**'a bağlı olarak değişebilir, bu nedenle belirtilen değerleri ve **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._ gibi diğer değerleri denemelisiniz.
JSON verilerini text/plain olarak gönderme örneği ([buradan](https://brycec.me/posts/corctf\_2021\_challenges)):
```html
```
### JSON Verileri için Preflight İsteklerinin Atlatılması
JSON verilerini bir POST isteği aracılığıyla 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 preflight isteği başlatır. Bununla birlikte, sunucunun JSON verilerini işleyip işlemediğini Content-Type'a bakılmaksızın kontrol etmek için bu kısıtlamayı potansiyel olarak atlatmanın stratejileri bulunmaktadır:
1. **Alternatif İçerik Türleri Kullanma**: Formda `enctype="text/plain"` ayarlayarak `Content-Type: text/plain` veya `Content-Type: application/x-www-form-urlencoded` kullanın. Bu yaklaşım, sunucunun Content-Type'a bakılmaksızın verileri kullanıp kullanmadığını test eder.
2. **İçerik Türünü Değiştirme**: Sunucunun içeriği JSON olarak tanıdığından emin olurken preflight isteğini önlemek için verileri `Content-Type: text/plain; application/json` ile gönderebilirsiniz. Bu bir preflight isteği başlatmaz ancak sunucunun `application/json`'ı kabul etmek için yapılandırılmışsa doğru şekilde işleyebilir.
3. **SWF Flash Dosyası Kullanımı**: Daha az yaygın ancak mümkün olan bir yöntem, bu tür kısıtlamaları atlamak için bir SWF flash dosyası kullanmaktır. Bu teknik hakkında detaylı bilgi için [bu yazıya](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937) başvurun.
### Referrer / Origin kontrolünü atlatma
**Referrer Başlığını Kullanmamak**
Uygulamalar, 'Referer' başlığını yalnızca var olduğunda doğrulayabilir. Tarayıcının bu başlığı göndermesini engellemek için aşağıdaki HTML meta etiketi kullanılabilir:
```xml
```
Bu, bazı uygulamalardaki doğrulama kontrollerini atlayarak 'Referer' başlığının atlandığından emin olur.
**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 %}
Sunucunun alan adını Referrer'ın parametreler içinde göndereceği URL'de ayarlamak için şunu yapabilirsiniz:
```html
```
### **HEAD yöntemi bypass**
[**Bu CTF çözümü**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution)nin ilk kısmında [Oak'ın kaynak kodu](https://github.com/oakserver/oak/blob/main/router.ts#L281), bir yönlendiricinin **HEAD isteklerini yanıtsız GET istekleri olarak işlemek üzere ayarlandığı** açıklanmıştır - bu, Oak'a özgü olmayan yaygın bir çalışma biçimidir. HEAD isteklerini işleyen özel bir işleyici yerine, bunlar sadece **GET işleyicisine verilir ancak uygulama yanıt gövdesini kaldırır**.
Bu nedenle, bir GET isteğinin sınırlı olduğu durumlarda, **GET isteği göndermek yerine işlenecek bir HEAD isteği gönderebilirsiniz**.
## **Sömürü Örnekleri**
### **CSRF Belirteci Sızdırma**
Eğer bir **CSRF belirteci** kullanılıyorsa **savunma** olarak, [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) zafiyeti veya [**Dangling Markup**](dangling-markup-html-scriptless-injection/) zafiyetini istismar ederek onu **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