HTTP istek kaçakçılığı, bir web sitesinin bir veya daha fazla kullanıcıdan alınan HTTP istek dizilerini işleme biçimine müdahale etme tekniğidir. Kaçakçılık güvenlik açıklarını talep etmek, genellikle doğası gereği kritiktir ve bir saldırganın güvenlik denetimlerini atlamasına, hassas verilere yetkisiz erişim elde etmesine ve diğer uygulama kullanıcılarını doğrudan tehlikeye atmasına olanak tanır.
- Not
- HTTP istek kaçakçılığı ilk olarak 2005’te belgelendi ve yakın zamanda PortSwigger’ın konuyla ilgili araştırması tarafından yeniden popüler hale getirildi.
HTTP istek kaçakçılığı saldırısında ne olur?
Günümüzün web uygulamaları, kullanıcılar ve nihai uygulama mantığı arasında sıklıkla HTTP sunucu zincirleri kullanır. Kullanıcılar istekleri bir ön uç sunucuya (bazen yük dengeleyici veya ters proxy olarak adlandırılır) gönderir ve bu sunucu istekleri bir veya daha fazla arka uç sunucuya iletir. Bu tür mimari, modern bulut tabanlı uygulamalarda giderek daha yaygın ve bazı durumlarda kaçınılmazdır.
Ön uç sunucu, HTTP isteklerini bir arka uç sunucuya ilettiğinde, genellikle aynı arka uç ağ bağlantısı üzerinden birkaç istek gönderir, çünkü bu çok daha verimli ve performanslıdır. Protokol çok basittir: HTTP istekleri birbiri ardına gönderilir ve alıcı sunucu, bir isteğin nerede bitip diğerinin nerede başladığını belirlemek için HTTP istek başlıklarını ayrıştırır:
Bu durumda, ön uç ve arka uç sistemlerin istekler arasındaki sınırlar konusunda anlaşmaları çok önemlidir. Aksi takdirde, bir saldırgan, ön uç ve arka uç sistemler tarafından farklı yorumlanan belirsiz bir istek gönderebilir:
Burada saldırgan, ön uç isteğinin bir kısmının arka uç sunucusu tarafından bir sonraki isteğin başlangıcı olarak yorumlanmasına neden olur. Bir sonraki talebe etkin bir şekilde eklenir ve bu nedenle, talep eden başvuru süreçlerinin işleyişine müdahale edebilir. Bu bir istek kaçakçılığı saldırısıdır ve yıkıcı sonuçları olabilir.
HTTP istek kaçakçılığı güvenlik açıkları nasıl ortaya çıkıyor?
HTTP istek kaçakçılığı güvenlik açıklarının çoğu, HTTP belirtiminin bir isteğin nerede bittiğini belirtmek için iki farklı yol sağlaması nedeniyle ortaya çıkar:
Content-Lenght başlığı ve Transfer-Encoding başlığı.
Content-Length başlığı basittir: mesaj gövdesinin uzunluğunu bayt olarak belirtir. Örneğin:
Transfer-Encoding başlığı, mesaj gövdesinin yığınlanmış kodlamayı kullandığını belirtmek için kullanılabilir. Bu, ileti gövdesinin bir veya daha fazla veri parçası içerdiği anlamına gelir. Her yığın, bayt cinsinden yığın boyutundan (onaltılık olarak ifade edilir), ardından yeni bir satırdan ve ardından yığın içeriğinden oluşur. İleti, sıfır boyutunda bir yığınla sonlandırılır. Örneğin:
- Not
- Birçok güvenlik testçisi, iki nedenden dolayı HTTP isteklerinde yığınlanmış kodlamanın kullanılabileceğinin farkında değildir:
- Burp Suite, mesajların görüntülenmesini ve düzenlenmesini kolaylaştırmak için kümelenmiş kodlamayı otomatik olarak açar.
- Tarayıcılar normalde isteklerde yığınlanmış kodlamayı kullanmaz ve normalde yalnızca sunucu yanıtlarında görülür.
HTTP belirtimi, HTTP mesajlarının uzunluğunu belirtmek için iki farklı yöntem sağladığından, tek bir mesajın her iki yöntemi aynı anda kullanması mümkündür, öyle ki bunlar birbiriyle çelişir. HTTP belirtimi, hem Content-Length hem de Transfer-Encoding üstbilgileri varsa, Content-Length üstbilgisinin yoksayılması gerektiğini belirterek bu sorunu önlemeye çalışır. Bu, yalnızca tek bir sunucu oyundayken belirsizliği önlemek için yeterli olabilir, ancak iki veya daha fazla sunucu birbirine zincirlendiğinde değil. Bu durumda, iki nedenden dolayı sorunlar ortaya çıkabilir:
- Bazı sunucular, isteklerde Transfer-Encoding başlığını desteklemez.
- Aktarım-Kodlama başlığını destekleyen bazı sunucular, başlık bir şekilde gizlenmişse, onu işlememeye yönlendirilebilir.
Ön uç ve arka uç sunucular (muhtemelen karışık) Transfer-Encoding başlığına göre farklı davranırlarsa, ardışık istekler arasındaki sınırlar konusunda anlaşamayabilirler ve bu da istek kaçakçılığı açıklarına yol açabilir.
HTTP istek kaçakçılığı saldırısı nasıl yapılır
İstek kaçakçılığı saldırıları, hem Content-Length üstbilgisini hem de Transfer-Encoding üstbilgisini tek bir HTTP isteğine yerleştirmeyi ve bunları, ön uç ve arka uç sunucularının isteği farklı şekilde işlemesi için değiştirmeyi içerir. Bunun tam olarak nasıl yapılacağı, iki sunucunun davranışına bağlıdır:
CL.TE: ön uç sunucu Content-Length başlığını kullanır ve arka uç sunucu Transfer-Encoding başlığını kullanır.
TE.CL: ön uç sunucu Transfer-Encoding başlığını kullanır ve arka uç sunucu Content-Length başlığını kullanır.
TE.TE: ön uç ve arka uç sunucuların her ikisi de Transfer-Encoding başlığını destekler, ancak sunuculardan biri başlığı bir şekilde karartarak onu işlememeye teşvik edilebilir.nt-Length başlığı göz ardı edilmelidir. Bu, yalnızca tek bir sunucu oyundayken belirsizliği önlemek için yeterli olabilir, ancak iki veya daha fazla sunucu birbirine zincirlendiğinde değil. Bu durumda, iki nedenden dolayı sorunlar ortaya çıkabilir:
CL.TE güvenlik açıkları
Burada ön uç sunucu Content-Length başlığını ve arka uç sunucu Transfer-Encoding başlığını kullanır. Basit bir HTTP request kaçakçılığı saldırısı gerçekleştirebiliriz:
KAÇAKÇI– SMUGGLED
Ön uç sunucu Content-Length başlığını işler ve istek gövdesinin SMUGGLED‘in sonuna kadar 13 bayt uzunluğunda olduğunu belirler. Bu istek, arka uç sunucusuna iletilir.
Arka uç sunucusu, Transfer-Encoding başlığını işler ve bu nedenle ileti gövdesine yığınlanmış kodlama kullanıyormuş gibi davranır. Sıfır uzunlukta olduğu belirtilen ilk yığını işler ve bu nedenle isteği sonlandırıyor olarak kabul edilir. Aşağıdaki baytlar, SMUGGLED, işlenmeden bırakılır ve arka uç sunucusu, bunları sıradaki bir sonraki isteğin başlangıcı olarak değerlendirir.
TE.CL güvenlik açıkları
Burada, ön uç sunucu Transfer-Encoding başlığını ve arka uç sunucusu Content-Length başlığını kullanır. Basit bir HTTP request kaçakçılığı saldırısı gerçekleştirebiliriz:
- Not
Bu isteği Burp Tekrarlayıcı kullanarak göndermek için öncelikle Tekrarlayıcı menüsüne gitmeniz ve “İçerik Uzunluğunu Güncelle” seçeneğinin işaretli olmadığından emin olmanız gerekir. - Son 0’dan sonra gelen \r\n\r\n dizisini eklemeniz gerekir.
Ön uç sunucu, Transfer-Encoding başlığını işler ve bu nedenle ileti gövdesine yığınlanmış kodlama kullanıyormuş gibi davranır. 8 bayt uzunluğunda olduğu belirtilen ilk parçayı SMUGGLED‘den sonraki satırın başına kadar işler. Sıfır uzunlukta olduğu belirtilen ikinci yığını işler ve bu nedenle isteği sonlandırıyor olarak kabul edilir. Bu istek, arka uç sunucusuna iletilir.
Arka uç sunucusu Content-Length başlığını işler ve istek gövdesinin 8‘den sonraki satırın başına kadar 3 bayt uzunluğunda olduğunu belirler. SMUGGLED ile başlayan aşağıdaki baytlar işlenmeden bırakılır ve arka uç sunucusu bunları sıradaki bir sonraki isteğin başlangıcı olarak değerlendirir.
TE.TE davranışı: TE başlığını gizleme
Burada, ön uç ve arka uç sunucuların her ikisi de Transfer-Encoding başlığını destekler, ancak sunuculardan biri, başlığı bir şekilde gizleyerek onu işlememeye teşvik edilebilir.
Transfer-Encoding başlığını karartmanın potansiyel olarak sonsuz yolları vardır. Örneğin:
Bu tekniklerin her biri, HTTP spesifikasyonundan ince bir şekilde ayrılmayı içerir. Bir protokol belirtimini uygulayan gerçek dünya kodu, nadiren ona mutlak bir kesinlikle yapışır ve farklı uygulamaların belirtimdeki farklı varyasyonları tolere etmesi yaygındır. Bir TE.TE güvenlik açığını ortaya çıkarmak için, Transfer-Encoding üstbilgisinin, ön uç veya arka uç sunucularından yalnızca birinin onu işlemesi, diğer sunucunun ise yok sayması gibi bazı varyasyonlarını bulmak gerekir.
Gizlenmiş Transfer-Encoding üstbilgisini işlememesi için ön uç mu yoksa arka uç sunucu mu olduğuna bağlı olarak, saldırının geri kalanı CL.TE veya TE.CL güvenlik açıklarıyla aynı biçimi alacaktır. zaten açıklanmıştır.
HTTP istek kaçakçılığı güvenlik açıkları nasıl önlenir
HTTP istek kaçakçılığı güvenlik açıkları, bir ön uç sunucunun aynı ağ bağlantısı üzerinden bir arka uç sunucuya birden çok isteği ilettiği durumlarda ortaya çıkar ve arka uç bağlantılar için kullanılan protokol, iki sunucunun arasındaki sınırlar konusunda anlaşmazlığa düşme riskini taşır. istekler. Ortaya çıkan HTTP istek kaçakçılığı güvenlik açıklarını önlemenin bazı genel yolları şunlardır:
- Her arka uç isteğinin ayrı bir ağ bağlantısı üzerinden gönderilmesi için arka uç bağlantılarının yeniden kullanımını devre dışı bırakın.
- Bu protokol, istekler arasındaki sınırlar hakkında belirsizliği önlediğinden, arka uç bağlantıları için HTTP/2 kullanın.
- İstekler arasındaki sınırlar konusunda anlaşmaları için ön uç ve arka uç sunucular için tamamen aynı web sunucusu yazılımını kullanın.
Bazı durumlarda, ön uç sunucunun belirsiz istekleri normalleştirmesini sağlayarak veya arka uç sunucunun belirsiz istekleri reddetmesini ve ağ bağlantısını kapatmasını sağlayarak güvenlik açıklarından ku. Bununla birlikte, bu yaklaşımlar potansiyel olarak yukarıda tanımlanan genel azaltmalardan daha fazla hataya açıktır.
