Türkiye'nin ilk Cross-Platform OldSchool MOBİL & PC 1-99 Sunucusu Lamira2 6 Kasım'da Açılıyor! Büyük Açılışı Kaçırma HEMEN TIKLA!
HTTP Request Smuggling: Reverse Proxy ve Backend Arasındaki Güven Problemi
Web uygulamalarında güvenlik denildiğinde genellikle SQL Injection, XSS veya yetkilendirme açıkları akla geliyor. Ancak bazı açıklar doğrudan uygulama kodundan değil, isteğin sunucuya ulaşana kadar geçtiği katmanların aynı veriyi farklı yorumlamasından kaynaklanıyor.HTTP Request Smuggling de tam olarak bu noktada karşımıza çıkıyor.
Özellikle reverse proxy, load balancer ve backend sunucusunun birlikte kullanıldığı mimarilerde, gelen HTTP isteğinin nerede bittiği konusunda bir yorumlama farkı oluşması ciddi güvenlik sorunlarına yol açabiliyor.
HTTP Request Smuggling nedir?
HTTP Request Smuggling, bir HTTP isteğinin ön taraftaki sunucu veya proxy ile arka taraftaki sunucu tarafından farklı şekilde yorumlanması sonucunda ortaya çıkan bir güvenlik açığı türüdür.Bir web uygulamasının tipik istek akışı şu şekilde olabilir:
İstemci → Reverse Proxy → Backend Sunucusu → Uygulama
Reverse proxy, gelen istekleri karşılar ve ilgili backend sunucusuna iletir. Performans ve kaynak kullanımı açısından backend bağlantıları tekrar kullanılabilir. Sorun, iki katmanın gelen verinin nerede sona erdiği konusunda anlaşamamasıyla başlayabilir.
Örneğin proxy bir isteğin tamamlandığını düşünürken backend aynı verinin devam ettiğini düşünebilir. Bu durumda tek bir bağlantı üzerinden taşınan istekler beklenenden farklı ayrıştırılabilir.
Buradaki kritik nokta, isteğin yalnızca hatalı olması değil, iki farklı bileşenin aynı isteğe farklı anlamlar yüklemesidir.
Bu problem nasıl ortaya çıkıyor?
HTTP/1.1 protokolünde mesaj gövdesinin uzunluğunu belirlemek için kullanılan başlıca mekanizmalardan ikisi şunlardır:- Content-Length
- Transfer-Encoding
Bazı hatalı veya tutarsız yapılandırmalarda, bu başlıkların birlikte bulunduğu bir istek proxy ve backend tarafından farklı işlenebilir. Başlıklardan birini esas alan katman ile diğerini esas alan katman arasında istek sınırı uyuşmazlığı oluşması, Request Smuggling sorunlarının bilinen nedenlerinden biridir.
Bu tür sorunlar özellikle HTTP ayrıştırıcılarının farklı davranması, hatalı başlıkların kabul edilmesi veya proxy'nin gelen isteği güvenli biçimde normalize etmeden backend'e aktarması durumlarında önem kazanır.
Her Content-Length veya Transfer-Encoding kullanımı bir açık anlamına gelmez. Asıl mesele, bileşenlerin protokolü nasıl uyguladığı ve çelişkili girdileri nasıl ele aldığıdır.
CL.TE, TE.CL ve TE.TE ne anlama geliyor?
Güvenlik araştırmalarında bu kısaltmalar, ön taraftaki bileşenin ve backend'in mesaj sınırını belirlerken hangi mekanizmayı esas aldığını anlatmak için kullanılır.CL.TE: Ön taraftaki bileşen Content-Length, backend ise Transfer-Encoding davranışını esas alır.
TE.CL: Ön taraftaki bileşen Transfer-Encoding, backend ise Content-Length davranışını esas alır.
TE.TE: Her iki bileşen de Transfer-Encoding kullanıyor gibi görünür ancak başlığın işlenişindeki farklılıklar veya tutarsızlıklar ayrıştırma uyuşmazlığına yol açabilir.
Bu adlandırmalar, farklı HTTP işleme davranışlarını sınıflandırmak için kullanılır. Bir sistemin bu kategorilerden birine girmesi tek başına doğrulanmış bir güvenlik açığı bulunduğunu göstermez; güvenli ve yetkili bir ortamda test edilmesi gerekir.
Bir web uygulaması için sonuçları neler olabilir?
Açığın etkisi, sunucu mimarisine ve isteğin nasıl işlendiğine göre değişir. Olası sonuçlar arasında şunlar bulunabilir:- İsteklerin yanlış kullanıcı veya oturum bağlamında işlenmesi.
- Proxy önbelleğinin beklenmeyen içerikle etkilenmesi.
- Erişim kontrollerinin bazı senaryolarda yanlış uygulanması.
- Backend'e ulaşan isteklerin beklenmedik biçimde birleştirilmesi veya ayrıştırılması.
- Başka güvenlik sorunlarının ortaya çıkmasını kolaylaştıran bir ortam oluşması.
Nasıl önlem alınabilir?
Bu sorunu yalnızca tek bir HTTP başlığını engelleyerek çözmeye çalışmak yeterli değildir. Proxy ve backend arasındaki istek işleme davranışını bir bütün olarak ele almak gerekir.1. Proxy ve backend yazılımlarını güncel tutun.
HTTP ayrıştırma ve bağlantı yönetimiyle ilgili bilinen sorunlar için güvenlik güncellemelerini takip edin. Kullanılan sürümlerin güvenlik duyurularını ayrıca kontrol edin.
2. Çelişkili veya hatalı istekleri güvenli şekilde reddedin.
HTTP mesaj sınırlarını belirleyen başlıklardaki tutarsızlıklar kabul edilmemeli; istekler belirsiz biçimde işlenmek yerine reddedilmelidir.
3. Proxy ile backend arasındaki davranışı doğrulayın.
Ön taraftaki katmanın isteği nasıl yorumladığı ile backend'in nasıl işlediği karşılaştırılmalıdır. Özellikle HTTP/1.1 bağlantı yeniden kullanımı ve protokol geçişleri göz önünde bulundurulmalıdır.
4. Güvenlik testlerini gerçek mimariye göre yapın.
Yalnızca uygulamanın kendisini test etmek yeterli olmayabilir. Reverse proxy, load balancer ve backend arasındaki akış da test kapsamına alınmalıdır. Bu işlemler üretim sistemleri yerine yetkili test ortamlarında yapılmalıdır.
5. Logları ve anormal bağlantı davranışlarını izleyin.
Beklenmedik 400 yanıtları, bağlantı kapanmaları ve proxy-backend logları arasındaki uyuşmazlıklar araştırılmaya değer sinyaller olabilir. Bunlar tek başına açığın kanıtı değildir ancak hata ayıklamada yardımcı olur.
Sonuç
HTTP Request Smuggling, web güvenliğinde yalnızca uygulama koduna bakmanın neden yeterli olmadığını gösteren iyi örneklerden biri. Uygulama doğru çalışıyor gibi görünse bile, önündeki proxy ile backend arasındaki protokol işleme farkları güvenlik riski oluşturabilir.Bu nedenle güvenli bir web mimarisi kurarken yalnızca hangi sunucunun kullanıldığına değil, bu bileşenlerin HTTP isteklerini nasıl ayrıştırdığına ve birbirleriyle nasıl iletişim kurduğuna da bakmak gerekiyor.
Kaynaklar:
- PortSwigger Web Security Academy — HTTP Request Smuggling:
Linkleri görebilmek için Turkmmo Forumuna ÜYE olmanız gerekmektedir.
- OWASP — HTTP Request Smuggling:
Linkleri görebilmek için Turkmmo Forumuna ÜYE olmanız gerekmektedir.
- RFC 9112 — HTTP/1.1:
Linkleri görebilmek için Turkmmo Forumuna ÜYE olmanız gerekmektedir.
