diff --git a/src/pentesting-web/csrf-cross-site-request-forgery.md b/src/pentesting-web/csrf-cross-site-request-forgery.md
index 68e2ea48a..b26425e32 100644
--- a/src/pentesting-web/csrf-cross-site-request-forgery.md
+++ b/src/pentesting-web/csrf-cross-site-request-forgery.md
@@ -4,83 +4,110 @@
## 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, farkında olmayan kullanıcılar adına eylemler gerçekleştirmesine olanak tanır. Saldırı, bir kurbanın platformuna giriş yapmış bir kullanıcının 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.
+**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.
-### CSRF Saldırısı için Ön Koşullar
+### CSRF Saldırısı için Önkoşullar
-CSRF açığını istismar etmek için birkaç koşulun sağlanması gerekir:
+Bir CSRF zafiyetinden yararlanmak 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 artırmak 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.
+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.
### Hızlı Kontrol
-**Burp'ta isteği 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:
+İ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:
 (1) (1).png)
","widgetType":"URL"}]
+```
-Saldırganların bunu nasıl istismar ettiğine dair:
+- GET'e geçerek bypass (no token):
-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.
+```http
+GET /index.php?module=Home&action=HomeAjax&file=HomeWidgetBlockList&widgetInfoList=[{"widgetId":"https://attacker
","widgetType":"URL"}] HTTP/1.1
+```
-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.
+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.
-### Yöntem atlatma
+### Lack of token
-Eğer istek "**garip**" bir **yöntem** kullanıyorsa, **yöntem** **aşırı yazma 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**_
+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.
-Bu, **POST isteği içinde \_method parametresini** göndererek veya **başlıkları** kullanarak da çalışabilir:
+### CSRF token is not tied to the user session
+
+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.
+
+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.
+
+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.
+
+### Method bypass
+
+İ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 ayrıca bir POST isteği içinde __method parametresini göndererek veya headers kullanarak da çalışabilir:
- _X-HTTP-Method_
- _X-HTTP-Method-Override_
- _X-Method-Override_
-### Özel başlık token atlatma
+### Custom header token bypass
-Eğer istek, **CSRF koruma yöntemi** olarak isteğe bir **token** ile **özel başlık** ekliyorsa, o zaman:
+Eğer istek CSRF koruma yöntemi olarak isteğe özel bir header ile token ekliyorsa:
-- **Özelleştirilmiş Token ve başlık olmadan isteği test edin.**
-- **Tam aynı uzunlukta ama farklı bir token ile isteği test edin.**
+- Özelleştirilmiş Token ve header olmadan isteği test edin.
+- Tam aynı uzunlukta fakat farklı bir token ile testi yapın.
-### CSRF tokeni bir çerezle doğrulanıyor
+### CSRF token is verified by a cookie
-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.
+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.
-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.
+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.
-Aşağıda bir saldırının nasıl yapılandırılabileceğine dair bir örnek bulunmaktadır:
+Aşağıda bir saldırının nasıl yapılandırılabileceğine dair bir örnek gösterilmiştir:
```html
@@ -103,19 +130,19 @@ onerror="document.forms[0].submit();" />
```
> [!TIP]
-> Dikkat 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.
+> 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.
### Content-Type değişikliği
-[**şuna**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests) göre, **POST** yöntemi kullanarak **ön uç** isteklerini **önlemek** için izin verilen Content-Type değerleri şunlardır:
+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:
- **`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.
+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.
-Örnek ( [buradan](https://brycec.me/posts/corctf_2021_challenges) ) JSON verisini text/plain olarak göndermenin:
+Örnek (from [here](https://brycec.me/posts/corctf_2021_challenges)) JSON verisini text/plain olarak gönderme:
```html