Next-Gen WAF Bypass: Polyglot Payload ve HTTP Request Smuggling Kombinasyonları

ene 6, 2026 OP

Autor del tema #0

1) Neden “Next-Gen” bypass’lar hâlâ mümkün?

Modern WAF’lar artık yalnızca imza (signature) yakalamıyor; davranış analizi, anomali skoru, bot tespiti, JA3/JA4, fingerprinting, rate limit, hatta kimi zaman L7 reverse-proxy yetenekleriyle “akıllı” karar veriyor. Buna rağmen bypass’lar bitmiyor çünkü saldırı yüzeyi değişti:

Katmanlar arası yorum farkı: İstemci → CDN → LB → reverse proxy → uygulama zincirinde aynı istek farklı yorumlanabiliyor.
Normalizasyon boşlukları: URL decode, charset, header folding, whitespace, chunked parçalama gibi “dönüşümler” her bileşende aynı değil.
Çoklu semantik: Tek bir girdi hem JSON hem form-encoded hem de template/SQL/HTML bağlamına “anlamlı” görünebiliyor.
Parçalı değerlendirme: WAF bazen “ön yüzde” gördüğü ile backend’in işlediği “gerçek” request arasında ayrışma yaşar.

Bu makalenin kalbi şu iki fikir:
(1) Polyglot payload = tek içerikte çoklu bağlam tetikleme
(2) Request Smuggling = aynı HTTP akışını farklı bileşenlere farklı şekilde “böldürme”

Kombinasyon ise, savunma için kritik bir risk sınıfı: WAF’in güvenli sandığı şey, backend’de farklı bir şeye dönüşebilir.

2) Polyglot Payload nedir? (Savunmacı perspektif)

Polyglot, aynı metnin birden fazla “dil/bağlam” tarafından anlamlı biçimde yorumlanabilmesi demek. Güvenlikte bu, tek bir kullanıcı girdisinin:

WAF tarafında “masum”
uygulamada “template”
log/alert sisteminde “escape bozan”
istemcide “HTML/JS”
backend’de “SQL/NoSQL/LDAP”

gibi farklı etkiler üretebilmesi anlamına gelir.

Polyglot’ların savunma açısından tehlikeli olmasının 3 nedeni

Tek filtreden kaçıp başka bağlama düşer
WAF “XSS” ararken payload “template” bağlamında çalışabilir.
Normalizasyon zinciri
Bir bileşen decode eder, diğeri iki kere decode eder, üçüncüsü hiç etmez.
Kayıt (log) zehirleme
WAF/IDS/SIEM log formatını bozan girdiler, görünürlüğü azaltır (alert’ı “gizler”).

VIP not: Polyglot’ları “payload listesi” gibi düşünmek yerine, bağlamlar arası geçiş olarak düşünmek daha doğru.

3) HTTP Request Smuggling (HRS) nedir?

Request Smuggling, bir HTTP isteğinin sınırlarını (nerede bittiğini/yenisinin nerede başladığını) zincirdeki bileşenlerin farklı yorumlamasıyla oluşur. En çok şu durumlarda risk artar:

CDN/LB/Proxy ile backend arasında HTTP/1.1 kullanımı
Connection reuse (keep-alive)
Header ayrıştırma farklılıkları
Chunked/Content-Length gibi gövde uzunluğu belirleyen mekanizmalar
HTTP/2 ↔ HTTP/1.1 dönüştürme (downgrade/translation)

Savunmacı bakış: HRS neye yol açar?

WAF atlatma: WAF’in gördüğü “request #1” ile backend’in işlediği “request #2” farklı olabilir.
Cache poisoning / route confusion: yanlış cache anahtarı, yanlış içerik.
Session karışması: aynı TCP bağlantısında başka kullanıcıya ait request’lerin etkilenmesi (bazı mimarilerde).
Gizli endpoint’lere erişim: dışarı kapalı görünen path/backend’de tetiklenebilir.

4) Kombinasyon: Polyglot + Smuggling neden “çarpan etkisi” yaratır?

Bu iki teknik birleşince amaç genelde şudur:
“WAF’in denetlediği kısım ile backend’in gerçekten çalıştırdığı kısmı ayır, sonra backend tarafına çoklu bağlamda etkili olabilecek bir girdi düşür.”

