Herkese hayırlı forumlar öncellikle bugünkü konumuz
HTTP request smuggling yani bu konuda HTTP istek kaçakçılığı saldırıları'nı ele alıcağız ve yaygın istek kaçakçılığı güvenlik açıklarının nasıl ortaya çıkabileceğini açıklayacağız
hazırsanız başlayalım
Peki ya HTTP Request Smuggling Nedir?
HTTP request smuggling, Bir web sitenin kanaktan veya kaynaklardan alınan HTTP istekleri sırasında, işlemlerin müdahale etme tekniğidir. İstak kaçakçılığı zaafiyeti sayesinde saldırganlar WAF ve firewall hizmetlerini kolayca aşabilir ve dosyalara erişim sağlayabilirler.
HTTP Request Smuggling Saldırısında Neler Olur?
Günümüzde Kullanıcılar sıklıkla HTTP sunucu zincirlerini kullanır.
kullanıcılar istekleri bir uç sunucuya gönderir ve sunucu bu istekleri
bi arka sunucuya veya birden fazla sunucuya gönderir. Bu gibi bulut tabanlı uygulamalarda giderek daha yaygın ve bazı durumlarda kaçınılmazdır.
HTTP istekleri bi arka uç sunucuya iletildiginde, aynı arka uç bağlantısı üzerinden bir kac istek gönderir.
HTTP istekleri birbiri ardı ardına iletilir ve alıcı sunucu, bir isteğin nereden bitip, nereden başladığını tespit etmek için HTTP istek başlıklarını ayrıştırır.
Bu tarz durumlarda, ön arka uç sistemlerinin sınırlar konusundaki anlaşmalar çok önemlidir.
Aksi taktirde bir saldırgan ön uç ve arka uç sistemler tarafından
belirlenemeyen bir istek iletebilir
Saldırgan, ön uç isteğinin bir kısmının arka uç sunucusu tarafından bir sonraki isteğinin başlatışı olarak yorumlanmasına neden olur. Sonraki iletiye etkin bir şekilde eklenir ve bu nedenle, talep eden süreçlerin işleyişine müdahale edebilmektedir. Bu bir istek kaçakçılığı saldırısıdır.
HTTP Request Smuggling Güvenlik Açıkları Nasıl Ortaya Çıkıyor?
HTTP İstek Kaçakçılığı güvenlik açıklarının büyük bir kısmı, HTTP belirtiminin bir isteğin nerede bittiğini belirtmek için iki farklı yol sağlaması nedeniyle oluşur.
Başlık basittir, mesaj gövdesinin uzunluğunu bayt olarak belirtir. Bu, mesajın gövdesinin yığın kodlamasını kullandığını belirtmek için kullanılabilir. Bu, mesajın gövdesinin bir veya daha fazla veri parçası içerdiği anlamına gelir.
Bazı güvenlik yöneticileri, HTTP isteklerinde yığın şifrelemenin kullanılabileceğinin farkında değildir ve bu bir sorundur.
eğer bilmiyorsanız, HTTP, HTTP mesajlarının uzunluğunu belirlemek için iki tür farklı yöntem sunmaktadır. Şunu da belirtmek isterim ki, tek bir mesajın aynı anda her iki yöntemi de kullanması mümkündür, bu durumda birbiriyle çelişir. HTTP protokolü, hem Content-Length hem de Transfer-Encoding başlıkları mevcutsa, Content-Length başlığının kullanılmaması gerektiğini belirterek bu sorunu çözmeye çalışmaktadır. Bu formül, yalnızca bir etkin sunucu olduğunda belirsizliği önlemek için yeterli olabilir, ancak zincirlenmiş iki veya daha fazla sunucu olduğunda yeterli kalmayabilir.
Bu sebeple, ön uç ve arka uç sunucular, büyük ihtimal gizlenmiş bir Aktarım Kodlama türü başlığına göre farklı davranırlarsa, ardışık istekler arasındaki sınırlar konusunda anlaşamayabilirler. Bu, güvenlik açıklarına ve HTTP İstek Kaçakçılığı saldırısına neden olabilir.
HTTP Request Smuggling Saldırısı Nasıl Yapılır?
İstek kaçakçılığı 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:
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 söylenen ilk parçayı işler ve bu nedenle isteğin sonlandırıldığını düşünmektedir. 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 sunucusu tarafından kullanılır. Basit bir Request Smuggling saldırısı şu şekilde gerçekleştirilebilir:
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 desteklenmektedir, fakat başlıklarda birini obfustace ederek sunuculardan birini onu işlememeye ikna edebilmektedir.
TE.TE güvenlik açığı ortaya çıkarmak için, Transfer-Encoding üst bilgisini, Front-end veya Back-end sunucularından yalnızca bir tanesinin onu işlemesi, diğer sunucunun ise yok sayması benzeri 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.
( alıntıdır )
HTTP request smuggling yani bu konuda HTTP istek kaçakçılığı saldırıları'nı ele alıcağız ve yaygın istek kaçakçılığı güvenlik açıklarının nasıl ortaya çıkabileceğini açıklayacağız
hazırsanız başlayalım
Peki ya HTTP Request Smuggling Nedir?
HTTP request smuggling, Bir web sitenin kanaktan veya kaynaklardan alınan HTTP istekleri sırasında, işlemlerin müdahale etme tekniğidir. İstak kaçakçılığı zaafiyeti sayesinde saldırganlar WAF ve firewall hizmetlerini kolayca aşabilir ve dosyalara erişim sağlayabilirler.
HTTP Request Smuggling Saldırısında Neler Olur?
Günümüzde Kullanıcılar sıklıkla HTTP sunucu zincirlerini kullanır.
kullanıcılar istekleri bir uç sunucuya gönderir ve sunucu bu istekleri
bi arka sunucuya veya birden fazla sunucuya gönderir. Bu gibi bulut tabanlı uygulamalarda giderek daha yaygın ve bazı durumlarda kaçınılmazdır.
HTTP istekleri bi arka uç sunucuya iletildiginde, aynı arka uç bağlantısı üzerinden bir kac istek gönderir.
HTTP istekleri birbiri ardı ardına iletilir ve alıcı sunucu, bir isteğin nereden bitip, nereden başladığını tespit etmek için HTTP istek başlıklarını ayrıştırır.
Bu tarz durumlarda, ön arka uç sistemlerinin sınırlar konusundaki anlaşmalar çok önemlidir.
Aksi taktirde bir saldırgan ön uç ve arka uç sistemler tarafından
belirlenemeyen bir istek iletebilir
Saldırgan, ön uç isteğinin bir kısmının arka uç sunucusu tarafından bir sonraki isteğinin başlatışı olarak yorumlanmasına neden olur. Sonraki iletiye etkin bir şekilde eklenir ve bu nedenle, talep eden süreçlerin işleyişine müdahale edebilmektedir. Bu bir istek kaçakçılığı saldırısıdır.
HTTP Request Smuggling Güvenlik Açıkları Nasıl Ortaya Çıkıyor?
HTTP İstek Kaçakçılığı güvenlik açıklarının büyük bir kısmı, HTTP belirtiminin bir isteğin nerede bittiğini belirtmek için iki farklı yol sağlaması nedeniyle oluşur.
Başlık basittir, mesaj gövdesinin uzunluğunu bayt olarak belirtir. Bu, mesajın gövdesinin yığın kodlamasını kullandığını belirtmek için kullanılabilir. Bu, mesajın gövdesinin bir veya daha fazla veri parçası içerdiği anlamına gelir.
Bazı güvenlik yöneticileri, HTTP isteklerinde yığın şifrelemenin kullanılabileceğinin farkında değildir ve bu bir sorundur.
eğer bilmiyorsanız, HTTP, HTTP mesajlarının uzunluğunu belirlemek için iki tür farklı yöntem sunmaktadır. Şunu da belirtmek isterim ki, tek bir mesajın aynı anda her iki yöntemi de kullanması mümkündür, bu durumda birbiriyle çelişir. HTTP protokolü, hem Content-Length hem de Transfer-Encoding başlıkları mevcutsa, Content-Length başlığının kullanılmaması gerektiğini belirterek bu sorunu çözmeye çalışmaktadır. Bu formül, yalnızca bir etkin sunucu olduğunda belirsizliği önlemek için yeterli olabilir, ancak zincirlenmiş iki veya daha fazla sunucu olduğunda yeterli kalmayabilir.
Bu sebeple, ön uç ve arka uç sunucular, büyük ihtimal gizlenmiş bir Aktarım Kodlama türü başlığına göre farklı davranırlarsa, ardışık istekler arasındaki sınırlar konusunda anlaşamayabilirler. Bu, güvenlik açıklarına ve HTTP İstek Kaçakçılığı saldırısına neden olabilir.
HTTP Request Smuggling Saldırısı Nasıl Yapılır?
İstek kaçakçılığı 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:
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 söylenen ilk parçayı işler ve bu nedenle isteğin sonlandırıldığını düşünmektedir. 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 sunucusu tarafından kullanılır. Basit bir Request Smuggling saldırısı şu şekilde gerçekleştirilebilir:
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 desteklenmektedir, fakat başlıklarda birini obfustace ederek sunuculardan birini onu işlememeye ikna edebilmektedir.
TE.TE güvenlik açığı ortaya çıkarmak için, Transfer-Encoding üst bilgisini, Front-end veya Back-end sunucularından yalnızca bir tanesinin onu işlemesi, diğer sunucunun ise yok sayması benzeri 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.
( alıntıdır )
Son düzenleme:
