Bu neden şimdi önemli

Haziran 2026'da IETF, yeni bir HTTP metodunu standartlaştıran RFC 10008'i yayımladı: QUERY. Bu metod GET gibi davranmak üzere tasarlandı — güvenli (sunucu tarafında durum değişikliği yok) ve idempotent (tekrar denemek güvenli) — ama aynı zamanda POST'un yaptığı gibi bir request gövdesi taşıyor; böylece karmaşık sorguların URL'ye sıkıştırılması gerekmiyor.

Bu, HTTP'de gerçekten faydalı bir boşluğu dolduruyor. Ama şu anda, çoğu güvenlik aracının varlığından haberdar olmadığı bir boşluk da bu. Haziran 2026'dan önce yazılmış WAF kuralları, reverse-proxy yönlendirmesi, framework middleware'i ve load balancer politikaları örtük bir varsayım üzerine kuruldu: durum değiştiren, gövde taşıyan istekler POST/PUT/PATCH/DELETE'tir, GET ise güvenlidir ve gövdesizdir. QUERY bu varsayımı tam ortadan ikiye böler — GET gibi güvenli, POST gibi gövde taşıyan — ve altı ay önce yazılmış bir metod allowlist'inin bundan haberdar olmasının hiçbir sebebi yok.

Beş somut istismar vektörü

1. WAF inceleme boşlukları. POST/PUT gövdelerini injection payload'ları için inceleyecek, GET'i ise düşük riskli sayacak şekilde ayarlanmış kural setleri, QUERY için gövde incelemesini hiç uygulamayabilir — ya da QUERY'yi hiç gövdeye bakmayan bir GET-şekilli kod yoluna yönlendirebilir. POST üzerinde yakalanacak bir payload, QUERY üzerinden incelenmeden geçebilir.

2. Cache poisoning. Cache'ler geleneksel olarak URL (artı bazı header'lar) üzerinden anahtarlanır çünkü GET istekleri anlamlı şekilde değişen gövdeler taşımaz. QUERY istekleri taşır. Yalnızca URL üzerinden anahtarlanan ve GET benzeri göründüğü için QUERY yanıtlarını cache'lemeye başlayan bir cache zehirlenebilir: saldırgan, cache'lenebilir bir endpoint'e kötü niyetli gövdeli bir QUERY gönderir, aynı URL'ye yapılan sonraki meşru istekler saldırganın cache'lenmiş yanıtını alır.

3. CSRF kör noktaları. CSRF middleware'i genellikle yalnızca POST/PUT/DELETE'in durum değiştirebileceğini varsayar ve GET-benzeri metodları token kontrolünden muaf tutar. Bir endpoint QUERY arkasında bir yan etki uyguluyorsa — hatta POST için yazılmış bir handler'ın yeniden kullanılması yoluyla kazara bile olsa — bu endpoint CSRF token'ı olmadan erişilebilir olabilir, çünkü framework QUERY'yi "güvenli" olarak sınıflandırmıştır.

4. CORS ve preflight işleme. Tarayıcılar, framework'ler ve CDN'lerin QUERY'nin CORS preflight'ını nasıl tetikleyeceği (ya da tetiklemeyeceği) konusunda uyuşması gerekir. Zincirdeki bileşenler anlaşamadığında — biri "basit istek" sayar, diğeri preflight ister — sonuç ya meşru trafiğin bozulması ya da cross-origin erişimi kapıya alması gereken preflight kontrolünün atlatılmasıdır.

5. Request smuggling. QUERY isteklerini farklı şekilde ayrıştıran ön uç ve arka uç bileşenleri — biri gövdeyi dikkate alırken diğeri GET-eşdeğeri sayıp yok sayması, ya da gövdenin nerede bittiği konusunda anlaşamamaları — HTTP request smuggling'in her zaman istismar ettiği ön uç/arka uç senkronizasyon bozukluğu sınıfını yeniden açar; bu sefer çoğu smuggling tespit aracının hiç test etmediği bir metodla.

Bu neden tipik bir yeni-özellik boşluğundan daha kötü