Tipik risk desenleri (saldırı ayrıntısı vermeden)

Ön katmanda temiz görünen istek, backend’de farklı endpoint’e kayar.
WAF’in parse ettiği body, backend’in parse ettiği body’den farklı olur.
Polyglot içerik, backend’de farklı parser/serializer zincirine düşer (örn. JSON → template → SQL).

Bu yüzden “WAF var” demek tek başına yeterli değil; WAF’in parse ettiği ile origin’in parse ettiği birebir aynı mı? sorusu kritik.

5) En sık görülen kök nedenler

Aşağıdakiler, gerçek dünyada HRS ve polyglot etkilerini besleyen ana hatalar:

5.1 HTTP ayrıştırma tutarsızlıkları

Header whitespace / obs-fold gibi “eski” davranışlar
Duplicate header’lar (aynı header birden fazla)
Transfer-Encoding ve Content-Length gibi uzunluk belirleyicilerde tutarsızlıklar
Proxy ile origin’in farklı RFC yorumlaması

5.2 Normalizasyon farkları

URL decode sayısı (1x vs 2x)
Unicode/charset dönüşümleri
Path normalize (//, ./, ../, %2f gibi)
Header canonicalization

5.3 Uygulama katmanı serileştirme zinciri

JSON parser toleransı (trailing comma vb.)
Form-urlencoded ile JSON’un aynı endpoint’te kabul edilmesi
Template motorlarının “güvenli” varsayılan olmaması
Log/metric pipeline’da escape eksikliği

6) Tespit: WAF ve altyapıda neyi izleyeceğiz?

Aşağıdaki sinyaller tek başına kanıt değil ama yüksek risk göstergesidir.

6.1 Trafik anomalileri

Aynı istemciden kısa sürede çok sayıda 4xx/5xx ve ardından başarılı 2xx
Aynı bağlantıda beklenmedik request burst (keep-alive)
“Normal endpoint” yoğunluğunun aniden düşmesi, “garip path” artışı

6.2 Header tutarsızlığı göstergeleri

Aynı request’te tekrarlanan header’lar
Beklenmedik Transfer-Encoding / gövde uzunluğu davranışları
Proxy katmanında görünen ile origin log’unda görünen Content-Length farkları (varsa)

6.3 WAF log korelasyonu

WAF “allow” dediği halde origin’de routing/handler değişiyorsa (örn. farklı controller)
WAF’in kaydettiği URL/path ile uygulama log’undaki path farklıysa
Aynı request_id altında çift işlem izleri

Pratik: Her request’e edge’de bir X-Request-ID enjekte edin; WAF/CDN/proxy/app log’larında aynı ID’yi taşıyın.

7) Önleme: Mimaride “bypass sınıfını” nasıl kapatırız?

Burada hedef: tek bir katmanda değil, zincirin tamamında deterministik ayrıştırma.

7.1 Katmanları sadeleştir (en etkilisi)

Mümkünse CDN/WAF → tek reverse proxy → uygulama
Araya giren “gizli” proxy’leri azalt (özellikle farklı vendor)

7.2 HTTP protokol stratejisi

Edge’den origin’e HTTP/2 end-to-end (mümkünse) veya net bir standart
HTTP/1.1 keep-alive reuse risklerine dikkat (özellikle shared connection havuzları)

7.3 Proxy/WAF sertleştirme

Ambiguous request’leri fail-closed (şüpheliyi düşür)
Duplicate/contradicting header politikası: tekilleştir veya reddet
Transfer-Encoding / body parsing politikaları: net ve tutarlı
“Normalize once, validate once” prensibi: normalizasyonu tek yerde standardize et

7.4 Uygulama katmanında bağlam güvenliği

Polyglot riskini azaltmak için:
- Template motorlarında auto-escape ve “no eval”
- JSON schema validation (strict)
- Output encoding (HTML/JS/URL/SQL bağlamına göre)
- Log sanitization (escape + length limits)

7.5 Güvenlik testleri

DAST + proxy fuzzing’i kendi staging’inizde yapın
Edge ve origin davranışını karşılaştıran testler:
“Edge ne gördü, origin ne işledi?”

Next-Gen WAF Bypass: Polyglot Payload ve HTTP Request Smuggling Kombinasyonları