(Savunma Odaklı Teknik İnceleme – VIP İçerik)

1) Kapsam ve Yasal Çerçeve

Bu içerik yalnızca:

• Kendi sistemlerinizde,
  
• Yazılı izinli pentest/sızma testi kapsamında,
  
• Kurum içi güvenlik doğrulaması ve iyileştirme amacıyla

kullanılmak üzere hazırlanmıştır. Üçüncü taraf sistemlerde izinsiz deneme yapmak hukuki ve cezai sonuç doğurabilir. Buradaki amaç, “nasıl kırılır” değil; nasıl anlaşılır, nasıl yakalanır, nasıl kapatılır sorularına teknik cevap vermektir.

---

2) HTTP/2 Desync Nedir? (Kısa Tanım)

Desync (senkron kayması); istemci–ara katman (CDN/WAF/Load Balancer/Reverse Proxy) – uygulama sunucusu (backend) arasında istek sınırlarının farklı yorumlanmasıyla oluşan bir durumdur.


HTTP/2’de tek TCP bağlantısı üzerinde çoklu stream ve frame yapısı vardır. Araya giren bileşenler (özellikle “HTTP/2 → HTTP/1.1 dönüşümü” yapan proxy/LB’ler), istekleri backend’e aktarırken:

• Header’ları normalize eder,
  
• Gövde (body) uzunluğu/sonlandırmasıyla ilgili farklı kurallar uygular,
  
• Stream’leri sıraya alır / birleştirir / bölüştürür,

ve bu süreçte aynı bayt dizisini iki taraf farklı istek sınırları olarak algılarsa, istemcinin “tek istek” sandığı şey, backend’de “iki istek” gibi görülebilir (veya tersi). İşte bu kayma, bazı senaryolarda güvenlik kontrollerinin atlandığı algısını oluşturabilir.

---

3) Neden “Load Balancer Atlatma” ile Anılır?

Çünkü pratikte güvenlik politikaları çoğunlukla şu katmanlarda uygulanır:

• CDN / WAF (L7 filtre)
  
• Load Balancer / Reverse proxy (routing, header rewriting, rate limit)
  
• API Gateway

Eğer bu katman ile backend’in HTTP semantiği veya istek ayrıştırma (parsing) davranışı birebir uyuşmazsa:

• LB’nin “tek istek” dediğine backend “iki istek” diyebilir,
  
• WAF’nin engellediği bir pattern, dönüşüm/normalize süreçlerinde farklılaşabilir,
  
• Bazı header’lar/alanlar bir katmanda yok sayılırken diğerinde geçerli olabilir.

Bu yüzden risk; tek başına HTTP/2’den değil, zincirin en zayıf halkasından doğar: LB ↔ proxy ↔ backend uyumsuzluğu.

---

4) Risk Senaryoları (Yüksek Seviye)

Aşağıdaki başlıklar, saldırı tarifine girmeden, savunmacıların “neye bakmalı” sorusunu cevaplar:

4.1 Yetki ve Oturum Sınırlarının Bulanıklaşması

• Bir katmanda “oturumlu” görünen istek, diğerinde “oturumsuz” ayrışabilir.
  
• Header normalizasyonu (ör. duplicated header’lar, case/whitespace davranışı) politikaları etkileyebilir.

4.2 Route/Host Bazlı Politikaların Aşınması

• LB’de route seçimi ile backend’de route çözümü farklı davranırsa, istek başka bir handler’a düşebilir.
  
• Özellikle microservice mimarilerde “edge routing” ile “service routing” tutarsızlığı kritik.

4.3 Cache/Rate Limit Yanılsamaları

• LB tek isteğe rate limit uygular, backend iki iş yapar gibi log düşebilir.
  
• Cache anahtarı (cache key) ile backend davranışı uyuşmazsa “anlamsız” cache sonuçları görülebilir.

---

5) Desync’i Tetikleyen Tipik Mimari Koşullar

Aşağıdaki durumlar “risk olasılığını” artırır:

1. HTTP/2 → HTTP/1.1 downgrade yapan katmanlar
   (Edge HTTP/2 konuşur, backend HTTP/1.1’dir.)
   
2. Birden fazla proxy katmanı (CDN → WAF → LB → ingress → service mesh)
   
3. Farklı vendor/parsing implementasyonları
   (Örn. bir katman strict RFC yorumu, diğeri toleranslı yorum.)
   
4. Header rewriting / normalize işlemlerinin yoğun olması
   (X-Forwarded-*, Host rewrite, path normalize, compression vb.)
   
5. Request buffering/streaming farkları
   (Bir katman body’yi tamponlar, diğeri chunk/stream taşır gibi davranır.)

---

6) Savunma: Tespit (Detection) Rehberi

Desync çoğu zaman “sessizdir”; klasik imza tabanlı WAF kuralı her zaman yakalayamaz. Bu nedenle telemetri korelasyonu şart.

6.1 Log Korelasyonu: “Edge ↔ Backend” Tutarlılık Kontrolü

Aşağıdaki alanları her katmanda tutarlı toplayın:

• Request ID (tekil): X-Request-ID gibi uçtan uca taşınan bir kimlik
  
• Stream/Connection bilgisi (edge): HTTP/2 stream id, connection reuse
  
• Path + Query normalize edilmiş hali
  
• Content length / body byte count (mümkünse ham ölçüm)
  
• Response code + latency

Şüpheli sinyaller:

• Edge log’unda 1 istek, backend’de aynı request-id ile “beklenmedik ek işlem/handler” izi
  
• Aynı bağlantı üzerinde sıra dışı 4xx/5xx patlaması (özellikle gateway timeout + backend 200 gibi tutarsızlık)
  
• Backend’de “bad request parsing” artışı + edge’de normal 200 akışı

6.2 Metrikler ve Alarm Kuralları

• backend_4xx_parse_error metrikleri
  
• upstream_reset / stream_error / protocol_error artışı
  
• Aynı kullanıcı ajanı / aynı IP havuzunda anomali (ama tek başına IP’ye güvenmeyin)

6.3 Güvenlik İzleri

• Beklenmeyen “routing” (servis A beklenirken servis B)
  
• Oturum doğrulaması yapılan endpoint’lerde “kimliksiz” erişim denemesi anomalisi
  
• Rate limit sistemi “normal” görünürken backend CPU/DB yükünün artması

---

7) Savunma: Önleme (Mitigation) Stratejileri

7.1 Zinciri Sadeleştir ve Tek Bir Parse Otoritesi Belirle

• Mümkünse uçtan uca HTTP/2 veya uçtan uca HTTP/1.1; “arada dönüşüm” risk yüzeyini artırır.
  
• Dönüşüm kaçınılmazsa: tek bir katmanı “canonical parser” olarak tasarlayın (örn. ingress), diğer katmanlar daha “pasif” kalsın.

7.2 Strict Parsing ve RFC Uyumlu Davranış

• Proxy/LB’de strict mode (vendor’a göre değişir) tercih edin.
  
• “Çift anlamlı” header durumlarını reddedin:
  
  
  • Yinelenen kritik header’lar (özellikle auth, host, content-length benzeri alanlar)
    
  • Anormal whitespace/obs-fold benzeri eski davranışlar (modernde reddedilmeli)

7.3 Normalizasyonu Standardize Et

• Path normalize (//, /./, /../), URL decode politikaları: tek ve tutarlı
  
• Header canonicalization: case/boşluk/kodlama tutarlılığı
  
• X-Forwarded-* / Forwarded kullanımını netleştirin (ikisini aynı anda “yarışır” bırakmayın)

7.4 Backend’i “Güvenlik Kaynağı” Yap

LB/WAF kuralı kaçsa bile:

• Backend framework/gateway katmanında mutlaka authz/authn doğrulaması
  
• “Edge’de doğrulandı” varsayımı yapmayan zero-trust servis tasarımı
  
• Internal endpoint’leri network policy ile kapatın (service-to-service allowlist)

7.5 Request Buffering ve Limitler

• Maksimum header size, maksimum body size, maksimum concurrent stream limitleri
  
• Aşırı uzun/çok header içeren istekleri erken reddetme
  
• Upstream timeouts: tutarlı ve katmanlar arasında uyumlu

7.6 Vendor Spesifik Hardening Kontrol Listesi

Her ürünün ayarı farklıdır ama kontrol listesi aynı:

• HTTP/2 enabled/disabled kararını risk analiziyle verin
  
• HTTP/2 → HTTP/1.1 dönüşüm davranışlarını dokümante edin
  
• “Header merge / duplicate header policy” ayarlarını inceleyin
  
• WAF ve LB’nin log seviyelerini geçici olarak artırıp baseline çıkarın

---

8) Güvenli Test Yaklaşımı (İzinli ve Zarar Vermeden)

VIP alandaki ekipler için etik test metodolojisi:

1. Staging ortamı kurun: prod ile aynı LB/proxy zinciri ve aynı konfigürasyon
   
2. Gözlemle-ölç: edge + ingress + backend loglarını tek panelde korele edin
   
3. Protokol uyumluluk testleri:
   
   
   • farklı client’lar (tarayıcı, mobil, servis)
     
   • farklı bağlantı davranışları (connection reuse, paralel stream)
4. Negatif testler: parsing hatası üreten “uygunsuz” isteklerin tüm katmanlarda aynı şekilde reddedildiğini doğrulayın
   
5. Canary rollout: strict ayarları önce küçük trafikte deneyip regresyon izle

Burada amaç “istismar kanıtı” üretmek değil; katmanların aynı şeyi aynı şekilde anladığını doğrulamak.

---

9) Operasyonel Öneriler (SOC / Blue Team)

• Runbook: “Parse error spike” ve “edge-backend mismatch” için olay müdahale akışı
  
• SIEM kuralı: aynı request-id ile çelişkili status/latency
  
• Threat hunting: belirli UA örüntülerinde HTTP/2 stream error artışı
  
• Değişiklik yönetimi: LB/WAF güncellemelerinden sonra regression test zorunluluğu

---

10) Sonuç

HTTP/2 desync; çoğu zaman “tek bir ürün zafiyeti” değil, mimari uyumsuzluk problemidir. Modern altyapılarda (CDN → WAF → LB → ingress → microservice) küçük bir parsing farkı bile, güvenlik kontrollerinin beklenmedik şekilde “sapmasına” neden olabilir.


VIP ekipler için ana mesaj:

• Korelasyon (log/metric) olmadan görünmez,
  
• Standardizasyon (tek parse yaklaşımı) olmadan kalıcı çözülmez,
  
• Backend zero-trust olmadan “edge’e güven” yaklaşımı risklidir.

---