hacktricks/pentesting-web/http-response-smuggling-desync.md

HTTP Yanıt Kaçırma / Desenkronizasyon

AWS hackleme konusunda sıfırdan kahraman olmaya kadar öğrenin htARTE (HackTricks AWS Kırmızı Takım Uzmanı)!

HackTricks'ı desteklemenin diğer yolları:

• Şirketinizi HackTricks'te reklamını görmek istiyorsanız veya HackTricks'i PDF olarak indirmek istiyorsanız [ABONELİK PLANLARI]'na göz atın (https://github.com/sponsors/carlospolop)!
• [Resmi PEASS & HackTricks ürünleri]'ni edinin (https://peass.creator-spring.com)
• [PEASS Ailesi]'ni keşfedin (https://opensea.io/collection/the-peass-family), özel [NFT'ler]'imiz koleksiyonumuz
• Katılın 💬 Discord grubuna veya telegram grubuna veya bizi Twitter 🐦 @carlospolopm** takip edin.**
• Hacking püf noktalarınızı paylaşarak PR'lar göndererek HackTricks ve HackTricks Cloud github depolarına katkıda bulunun.

Bu yazının tekniği şu videodan alınmıştır: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s

HTTP İstek Kuyruğu Desenkronizasyonu

Öncelikle, bu teknik bir HTTP İstek Kaçırma açığından yararlanır, bu yüzden bunun ne olduğunu bilmelisiniz:

Bu teknik ve yaygın bir HTTP İstek kaçırma arasındaki ana fark, kurbanın isteğine bir önek ekleyerek saldırmak yerine, kurbanın aldığı yanıtı sızdırmak veya değiştirmektir. Bunun için, HTTP İstek kaçırma saldırısını kötüye kullanmak için yarım bir istek göndermek yerine, arka arkaya 2 tam istek göndererek proxy yanıtlarının kuyruğunu desenkronize etmeyi hedefliyoruz.

Bu, yanıt kuyruğunu desenkronize edebileceğimiz anlamına gelir, böylece kurbanın meşru isteğinden gelen yanıt saldırgana gönderilir veya saldırganın kontrol ettiği içerik kurbanın yanıtına enjekte edilir.

HTTP Pipeline Desenkronizasyonu

HTTP/1.1, önceki istekleri beklemeye gerek olmadan farklı kaynaklar istemeyi sağlar. Bu nedenle, bir proxy varsa, arka uca gönderilen isteklerin ve oradan gelen yanıtların senkronize eşleşmesini sağlamak proxylerin görevidir.

Ancak, yanıtların kuyruğunu desenkronize etme sorunu vardır. Bir saldırgan bir HTTP Yanıt kaçırma saldırısı gönderirse ve ilk istek ve kaçırılan yanıt hemen yanıtlanırsa, kaçırılan yanıt, kurbanın yanıt kuyruğuna eklenmez, sadece bir hata olarak atılır.

Bu nedenle, kaçırılan isteğin sunucuda işlenmesi daha uzun sürmelidir. Bu nedenle, kaçırılan istek işlendiğinde, saldırganla iletişim kurulmuş olacak.

Bu belirli durumda bir kurban bir istek gönderdiğinde ve kaçırılan istek önce yanıtlandığında, kaçırılan yanıt kurbanın yanıtına gönderilecektir. Bu nedenle, saldırgan kurban tarafından "gerçekleştirilen" isteği kontrol edecek.

Dahası, saldırgan daha sonra bir istek yaparsa ve kurbanın meşru yanıtı, saldırganın isteğinden önce yanıtlanırsa, kurbanın yanıtı saldırgana gönderilecek, kurbanın yanıtını (örneğin Set-Cookie başlığını içerebilir) çalacak.

Birden Fazla İç İçe Enjeksiyon

Yaygın bir HTTP İstek Kaçırma saldırısından farklı bir ilginç fark, yaygın bir kaçırma saldırısında kurbanın isteğinin başlangıcını değiştirmenin hedef olduğu, HTTP Yanıt kaçırma saldırısında, tam istekler gönderdiğinizden, bir payload içine onlarca yanıt enjekte edebileceğinizdir, bu da onlarca kullanıcının enjekte edilen yanıtları alan ve desenkronize olan kullanıcılar olacağı anlamına gelir.

Meşru kullanıcılara daha kolayca onlarca saldırıyı dağıtabilme yeteneğinin yanı sıra, bu aynı zamanda sunucuda bir DoS oluşturmak için de kullanılabilir.

Saldırı Organizasyonu

Bu tekniği kötüye kullanmak için, sunucuya ilk kaçırılan mesajın işlenmesi için çok zaman gereklidir.

Bu zaman alıcı istek, kurbanın yanıtını çalmayı denemek için yeterlidir. Ancak daha karmaşık bir saldırı gerçekleştirmek istiyorsanız, bu saldırı için yaygın bir yapı olacaktır.

Öncelikle, HTTP İstek Kaçırma'yı kötüye kullanarak ilk istek, ardından zaman alan istek ve ardından kurbanlara gönderilecek yanıtların 1 veya daha fazla payload isteği.

