- Konu sahibi
- #1
HTTP request smuggling nedir?
HTTP request smuggling, istemci ile aynı HTTP bağlantısını işleyen ön uç proxy/load balancer ve arka uç web sunucusunun bir isteğin sınırını farklı yorumlamasıdır. Saldırgan, bu yorum farkını kullanarak bir isteğin parçasını sonraki isteğin başı gibi araya sokabilir. Sonuç olarak başka kullanıcıların istekleri etkilenebilir, önbellek zehirlenebilir veya yetkilendirme kontrolleri atlatılmaya çalışılabilir.
Nasıl çalışır?
HTTP/1.1 istek gövdesinin nerede bittiğini belirlemek için özellikle
Content-Length ve Transfer-Encoding: chunked başlıkları önemlidir. Ön uç bu iki başlığı farklı bir kuralla işlerken arka uç diğer kuralı uygularsa, aynı bayt dizisi iki sunucu tarafından farklı isteklere ayrılır.En riskli durumlar, aynı istekte çelişkili gövde uzunluğu bilgileri bulunması veya proxy ile uygulama sunucusunun geçersiz başlıklara farklı tolerans göstermesidir. Başlıkların boşluk, büyük-küçük harf, tekrar veya parçalı aktarım biçimi bakımından farklı yorumlanması da benzer ayrışmaya yol açabilir.
Aşağıdaki gösterim geçerli bir HTTP isteği veya çalıştırılabilir test değildir; yalnız çelişkili uzunluk bilgilerinin konumunu anlatan şemadır:
Kod:
POST /login HTTP/1.1
Host: example.com
Content-Length: [belirli bir uzunluk]
Transfer-Encoding: chunked
[istek gövdesi]Bu örnek tek başına başarılı bir saldırı anlamına gelmez. Ön uç
Transfer-Encoding bilgisini esas alıp gövdeyi erken bitirirken arka uç Content-Length değerini esas alırsa, aradaki veri sonraki isteğin başlangıcı olarak yorumlanabilir. Hangi bileşenin önce geldiği, bağlantının yeniden kullanılıp kullanılmadığı ve sunucuların geçersiz istekleri nasıl reddettiği sonucu belirler.Yaygın yorum uyuşmazlıkları
Aşağıdaki adlandırmalar, hangi başlığın iki bileşen tarafından farklı önceliklendirilmesine göre kullanılır:
| Durum | Uyuşmazlık | Olası sonuç |
|---|---|---|
| CL.TE | Ön uç Content-Length, arka uç Transfer-Encoding kullanır | Arka uçta kalan veri sonraki istek gibi görülebilir |
| TE.CL | Ön uç Transfer-Encoding, arka uç Content-Length kullanır | İstek kuyruğunun ayrılması bozulabilir |
| TE.TE | Her iki taraf da Transfer-Encoding kullanır ancak biçimi farklı yorumlar | Aynı bağlantıda istek sınırı ayrışabilir |
Sınıflandırma, iki katmanın hangi uzunluk bilgisini kullandığını karşılaştırır. Uygulama sunucusu tek başına güvenli görünse bile önündeki CDN, WAF, reverse proxy veya ingress bileşeni farklı davranıyorsa risk devam edebilir.
Savunma ve teşhis adımları
- İstek yolundaki tüm bileşenleri listeleyin: CDN veya WAF, load balancer, reverse proxy, servis mesh ve uygulama sunucusu. Her katmanın HTTP sürümünü, bağlantı yeniden kullanımını ve geçersiz istek politikasını belgeleyin.
- Çelişkili veya geçersiz gövde uzunluğu başlıklarını ortak bir politikayla reddedin. Özellikle
Content-LengthileTransfer-Encodingbirlikte geldiğinde isteği arka uca iletmek yerine bağlantıyı kapatmak daha güvenli bir varsayımdır. - Her bileşeni üreticisinin desteklediği ve ilgili ayrıştırma düzeltmelerini içeren sürümde tutun. Ara katmanlarda geçersiz istek reddi ve protokol dönüşümünü birlikte denetleyin; farklı ürünlerin ayrıştırıcılarının kendiliğinden aynı davrandığını varsaymayın.
- Yalnızca yetkili olduğunuz izole test ortamında, zararsız ve benzersiz bir işaret içeren isteklerle katmanların loglarını karşılaştırın. Beklenmeyen ikinci istek, farklı gövde uzunluğu veya bağlantının erken kapanması görülürse testi durdurup ayrıştırma farkını inceleyin.
- Düzeltmeden sonra aynı testi her ara katmanda tekrarlayın. Bir katmanda reddedilen isteğin arka uca ulaşmadığını doğrulayın; yalnızca WAF uyarı üretmesi, isteğin gerçekten engellendiğini kanıtlamaz.
İlk karar, sistemde birden fazla HTTP ayrıştırıcısı bulunup bulunmadığını belirlemektir. Tek sunuculu basit bir yapı ile CDN, WAF ve birden fazla proxy içeren zincirin riski ve test yöntemi aynı değildir. HTTP/2 kullanılan yapılarda klasik HTTP/1.1 gövde sınırı sorunu doğrudan aynı biçimde ortaya çıkmayabilir; ancak HTTP/2’den HTTP/1.1’e geçiş yapan bir ara katman varsa dönüşümün nasıl yapıldığı ayrıca denetlenmelidir.
Sık sorulan sorular
Response splitting ile aynı açık mıdır?
Hayır. Response splitting, örneğin yanıt başlıklarına denetimsiz CR/LF girmesiyle bir yanıtın birden fazla yanıtmış gibi ayrılmasına yol açabilir. Request smuggling ise istek sınırının HTTP katmanları arasında farklı yorumlanmasıdır. İki durumun etkileri kesişebilse de girdinin işlendiği yer ve düzeltme yolu aynı değildir.
WAF kullanmak tek başına yeterli midir?
Genellikle hayır. WAF belirli kalıpları engelleyebilir ancak proxy ile arka uç sunucusunun farklı ayrıştırma davranışını düzeltmez. Kalıcı çözüm, çelişkili istekleri tutarlı biçimde reddetmek ve tüm HTTP ara katmanlarının aynı sınırlandırma politikasını uygulamasını sağlamaktır.
