ÖNEMLİ NOT: Bu bölüm, güvenlik farkındalığı ve savunma amaçlıdır. HTTP Request Smuggling, implementation-specific bir zafiyet olduğu için örnekler kavramsal düzeydedir. Gerçek saldırı vektörleri, hedef sistemin parser davranışına göre değişir.
HTTP Desync Attacks Nedir? (Güncel Tanım)
HTTP Desync Attacks (HTTP Request Smuggling) , frontend (proxy, load balancer, CDN) ve backend (web sunucusu) arasındaki HTTP isteklerinin sınırlandırılmasında (Content-Length, Transfer-Encoding, HTTP/2 framing) yaşanan uyumsuzluklar nedeniyle oluşan bir saldırı sınıfıdır. Saldırgan, bu uyumsuzluğu kullanarak istek kuyruğunu zehirleyebilir, önbelleği manipüle edebilir ve diğer kullanıcıların isteklerini etkileyebilir.
Temel Mekanizma:
Frontend ve backend, HTTP isteklerinin nerede bittiğini farklı şekilde yorumlar.
Saldırgan, bu farklı yorumlamayı kullanarak bir isteği "kaçırarak" diğer kullanıcıların isteklerini etkiler.
HTTP Desync Türleri (Güncel Sınıflandırma):
1. CL.TE (Content-Length vs Transfer-Encoding)
Frontend Content-Length, backend Transfer-Encoding kullanır.
Kavramsal Örnek:
http
POST / HTTP/1.1
Host: hedef.com
Content-Length: 36
Transfer-Encoding: chunked
0
GET /admin HTTP/1.1
Host: hedef.com
Gerçekte: CRLF, chunk size, body uzunluğu hassastır. Bu örnek kavramsaldır.
2. TE.CL (Transfer-Encoding vs Content-Length)
Frontend Transfer-Encoding, backend Content-Length kullanır.
Kavramsal Örnek:
http
POST / HTTP/1.1
Host: hedef.com
Content-Length: 4
Transfer-Encoding: chunked
12
GET /admin HTTP/1.1
Host: hedef.com
0
3. TE.TE (Transfer-Encoding vs Transfer-Encoding)
Her iki tarafta TE var, ancak farklı yorumlanıyor (obfuscation).
4. HTTP/2 Desync
H2.TE: HTTP/2 → HTTP/1.1 downgrade sırasında TE uyumsuzluğu.
H2.CL: HTTP/2 → HTTP/1.1 downgrade sırasında CL uyumsuzluğu.
H2 Request Splitting: HTTP/2 frame'lerinin yanlış yorumlanması.
H2C Smuggling: HTTP/2 Clear Text (H2C) üzerinden smuggling.
5. HTTP/3 (QUIC) Perspektifi
HTTP/3 (QUIC), kendi çerçeveleme (framing) mekanizmasını kullandığından klasik CL.TE/TE.CL senaryolarını içermez. Ancak:
HTTP/3 → HTTP/1.1 veya HTTP/2 downgrade işlemlerinde, gateway'ler arasındaki parser farklılıkları nedeniyle desync riskleri oluşabilir.
HTTP/3'ün header compression (QPACK) ve framing yapısı, farklı downgrade senaryolarına yol açabilir.
2026 itibarıyla HTTP/3 yaygınlaşmaya başladığı için, gateway/downgrade senaryoları dikkatle izlenmelidir.
HTTP Desync Saldırılarının Gerçek Etkileri:
YANLIŞ: "Saldırgan /admin'e erişir"
DOĞRU: Smuggling'in asıl etkileri şunlardır:
Request Queue Poisoning: İstek kuyruğunun zehirlenmesi; saldırganın isteği, başka bir kullanıcının isteğinin önüne geçer.
Response Queue Desynchronization: Yanıt kuyruğunun senkronsuzlaşması; yanıtlar farklı kullanıcılara gider.
Cache Poisoning: Önbelleğe, diğer kullanıcıların göreceği hatalı/zararlı yanıtların yerleşmesi.
Session Fixation: Başka kullanıcıların oturumlarının ele geçirilmesi.
Authentication Confusion: Kimlik doğrulama mekanizmasının karışması.
Internal API Poisoning: Dahili API'lere yetkisiz erişim.
Credential Leakage: Diğer kullanıcıların kimlik bilgilerinin sızdırılması.
CDN Cache Poisoning: CDN önbelleğinin zehirlenmesi (geniş etkili).
CORS Cache Poisoning: CORS politikalarının atlatılması.
HTTP Desync Nasıl Tespit Edilir? (Doğru Yaklaşım)
YANLIŞ: "404 dönerse açık var" - Bu tek başına bir kanıt değildir.
DOĞRU: Tespit için şu göstergeler birlikte değerlendirilir:
A. Zaman Tabanlı Göstergeler:
Timeout: İsteklerin zaman aşımına uğraması, olası bir desync göstergesidir. Ancak reverse proxy, load balancer veya network sorunları da timeout üretebilir. Bu nedenle tek başına kanıt değildir.
Gecikme: Normal isteklere göre anormal gecikmeler.
B. Yanıt Tabanlı Göstergeler:
Desync: İkinci isteğin yanıtının bozulması veya farklı bir kullanıcıya gitmesi.
Response Poisoning: Önbelleğe alınan yanıtın beklenenden farklı olması.
C. Queue Tabanlı Göstergeler:
Request Queue Poisoning: Saldırganın isteğinden sonra gönderilen normal isteklerin hatalı yanıt alması.
Response Queue Desync: Yanıtların sırasının karışması.
D. Doğrulama Yöntemi:
Smuggling payload'ı gönderin.
Normal bir istek gönderin.
Normal isteğin yanıtı bozulduysa veya beklenmeyen bir yanıt geldiyse, desync başarılıdır.
HTTP/2 Downgrade (2026 Güncel Konusu)
Neden Önemli?
Birçok modern web uygulaması, istemcilerle HTTP/2 üzerinden iletişim kurar.
Backend sunucuları ise hala HTTP/1.1 kullanıyor olabilir.
Downgrade işlemi sırasında, HTTP/2 frame'leri HTTP/1.1 isteklerine dönüştürülür.
Bu dönüştürme sırasında parser farklılıkları desync'e yol açabilir.
HTTP/2 Downgrade Desync Senaryoları:
H2.TE Desync:
HTTP/2 isteği, backend'e HTTP/1.1 olarak iletilir.
Frontend HTTP/2'de Transfer-Encoding'i desteklemez (HTTP/2'de yoktur).
Backend HTTP/1.1'de Transfer-Encoding'i destekler.
Frontend, Content-Length'i kullanır; backend TE'yi kullanırsa desync oluşur.
H2.CL Desync:
HTTP/2'de Content-Length header'ı varsa, frontend bunu kullanır.
Backend, Content-Length'i farklı yorumlarsa desync oluşur.
HTTP/2 Request Splitting:
HTTP/2 frame'lerinin (HEADERS, DATA) yanlış sınırlandırılması.
Bir frame içinde birden fazla HTTP isteği gönderme.
Koruma Teknikleri (Güncel ve Doğru Yaklaşım):
1. RFC Uyumluluğu
HTTP/1.1 spesifikasyonu artık RFC 9112 ile güncellenmiştir (RFC 7230 eskidir).
Tüm frontend ve backend sunucuları RFC 9112 uyumlu olmalıdır.
RFC 9112, Content-Length ve Transfer-Encoding davranışını daha net tanımlar.
2. Parser Tutarlılığı (ÖNEMLİ)
YANLIŞ: "Aynı parser kullanın" - Bu pratikte mümkün değildir (Nginx, Apache, vb.).
DOĞRU: "Tüm sunucular RFC 9112 uyumlu davranmalı ve aynı HTTP standartlarını benimsemelidir."
Önerilen Pratik:
Nginx, Apache, Envoy, HAProxy gibi yaygın sunucuların güncel sürümlerini kullanın.
Tüm sunucularda aynı HTTP/1.1 davranışını zorunlu kılın.
HTTP/1.1 ve HTTP/2 arasındaki downgrade mekanizmalarını dikkatle yapılandırın.
3. HTTP/2 ve HTTP/3 Yapılandırması
HTTP/2 kullanıyorsanız, backend ile HTTP/2 üzerinden iletişim kurun (downgrade'i ortadan kaldırın).
HTTP/3 kullanımında, gateway'lerin downgrade yaparken desync risklerini göz önünde bulundurun.
Mümkünse uçtan uca (end-to-end) aynı HTTP sürümünü kullanın.
4. Header Normalizasyonu (WAF/Proxy Seviyesinde)
WAF veya proxy, gelen istekleri normalize etmelidir:
Çoklu Content-Length header'larını temizleme.
Çoklu Transfer-Encoding header'larını temizleme.
Content-Length ile Transfer-Encoding çakışmasını çözme.
Not: Bu normalizasyon, uygulama kodu seviyesinde değil, WAF/proxy/load balancer seviyesinde yapılmalıdır.
5. WAF ve Parser Tutarlılığı
WAF tek başına çözüm değildir! Çünkü:
WAF ile backend farklı parser kullanıyorsa, WAF isteği farklı yorumlayabilir ve backend farklı yorumlayabilir.
Smuggling'in temel nedeni zaten parser ayrışmasıdır.
WAF, smuggling payload'larını yakalayabilir ancak desync riskini ortadan kaldırmaz.
Doğru Yaklaşım:
Frontend ve backend parser'larını RFC 9112 uyumlu hale getirin.
WAF'ı ekstra katman olarak kullanın, tek çözüm olarak görmeyin.
Tüm katmanlarda (WAF, proxy, load balancer, backend) aynı HTTP yorumlamasını sağlayın.
6. İzleme ve Log
Anormal request pattern'lerini izleyin.
Content-Length ve Transfer-Encoding header kombinasyonlarını loglayın.
Timeout ve desync göstergelerini takip edin.
Önbellek davranışını izleyin (cache poisoning tespiti).
HTTP Desync Kontrol Listesi (Güncel):
A. Sunucu Yapılandırması:
Tüm sunucular RFC 9112 uyumlu mu?
HTTP/1.1, HTTP/2 ve HTTP/3 parser'ları tutarlı mı?
Downgrade mekanizmaları (HTTP/2 → HTTP/1.1) güvenli mi?
HTTP/3 gateway yapılandırması desync riskini göz önünde bulunduruyor mu?
B. Header Yönetimi:
Content-Length ve Transfer-Encoding header'ları tutarlı mı?
Çoklu header'lar temizleniyor mu?
Header normalizasyonu yapılıyor mu? (WAF/proxy seviyesinde)
C. Test ve İzleme:
CL.TE, TE.CL, TE.TE testleri yapıldı mı?
HTTP/2 downgrade testleri yapıldı mı?
HTTP/3 downgrade senaryoları değerlendirildi mi?
Request queue poisoning testleri yapıldı mı?
Cache poisoning testleri yapıldı mı?
Response queue desync testleri yapıldı mı?
D. Modern Etki Testleri:
CDN cache poisoning testi yapıldı mı?
Internal API poisoning testi yapıldı mı?
Authentication confusion testi yapıldı mı?
CORS cache poisoning testi yapıldı mı?
HTTP Desync Savunma Stratejisi (Özet):
Parser Tutarlılığı: Tüm katmanlarda RFC 9112 uyumlu davranış.
Downgrade'den Kaçının: HTTP/2 → HTTP/1.1 downgrade'ini mümkünse ortadan kaldırın.
HTTP/3 Farkındalığı: HTTP/3 kullanımında gateway/downgrade risklerini değerlendirin.
Header Normalizasyonu: WAF/proxy seviyesinde header'ları normalleştirin.
WAF + Uygulama: WAF'ı ek katman olarak kullanın, tek çözüm olarak görmeyin.
Sürekli İzleme: Anomalileri, timeout'ları ve desync göstergelerini takip edin.
Düzenli Test: Yetkili ekipler tarafından desync testleri yapın.
Sık Yapılan Hatalar ve Güncel Çözümler:
Eski/Yanlış Yaklaşım Güncel Doğru Yaklaşım
RFC 7230 referansı RFC 9112 kullanın
"Aynı parser kullanın" "RFC 9112 uyumlu davranış"
Application'da chunk decode Proxy/load balancer seviyesinde normalize
"404 dönerse açık var" Timeout + desync + queue poisoning birlikte değerlendirilir
Sadece CL.TE/TE.CL HTTP/2 downgrade, HTTP/3 gateway riskleri
WAF tek çözüm WAF + parser tutarlılığı + izleme
HTTP Desync Attacks Nedir? (Güncel Tanım)
HTTP Desync Attacks (HTTP Request Smuggling) , frontend (proxy, load balancer, CDN) ve backend (web sunucusu) arasındaki HTTP isteklerinin sınırlandırılmasında (Content-Length, Transfer-Encoding, HTTP/2 framing) yaşanan uyumsuzluklar nedeniyle oluşan bir saldırı sınıfıdır. Saldırgan, bu uyumsuzluğu kullanarak istek kuyruğunu zehirleyebilir, önbelleği manipüle edebilir ve diğer kullanıcıların isteklerini etkileyebilir.
Temel Mekanizma:
Frontend ve backend, HTTP isteklerinin nerede bittiğini farklı şekilde yorumlar.
Saldırgan, bu farklı yorumlamayı kullanarak bir isteği "kaçırarak" diğer kullanıcıların isteklerini etkiler.
HTTP Desync Türleri (Güncel Sınıflandırma):
1. CL.TE (Content-Length vs Transfer-Encoding)
Frontend Content-Length, backend Transfer-Encoding kullanır.
Kavramsal Örnek:
http
POST / HTTP/1.1
Host: hedef.com
Content-Length: 36
Transfer-Encoding: chunked
0
GET /admin HTTP/1.1
Host: hedef.com
Gerçekte: CRLF, chunk size, body uzunluğu hassastır. Bu örnek kavramsaldır.
2. TE.CL (Transfer-Encoding vs Content-Length)
Frontend Transfer-Encoding, backend Content-Length kullanır.
Kavramsal Örnek:
http
POST / HTTP/1.1
Host: hedef.com
Content-Length: 4
Transfer-Encoding: chunked
12
GET /admin HTTP/1.1
Host: hedef.com
0
3. TE.TE (Transfer-Encoding vs Transfer-Encoding)
Her iki tarafta TE var, ancak farklı yorumlanıyor (obfuscation).
4. HTTP/2 Desync
H2.TE: HTTP/2 → HTTP/1.1 downgrade sırasında TE uyumsuzluğu.
H2.CL: HTTP/2 → HTTP/1.1 downgrade sırasında CL uyumsuzluğu.
H2 Request Splitting: HTTP/2 frame'lerinin yanlış yorumlanması.
H2C Smuggling: HTTP/2 Clear Text (H2C) üzerinden smuggling.
5. HTTP/3 (QUIC) Perspektifi
HTTP/3 (QUIC), kendi çerçeveleme (framing) mekanizmasını kullandığından klasik CL.TE/TE.CL senaryolarını içermez. Ancak:
HTTP/3 → HTTP/1.1 veya HTTP/2 downgrade işlemlerinde, gateway'ler arasındaki parser farklılıkları nedeniyle desync riskleri oluşabilir.
HTTP/3'ün header compression (QPACK) ve framing yapısı, farklı downgrade senaryolarına yol açabilir.
2026 itibarıyla HTTP/3 yaygınlaşmaya başladığı için, gateway/downgrade senaryoları dikkatle izlenmelidir.
HTTP Desync Saldırılarının Gerçek Etkileri:
YANLIŞ: "Saldırgan /admin'e erişir"
DOĞRU: Smuggling'in asıl etkileri şunlardır:
Request Queue Poisoning: İstek kuyruğunun zehirlenmesi; saldırganın isteği, başka bir kullanıcının isteğinin önüne geçer.
Response Queue Desynchronization: Yanıt kuyruğunun senkronsuzlaşması; yanıtlar farklı kullanıcılara gider.
Cache Poisoning: Önbelleğe, diğer kullanıcıların göreceği hatalı/zararlı yanıtların yerleşmesi.
Session Fixation: Başka kullanıcıların oturumlarının ele geçirilmesi.
Authentication Confusion: Kimlik doğrulama mekanizmasının karışması.
Internal API Poisoning: Dahili API'lere yetkisiz erişim.
Credential Leakage: Diğer kullanıcıların kimlik bilgilerinin sızdırılması.
CDN Cache Poisoning: CDN önbelleğinin zehirlenmesi (geniş etkili).
CORS Cache Poisoning: CORS politikalarının atlatılması.
HTTP Desync Nasıl Tespit Edilir? (Doğru Yaklaşım)
YANLIŞ: "404 dönerse açık var" - Bu tek başına bir kanıt değildir.
DOĞRU: Tespit için şu göstergeler birlikte değerlendirilir:
A. Zaman Tabanlı Göstergeler:
Timeout: İsteklerin zaman aşımına uğraması, olası bir desync göstergesidir. Ancak reverse proxy, load balancer veya network sorunları da timeout üretebilir. Bu nedenle tek başına kanıt değildir.
Gecikme: Normal isteklere göre anormal gecikmeler.
B. Yanıt Tabanlı Göstergeler:
Desync: İkinci isteğin yanıtının bozulması veya farklı bir kullanıcıya gitmesi.
Response Poisoning: Önbelleğe alınan yanıtın beklenenden farklı olması.
C. Queue Tabanlı Göstergeler:
Request Queue Poisoning: Saldırganın isteğinden sonra gönderilen normal isteklerin hatalı yanıt alması.
Response Queue Desync: Yanıtların sırasının karışması.
D. Doğrulama Yöntemi:
Smuggling payload'ı gönderin.
Normal bir istek gönderin.
Normal isteğin yanıtı bozulduysa veya beklenmeyen bir yanıt geldiyse, desync başarılıdır.
HTTP/2 Downgrade (2026 Güncel Konusu)
Neden Önemli?
Birçok modern web uygulaması, istemcilerle HTTP/2 üzerinden iletişim kurar.
Backend sunucuları ise hala HTTP/1.1 kullanıyor olabilir.
Downgrade işlemi sırasında, HTTP/2 frame'leri HTTP/1.1 isteklerine dönüştürülür.
Bu dönüştürme sırasında parser farklılıkları desync'e yol açabilir.
HTTP/2 Downgrade Desync Senaryoları:
H2.TE Desync:
HTTP/2 isteği, backend'e HTTP/1.1 olarak iletilir.
Frontend HTTP/2'de Transfer-Encoding'i desteklemez (HTTP/2'de yoktur).
Backend HTTP/1.1'de Transfer-Encoding'i destekler.
Frontend, Content-Length'i kullanır; backend TE'yi kullanırsa desync oluşur.
H2.CL Desync:
HTTP/2'de Content-Length header'ı varsa, frontend bunu kullanır.
Backend, Content-Length'i farklı yorumlarsa desync oluşur.
HTTP/2 Request Splitting:
HTTP/2 frame'lerinin (HEADERS, DATA) yanlış sınırlandırılması.
Bir frame içinde birden fazla HTTP isteği gönderme.
Koruma Teknikleri (Güncel ve Doğru Yaklaşım):
1. RFC Uyumluluğu
HTTP/1.1 spesifikasyonu artık RFC 9112 ile güncellenmiştir (RFC 7230 eskidir).
Tüm frontend ve backend sunucuları RFC 9112 uyumlu olmalıdır.
RFC 9112, Content-Length ve Transfer-Encoding davranışını daha net tanımlar.
2. Parser Tutarlılığı (ÖNEMLİ)
YANLIŞ: "Aynı parser kullanın" - Bu pratikte mümkün değildir (Nginx, Apache, vb.).
DOĞRU: "Tüm sunucular RFC 9112 uyumlu davranmalı ve aynı HTTP standartlarını benimsemelidir."
Önerilen Pratik:
Nginx, Apache, Envoy, HAProxy gibi yaygın sunucuların güncel sürümlerini kullanın.
Tüm sunucularda aynı HTTP/1.1 davranışını zorunlu kılın.
HTTP/1.1 ve HTTP/2 arasındaki downgrade mekanizmalarını dikkatle yapılandırın.
3. HTTP/2 ve HTTP/3 Yapılandırması
HTTP/2 kullanıyorsanız, backend ile HTTP/2 üzerinden iletişim kurun (downgrade'i ortadan kaldırın).
HTTP/3 kullanımında, gateway'lerin downgrade yaparken desync risklerini göz önünde bulundurun.
Mümkünse uçtan uca (end-to-end) aynı HTTP sürümünü kullanın.
4. Header Normalizasyonu (WAF/Proxy Seviyesinde)
WAF veya proxy, gelen istekleri normalize etmelidir:
Çoklu Content-Length header'larını temizleme.
Çoklu Transfer-Encoding header'larını temizleme.
Content-Length ile Transfer-Encoding çakışmasını çözme.
Not: Bu normalizasyon, uygulama kodu seviyesinde değil, WAF/proxy/load balancer seviyesinde yapılmalıdır.
5. WAF ve Parser Tutarlılığı
WAF tek başına çözüm değildir! Çünkü:
WAF ile backend farklı parser kullanıyorsa, WAF isteği farklı yorumlayabilir ve backend farklı yorumlayabilir.
Smuggling'in temel nedeni zaten parser ayrışmasıdır.
WAF, smuggling payload'larını yakalayabilir ancak desync riskini ortadan kaldırmaz.
Doğru Yaklaşım:
Frontend ve backend parser'larını RFC 9112 uyumlu hale getirin.
WAF'ı ekstra katman olarak kullanın, tek çözüm olarak görmeyin.
Tüm katmanlarda (WAF, proxy, load balancer, backend) aynı HTTP yorumlamasını sağlayın.
6. İzleme ve Log
Anormal request pattern'lerini izleyin.
Content-Length ve Transfer-Encoding header kombinasyonlarını loglayın.
Timeout ve desync göstergelerini takip edin.
Önbellek davranışını izleyin (cache poisoning tespiti).
HTTP Desync Kontrol Listesi (Güncel):
A. Sunucu Yapılandırması:
Tüm sunucular RFC 9112 uyumlu mu?
HTTP/1.1, HTTP/2 ve HTTP/3 parser'ları tutarlı mı?
Downgrade mekanizmaları (HTTP/2 → HTTP/1.1) güvenli mi?
HTTP/3 gateway yapılandırması desync riskini göz önünde bulunduruyor mu?
B. Header Yönetimi:
Content-Length ve Transfer-Encoding header'ları tutarlı mı?
Çoklu header'lar temizleniyor mu?
Header normalizasyonu yapılıyor mu? (WAF/proxy seviyesinde)
C. Test ve İzleme:
CL.TE, TE.CL, TE.TE testleri yapıldı mı?
HTTP/2 downgrade testleri yapıldı mı?
HTTP/3 downgrade senaryoları değerlendirildi mi?
Request queue poisoning testleri yapıldı mı?
Cache poisoning testleri yapıldı mı?
Response queue desync testleri yapıldı mı?
D. Modern Etki Testleri:
CDN cache poisoning testi yapıldı mı?
Internal API poisoning testi yapıldı mı?
Authentication confusion testi yapıldı mı?
CORS cache poisoning testi yapıldı mı?
HTTP Desync Savunma Stratejisi (Özet):
Parser Tutarlılığı: Tüm katmanlarda RFC 9112 uyumlu davranış.
Downgrade'den Kaçının: HTTP/2 → HTTP/1.1 downgrade'ini mümkünse ortadan kaldırın.
HTTP/3 Farkındalığı: HTTP/3 kullanımında gateway/downgrade risklerini değerlendirin.
Header Normalizasyonu: WAF/proxy seviyesinde header'ları normalleştirin.
WAF + Uygulama: WAF'ı ek katman olarak kullanın, tek çözüm olarak görmeyin.
Sürekli İzleme: Anomalileri, timeout'ları ve desync göstergelerini takip edin.
Düzenli Test: Yetkili ekipler tarafından desync testleri yapın.
Sık Yapılan Hatalar ve Güncel Çözümler:
Eski/Yanlış Yaklaşım Güncel Doğru Yaklaşım
RFC 7230 referansı RFC 9112 kullanın
"Aynı parser kullanın" "RFC 9112 uyumlu davranış"
Application'da chunk decode Proxy/load balancer seviyesinde normalize
"404 dönerse açık var" Timeout + desync + queue poisoning birlikte değerlendirilir
Sadece CL.TE/TE.CL HTTP/2 downgrade, HTTP/3 gateway riskleri
WAF tek çözüm WAF + parser tutarlılığı + izleme
