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çek bir kullanım boşluğunu dolduruyor. Güvenlik riski ise spesifikasyonun kendisinden değil, downstream bileşenlerin metod ve gövde varsayımlarını farklı uygulamasından doğabilir. Haziran 2026'dan önce yazılmış WAF kuralları, reverse-proxy yönlendirmesi, framework middleware'i ve load balancer politikaları QUERY'yi açıkça ele almıyor olabilir. IETF metni, QUERY isteğinin safe ve idempotent olduğunu; sorgu girdisinin ise request content içinde taşındığını açıklar. RFC 10008 — The HTTP QUERY Method

Buradaki değerlendirme doğrulanmış bir “her WAF bypass olur” bulgusu değildir. Aşağıdaki vektörler, QUERY desteği eklenirken her bileşenin aynı semantiği uygulayıp uygulamadığını sınayan araştırma hipotezleridir. Gerçek etki; WAF, CDN, cache, framework, origin ve uygulama endpoint’inin konfigürasyonuna göre ölçülmelidir.

RFC 10008 neyi tanımlıyor?

RFC 10008’in üç özelliği güvenlik incelemesinin başlangıç noktasıdır:

Özellik	QUERY için anlamı	Güvenlik sonucu
Safe	Sunucu tarafında kaynak durumunu değiştirmeyen query işlemi	CSRF ve cache politikaları otomatik varsayılamaz
Idempotent	Aynı query’nin tekrar edilmesi farklı kısmi durum üretmemeli	Retry ve proxy davranışı test edilmelidir
Request content	Query girdisi URI yerine gövdede taşınır	WAF ve logging gövdeyi gerçekten incelemeli

Safe, “gövde taşımaz” anlamına gelmez. Idempotent, “her uygulama implementasyonu risksizdir” anlamına gelmez. Origin uygulaması RFC semantiğini bozup yan etki üretiyorsa, bu artık uygulama tasarım hatasıdır ve ayrı değerlendirilmelidir.

İlk doğrulama: metod zinciri aynı şeyi mi görüyor?

Bir endpoint’i test ederken yalnızca origin sunucusuna QUERY gönderip cevap almak yeterli değildir. İstek şu zincirden geçer:

Client → CDN / WAF → Load Balancer → Reverse Proxy → Framework → Origin

Her hop için şu alanları kaydedin: metod, Content-Type, Content-Length/Transfer-Encoding, gövde hash’i, status code, cache status, log görünürlüğü ve response header’ları. Bir bileşen QUERY’yi reddederken diğeri GET gibi işliyorsa, güvenlik kontrolü ile uygulama davranışı arasında fark oluşur.

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.

Güvenli test planı

Bu metodun etkisini üretim trafiğine payload göndererek ölçmek yerine, aynı endpoint’in staging kopyasında kontrollü bir matris kullanın:

1. Aynı zararsız query gövdesini GET, POST ve QUERY ile karşılaştırın.
2. WAF’in izin, blok ve log sonuçlarını; origin’in aldığı metod ve gövdeyle eşleştirin.
3. Cache açık ve kapalı senaryolarda Age, Cache-Control, Vary ve cache key davranışını kaydedin.
4. CSRF/CORS middleware’inin QUERY için hangi yolu izlediğini test edin.
5. HTTP/1.1 ve HTTP/2 geçişinde Content-Length, transfer framing ve gövde sonlandırmasını doğrulayın.
6. Proxy zincirindeki her bileşenin aynı isteği aynı şekilde logladığını kontrol edin.

Kabul kriteri “QUERY çalıştı” değildir. Kabul kriteri; izin verilen endpoint’lerin beklenen şekilde çalışması, yetkisiz gövde ve origin davranışının görünür olması, cache/CSRF/CORS politikalarının belgelenmesi ve desync testlerinin metod kapsamını açıkça göstermesidir.

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.

QUERY için allowlist ve gözlemlenebilirlik politikası

İlk uygulama aşamasında tüm endpoint’leri otomatik olarak QUERY kabul eder hâle getirmek yerine, metod allowlist’ini route ve içerik tipi bazında tanımlamak daha güvenlidir. Her route için şu kararlar yazılı olmalıdır:

• QUERY destekleniyor mu, yoksa açıkça reddediliyor mu?
• Hangi Content-Type ve gövde şeması kabul ediliyor?
• Yanıt cache’lenebilir mi; cache key hangi bileşenlerden oluşuyor?
• Loglarda metod, gövde boyutu, gövde hash’i ve karar sonucu görünür mü?
• Origin’in query işlemi gerçekten safe/idempotent mi?
• Uygulama veya proxy beklenmeyen yan etki üretirse hangi kill switch kullanılacak?

WAF ekipleri mevcut GET/POST test setini kopyalayıp yalnızca method alanını değiştirmemelidir. QUERY gövdesinin parsing, normalization, content inspection ve log redaction zincirinden geçtiği ayrı ayrı görülmelidir.

Test sınıfı	Beklenen kontrol
Normal query	Origin doğru gövdeyi alır, beklenen response döner
Zararsız büyük gövde	Boyut limitleri ve hata kodu tutarlıdır
Kötü niyetli örnek	WAF incelemesi ve log kararı görünürdür
Cache karşılaştırması	Aynı URI, farklı gövde için yanlış cache paylaşımı yoktur
CSRF/CORS	Uygun token ve preflight politikası uygulanır
Desync/framing	Ön uç ve arka uç gövde sınırında aynı kararı verir

Bir testin “geçti” sayılması için yalnızca response status’a bakmak yeterli değildir. WAF logu, origin access logu, CDN cache status’u ve uygulama audit kaydı aynı request ID ile ilişkilendirilmelidir.

Bu konu için doğru arama niyeti

RFC 10008 hakkında arama yapan kişi genellikle standardın ne olduğunu, QUERY’nin GET’ten farkını veya WAF/reverse proxy tarafında neyi test etmesi gerektiğini öğrenmek ister. Bu nedenle içerik “WAF bypass kesinleşti” iddiası yerine üç soruyu doğrudan cevaplamalıdır: safe/idempotent ne demektir, gövde taşıyan safe metod hangi varsayımları bozar ve ekip bunu staging’de nasıl kanıtlar?

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

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