Sorunun özü, ön uçların ve arka uçların genellikle HTTP protokolü için farklı düzeylerde destek sağlaması, ancak aynı zamanda farklı kullanıcılardan gelen istekleri ortak bir kanalda kapsüllemesidir. Ön uç alma isteklerini ve arka uç işleme isteklerini birbirine bağlamak için, kullanıcı isteklerinin iletildiği, zincir boyunca birbiri ardına iletildiği ve HTTP protokolü aracılığıyla ayrıldığı uzun ömürlü bir TCP bağlantısı kurulur. İstekleri ayırmak için "Content-Length" (istekteki verilerin toplam boyutunu belirler) ve "
Sorun, ön ucun yalnızca "İçerik Uzunluğu"nu desteklemesi ancak "Aktarım Kodlaması: yığınlanmış" ifadesini göz ardı etmesi (örneğin, Akamai CDN bunu yaptı) veya bunun tersi durumunda ortaya çıkar. Transfer-Encoding: chunked her iki tarafta da destekleniyorsa, HTTP başlık ayrıştırıcılarının uygulama özellikleri bir saldırı için kullanılabilir (örneğin, ön uç "Transfer-Encoding: xchunked", "Transfer-Encoding: chunked" gibi satırları yok saydığında) ”, “Transfer-Kodlama :[tab]parçalanmış", "X: X[\n]Transfer-Kodlama: parçalanmış", "Transfer-Kodlama[\n]: parçalanmış" veya "Transfer-Kodlama : parçalanmış" ve arka uç bunları başarıyla işler).
Bu durumda, saldırgan hem "Content-Length" hem de "Transfer-Encoding: chunked" başlıklarını içeren bir istek gönderebilir, ancak "Content-Length" içindeki boyut parçalanmış zincirin boyutuna karşılık gelmez. gerçek değerinden küçüktür. Ön uç, isteği "İçerik Uzunluğuna" göre işler ve iletirse ve arka uç, "Aktarım Kodlaması: yığınlanmış" temeline göre bloğun tamamlanmasını beklerse, o zaman "Aktarım Kodlaması: yığınlanmış" temeline dayalı verinin sonu, saldırgan daha önceden belirlenecek ve isteğin kalan kuyruğu bir sonraki isteğin başında olacaktır, yani. Saldırgan, başka birinin daha sonra ilettiği isteğin başına isteğe bağlı veriler ekleyebilecektir.
Kullandığınız ön uç-arka uç kombinasyonundaki sorunu belirlemek için ön uç üzerinden şu şekilde bir istek gönderebilirsiniz:
POST /HTTP/1.1 hakkında
Ev sahibi: örnek.com
Aktarım Kodlaması: parçalanmış
Content-Length: 4
1
Z
Q
Sorun, arka ucun isteği hemen işleme koymaması ve yığınlanmış verilerin son sıfır sınırlayıcı bloğunun gelmesini beklemesi durumunda ortaya çıkar. Daha eksiksiz bir kontrol için
Gerçek bir saldırının gerçekleştirilmesi, saldırıya uğrayan sitenin yeteneklerine bağlıdır; örneğin, Trello web uygulamasına saldırırken, isteğin başlangıcını değiştirebilirsiniz ("PUT /1/members/1234... x=x&csrf gibi verileri değiştirin) =1234&username=testzzz&bio=cake”) ve üçüncü taraf bir kullanıcının orijinal isteğini ve içinde belirtilen kimlik doğrulama Çerezini içeren bir mesaj gönderin. Saas-app.com'a yapılan bir saldırı için, yanıttaki JavaScript kodunu istek parametrelerinden birinde değiştirerek değiştirmenin mümkün olduğu ortaya çıktı. Redhat.com'a yapılan saldırıda, saldırganın web sitesine yönlendirmek için dahili bir işleyici kullanıldı ("POST /search?dest=../assets/idx?redir=// biçiminde bir istek)[e-posta korumalı]/ HTTP/1.1").
İçerik dağıtım ağlarına yönelik yöntemin kullanılması, istenen sitenin "Ana Bilgisayar:" başlığını değiştirerek kolayca değiştirilmesini mümkün kıldı. Saldırı aynı zamanda içerik önbellekleme sistemlerinin içeriğini zehirlemek ve önbelleğe alınmış gizli verileri çıkarmak için de kullanılabilir. Yöntemin zirvesi, PayPal'a yapılan bir saldırının organizasyonuydu; bu saldırı, kimlik doğrulama sırasında kullanıcılar tarafından gönderilen şifrelerin ele geçirilmesini mümkün kıldı (iframe isteği, PayPal.com/us/gifts sayfası bağlamında JavaScript'i çalıştıracak şekilde değiştirildi). CSP'nin (İçerik Güvenliği Politikası) uygulanmadığı).
İlginçtir ki 2005 yılında
Kaynak: opennet.ru