Bu beş vektörden hiçbiri QUERY'nin spesifikasyonunda bir hata gerektirmiyor. Bunlar, QUERY'nin gerçekte ne olduğu (güvenli VE gövde taşıyan — önceki hiçbir standart metodun sahip olmadığı bir kombinasyon) ile her downstream güvenlik kontrolünün "güvenli metod" için varsaydığı şey (incelemeye değer bir gövde yok) arasındaki uyumsuzluktan doğuyor. Buradaki zafiyet, tek bir bileşenin içinde değil, bileşenler arasındaki boşlukta yaşıyor — bu da tam olarak tek bir ekibin gözden kaçırması kolay olan türden bir sorun, çünkü hiçbir bileşen tek başına "yanlış" değil.

Savunma kontrol listesi

• WAF'ınızı fark testinden (differential test) geçirin. Aynı payload'ları hem POST hem QUERY ile aynı endpoint'lere gönderip sonuçları karşılaştırın. POST'ta engellenip QUERY'de geçen herhangi bir payload, göz ardı edilecek bir false negative değil, bir kural seti boşluğudur.
• Cache-key oluşturmayı denetleyin. CDN/reverse-proxy cache anahtarlarınızın QUERY için yalnızca URL ve header değil, tam gövde hash'ini de içerdiğini doğrulayın. QUERY yanıtları cache'leniyorsa, bu kararın bilinçli verildiğini teyit edin.
• CSRF middleware'ini sabit kodlanmış metod listeleri için yeniden gözden geçirin. if method in ['POST', 'PUT', 'DELETE'] tarzı kontrollere, yan etkisi olabilecek her endpoint için — mevcut bir POST route'undan yeniden kullanılan handler'lar dahil — QUERY'nin açıkça eklenmesi gerekir.
• Load balancer, reverse proxy ve framework QUERY desteğini uçtan uca doğrulayın, yalnızca origin'de değil. QUERY'yi sessizce düşüren veya sınıf değiştiren bir bileşen, testte çalışıp production'da bozulan/atlatılan bir sürprize yol açabilir.
• CORS preflight davranışını her hop için (tarayıcı, CDN, uygulama sunucusu) QUERY özelinde doğrulayın, tutarlılığı varsaymak yerine.
• Request-smuggling tespit araçlarınızın QUERY kapsamını kontrol edin. Mevcut desync test araçlarının çoğu bu metoddan önce yazıldı; gerçekten QUERY yollarını test ettiğini, sessizce atlamadığını doğrulayın.

Bu ne anlama gelmiyor

Bu yazı RFC 10008'in güvensiz olduğu ya da QUERY'nin benimsenmemesi gerektiği iddiası değil. Yeni bir metodun, o zamanki mantıklı varsayımlarla göreceği metod kümesinin sabit olduğunu düşünen bileşenlerle dolu bir ekosisteme girmesinin doğrudan bir sonucu. Çözüm envanter ve testtir, kaçınmak değil — QUERY'yi bilinçli benimseyip zinciri uçtan uca denetleyen ekipler, genelde QUERY'yi hiç benimsemeyen ama varsayılan metod işleme davranışını hiç incelememiş ekiplerden daha iyi durumda olacaktır; çünkü framework'ler ve proxy'ler, uygulama bilinçli kullanmasa bile upgrade sonrası QUERY'yi kabul etmeye başlayabilir.

Eresus Guard ile kanıt odaklı kapsama

Bu tür metod seviyesi boşluklar, bir kez doğrulanıp sonra proxy'ler, framework'ler ve WAF kural setleri bağımsız şekilde güncellendikçe sessizce eskiyen türden bulgulardır. Eresus Guard'ın DAST ve yapılandırma kontrolleri, varlık envanteri genelinde QUERY'ye özgü test senaryolarına yönlendirilebilir; neyin, hangi bileşende, hangi sonuçla test edildiği kanıtı tek seferlik bir Slack mesajı yerine tek bir denetlenebilir kayıtta tutulur. Eresus Guard çalışma alanını inceleyebilir veya kapsam görüşmesi planlayabilirsiniz.

Kaynaklar

• RFC 10008: The New HTTP QUERY Method and the Attack Surface Still Catching Up — Hive Security