HTTP Request Smuggling, bir web sitesinin bir veya daha fazla HTTP istek dizisinin işleyişine müdahale edilmesi yöntemidir. Bir saldırganın güvenlik önlemlerini aşmasına, hassas verilere yetkisiz erişim elde etmesine ve diğer kullanıcıların güvenliğini doğrudan tehdit etmesine olanak tanır.
HTTP Request Smuggling Saldırı Mantığı Nedir?
Günümüz web uygulamaları, kullanıcıları asıl uygulama sunucusuna bağlamak için genellikle HTTP sunucu zincirlerini kullanır.
Kullanıcılar, bir veya daha fazla back-end server’a ileten bir front-end server’a (load-balancer veya reverse proxy olarak da bilinir) istekte bulunurlar. Modern bulut tabanlı sistemlerde, bu tasarım biçimi daha sık ve bazı durumlarda kaçınılmaz hale gelir.
Front-end server HTTP isteklerini bir back-end server’a aktardığında, genellikle aynı back-end ağ bağlantısı üzerinden çok sayıda istek gönderir. Protokol basittir: HTTP istekleri ardı ardına teslim edilir ve alıcı sunucu, bir isteğin nerede biteceğini ve bir sonrakinin nerede başlayacağını belirlemek için HTTP istek headerlarını ayrıştırır.
Bu durumda, front-end ve back-end sistemlerin istekler arasındaki sınırlar üzerinde hemfikir olması kritik öneme sahiptir. Aksi takdirde saldırgan, front-end ve back-end sistemlerinin farklı algıladığı belirsiz bir istekte bulunabilir.
Saldırgan, front-end isteğinin bir kısmının back-end sunucusu tarafından bir sonraki isteğin başlangıcı olarak yorumlamasına neden olmasını sağlayabilir. Bir sonraki talebe belirlediği isteği etkin bir şekilde ekleyebilir ve sonraki istek süreçlerinin işleyişine müdahale edebilir.
Content-Length ve Transfer-Encoding isteğin nerede bittiğini belirtmek için kullanıldığı headerlardır. Bu zafiyetin oluşmasının nedeni ise bu headerların geçersiz kullanımından kaynaklıdır.
Content-Length istemciye ileti gövdesinin kaç bayt veriye sahip olduğunu söyler. Örneğin:
POST /search HTTP/1.1
Host: hedef-site.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 13
q=arananmetin
Burada istek içerisinde toplam 13 karakter uzunluğunda bir veri gönderdiğimizi görebilirsiniz.
İstek bodysinin chunked encoding kullandığını belirtmek için ise Transfer-Encoding header’ı kullanılır. Bu, request bodyde bir veya daha fazla veri parçası içerdiğini gösterir. Her parça, bayt cinsinden parça boyutuyla (onaltılık olarak ifade edilir), sonra bir satır sonu ve son olarak parça içeriğiyle başlar. İleti sıfır boyutlu bir parça ile sonlandırılır. Örnek olarak:
POST /search HTTP/1.1
Host: hedef-site.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
b
q=ornekveri
0
HTTP specificationu, HTTP mesajlarının uzunluğunu belirlemek için iki yöntem sağladığından, tek bir mesajın her iki yöntemi aynı anda kullanması bunların çakışmasına neden olabilir. HTTP belirtimi, hem Content-Length hem de Transfer-Encoding header varsa, Content-Length header dikkate alınmaması gerektiğini belirterek bu sorunu önlemeye çalışır. Yalnızca bir sunucu kullanılıyorken, bu belirsizliği önlemek için yeterli olabilir, ancak iki veya daha fazla sunucu birbirine bağlandığında, sorunlar iki nedenden dolayı gelişebilir:
- İsteklerdeki Transfer-Encoding header tüm sunucular tarafından desteklenmeyebilir.
- Transfer-Encoding başlığı bir şekilde obfuscate edilmiş ise, bazı sunucular onu işlemeyi reddedebilir.
Front-end ve back-end sunucular Transfer-Encoding başlığına yanıt olarak farklı davranırlarsa, ardışık istekler arasındaki sınırlar hakkında anlaşamayabilirler ve bu da potansiyel olarak request smuggling güvenlik açıklarına yol açabilir.
HTTP Request Smuggling Saldırısı Nasıl Gerçekleştirilir ?
Request Smuggling saldırıları, hem Content-Length hem de Transfer-Encoding başlıklarını tek bir HTTP isteğine eklemeyi ve bunları, front-end ve back-end sunucuların isteği farklı şekilde ele alması için değiştirmeyi hedefler. Bunun gerçekleştirilme şekli, iki sunucunun davranışı tarafından belirlenir:
- CL.TE: Content-Length başlığı front-end sunucu tarafından kullanılırken Transfer-Encoding başlığı back-end sunucusu tarafından kullanılır.
- TE.CL: Transfer-Encoding başlığı front-end sunucu tarafından kullanılırken Content-Length başlığı back-end sunucusu tarafından kullanılır.
- TE.TE: hem front-end hem de back-end sunucular Transfer-Encoding başlığını destekler, ancak sunuculardan birinin başlığı bir şekilde gizleyerek bunu görmezden gelmesi sağlanabilir.
CL.TE Vulnerabilities
Burada, front-end sunucu Content-Length header ve back-end sunucu Transfer-Encoding header kullanır. Aşağıdaki gibi basit bir Request Smuggling saldırısı gerçekleştirebiliriz:
POST / HTTP/1.1
Host: hedef-site.com
Content-Length: 13
Transfer-Encoding: chunked
0
Smuggled
Front-end sunucu, Content-Length başlığını inceler ve istek gövdesinin SMUGGLED ile biten 13 bayt uzunluğunda olduğu sonucuna varır. Bu istek back-end sunucusuna gönderilir.
Back-end sunucusu Transfer-Encoding başlığını incelediğinden, mesaj gövdesine chunked encoding uygulanıyormuş gibi davranır. Sıfır uzunlukta olduğu belirtilen ilk parçayı işler ve bu nedenle isteğin sonlandırıldığını düşünür. Aşağıdaki SMUGGLED, işlenmeden bırakılır ve back-end sunucusu, bunları bir sonraki isteğin başlangıcı olarak kabul eder.
TE.CL Vulnerabilities
Transfer-Encoding başlığı front-end sunucu tarafından kullanılırken Content-Length başlığı back-end sunucu tarafından kullanılır. Basit bir Request Smuggling saldırısı şu şekilde gerçekleştirilebilir:
POST / HTTP/1.1
Host: hedef-site.com
Content-Length: 3
Transfer-Encoding: chunked
8
SMUGGLED
0
Front-end sunucu, Transfer-Encoding başlığını işlediğinden, mesaj gövdesine chunked encoding uygulanıyormuş gibi davranır. SMUGGLED’den sonraki satırın başına ulaşana kadar 8 bayt uzunluğunda olduğu bildirilen ilk parça geçer. Sıfır uzunlukta olduğu iddia edilen ikinci parçayı işler ve bu nedenle isteğin sonlandırıldığını düşünür. Bu istek Back-end sunucusuna gönderilir.
Back-end sunucusu Content-Length başlığını inceler ve istek gövdesinin 8. satırı izleyen satırın başına kadar 3 bayt uzunluğunda olduğunu bulur. SMUGGLED’den sonraki baytlar işlenmeden bırakılır ve Back-end sunucu bunu bir sonraki isteğin başlangıcı olarak değerlendirir.
TE.TE Vulnerabilities.
Transfer-Encoding başlığı bu durumda hem Front-end hem de Back-end sunucular tarafından desteklenir, ancak başlıklardan birini obfustace ederek sunuculardan birini onu işlememeye ikna edilebilir.
Transfer-Encoding başlığını obfuscate etmek:
Transfer-Encoding: xchunkedTransfer-Encoding : chunkedTransfer-Encoding: chunkedTransfer-Encoding: xTransfer-Encoding:[tab]chunked[space]Transfer-Encoding: chunkedX: X[\n]Transfer-Encoding: chunkedTransfer-Encoding: chunked
TE.TE güvenlik açığını ortaya çıkarmak için, Transfer-Encoding üst bilgisinin, Front-end veya Back-end sunucularından yalnızca birinin onu işlemesi, diğer sunucunun ise yok sayması gibi bazı varyasyonlarını bulmak gerekir.
Saldırının geri kalanı, Front-end veya Back-end sunucusunun, Obfuscated Transfer-Encoding üstbilgisini ayrıştırmamaya ikna edilip edilemeyeceğine bağlı olarak, daha önce bahsedilen CL.TE veya TE.CL güvenlik açıklarıyla aynı şekli izleyecektir.
HTTP Request Smuggling Saldırıları Nasıl Önlenir?
Her bir Back-end isteğinin ayrı bir ağ bağlantısı üzerinden gönderilmesi için Back-end bağlantısının yeniden kullanımını devre dışı bırakın.
Back-end bağlantıları için HTTP/2’yi kullanın, çünkü istek sınırlarıyla ilgili belirsizliği ortadan kaldırır.
Front-end ve Back-end sunucular için aynı web sunucusu yazılımını kullanın, böylece istek sınırları üzerinde anlaşabilirler.
Yazar: Furkan Harani