HTTP Yanıt Kuyruğu Desenkronizasyonunu Kötüye Kullanma

Diğer kullanıcıların isteklerini yakalama

Bilinen HTTP İstek Kaçırma payloadları gibi, kurbanın isteğini çalabilirsiniz ancak önemli bir farkla: Bu durumda, yanıtta yansıtılacak içeriği göndermek yeterlidir, kalıcı depolama gerekli değildir.

Öncelikle, saldırgan, sonunda yansıtılan parametreli bir son POST isteği içeren bir payload gönderir ve büyük bir Content-Length içerir

Sonra, ilk istek (mavi) işlendikten sonra ve uyuyan istek işlenirken (sarı) kurbanın gönderdiği bir sonraki istek, yansıtılan parametrenin hemen ardından kuyruğa eklenecektir:

Sonra, kurban, uyuyan isteğin yanıtını alacak ve bu sırada saldırgan başka bir istek gönderirse, yansıtılan içerik isteğinin yanıtı ona gönderilecektir.

Yanıt Desenkronizasyonu

Bu noktaya kadar, HTTP İstek Kaçırma saldırılarını kötüye kullanarak bir istemcinin alacağı yanıtı kontrol etmeyi ve ardından kurban için amaçlanan yanıtı çalmayı öğrendik.

Ancak yanıtları daha da fazla desenkronize etmek mümkün.

HEAD isteği gibi ilginç istekler vardır ki, yanıtın gövdesinde hiçbir içerik olmaması gerektiği belirtilir ve (zorunlu olarak) GET isteği gibi Content-Length içermesi gerekir.

Bu nedenle, bir saldırgan HEAD isteği enjekte ederse, bu resimlerde olduğu gibi:

Sonra, mavi olan saldırgana yanıtlandıktan sonra, bir sonraki kurbanın isteği kuyruğa eklenecektir:

Sonra, kurban, HEAD isteğinden gelen yanıtı alacak, bu yanıt Content-Length içerecek ancak hiçbir içerik olmayacak. Bu nedenle, proxy, bu yanıtı kurbanın yanına göndermeyecek, ancak bazı içerik bekleyecek, aslında saldırgan tarafından da enjekte edilen sarı isteğin yanıtı olacak:

İçerik Karışıklığı

Önceki örneği takip ederek, yanıtı alacak kurbanın isteğinin gövdesini kontrol edebileceğinizi ve bir HEAD yanıtının genellikle başlıklarında Content-Type ve Content-Length'i içerdiğini bildiğinizde, XSS'e neden olmak için aşağıdaki gibi bir istek gönderebilirsiniz XSS'e karşı savunmasız olmayan sayfada:

Önbellek Zehirlenmesi

Önceki yorumlanmış yanıt desenkronizasyon İçerik Karışıklığı saldırısını istismar ederek, önbellek, kurban tarafından gerçekleştirilen isteğin yanıtını saklarsa ve bu yanıt bir XSS'e neden olan enjekte edilmiş bir yanıtsa, o zaman önbellek zehirlenir.

XSS yükü içeren kötü niyetli istek:

Önbelleğe yanıtı saklaması için başlığı içeren kurbanın kötü niyetli yanıtı:

{% hint style="warning" %} Bu durumda "kurban" saldırgan ise artık kötü niyetli yanıtla önbellek zehirlenmesi yapabilir çünkü kötü niyetli yanıtla önbelleğe alınacak URL'yi kontrol edebilir. {% endhint %}

Web Önbellek Aldatmacası

Bu saldırı öncekine benzer, ancak önbelleğe bir yük enjekte etmek yerine, saldırgan kurban bilgisini önbelleğe alacak:

Yanıt Bölünmesi

Bu saldırının amacı, yanıt desenkronizasyonunu tekrar istismar ederek proxy'nin %100 saldırgan tarafından oluşturulan bir yanıt göndermesini sağlamaktır.

Bunu başarmak için, saldırganın, yanıtın içinde bazı değerleri yansıtan web uygulamasının bir uç noktasını bulması ve HEAD yanıtının içeriğinin uzunluğunu bilmesi gerekir.

Şu şekilde bir saldırı gönderecektir:

İlk istek çözüldükten ve saldırgana geri gönderildikten sonra, kurbanın isteği kuyruğa eklenir:

Kurban, yanıt olarak HEAD yanıtını + yansıtılan verilerin bir kısmını içeren ikinci isteğin yanıtını alacaktır:

Ancak, yansıtılan verilerin HEAD yanıtının Content-Length'ine göre bir boyuta sahip olduğuna dikkat edin, bu da yanıt kuyruğunda geçerli bir HTTP yanıtı oluşturdu.

Bu nedenle, ikinci kurbanın sonraki isteği tamamen saldırgan tarafından oluşturulan bir yanıt alacaktır. Yanıt tamamen saldırgan tarafından oluşturulduğundan, aynı zamanda proxy'nin yanıtı önbelleğe almasını sağlayabilir.