<summary><strong>AWS hackleme konusunu sıfırdan kahramana kadar öğrenin</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Kırmızı Takım Uzmanı)</strong></a><strong> ile!</strong></summary>
* **Şirketinizi HackTricks'te reklam 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)!
* [**PEASS Ailesi'ni**](https://opensea.io/collection/the-peass-family) keşfedin, özel [**NFT'lerimiz**](https://opensea.io/collection/the-peass-family) koleksiyonumuz
* **💬 [**Discord grubuna**](https://discord.gg/hRep4RUj7f) katılın veya [**telegram grubuna**](https://t.me/peass) katılın veya bizi **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)** takip edin.**
Bu tekniğin bir standart HTTP İstek kaçırma saldırısından farkı, **kurbanın isteğine bir önek ekleyerek saldırmak yerine**, **kurbanın aldığı yanıtı sızdırmak veya değiştirmek** olacaktır. Bu, HTTP İstek kaçırma saldırısını kötüye kullanmak için 1 istek ve yarım göndermek yerine, **proxy yanıtlarını desenkronize etmek için 2 tam istek göndermek** anlamına gelir.
Bu, **yanıt kuyruğunu desenkronize edebileceğimiz için**, **kurbanın meşru isteğinden gelen yanıtın saldırgan tarafından gönderilmesine** veya **kurbanın yanıtına saldırgan tarafından kontrol edilen içerik enjekte edilmesine** olanak tanır.
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** proxy'nin 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ıtlar hemen yanıtlanırsa**, kaçırılan yanıt, kurbanın yanıt kuyruğuna **eklenmeyecek, sadece bir hata olarak atılacaktır**.
Bu nedenle, **kaçırılan isteğin işlenmesi için daha fazla zaman alması gerekmektedir**. Bu nedenle, kaçırılan istek işlendiğinde, saldırganla iletişim kurulmuş olacaktır.
Eğer bu belirli durumda bir **kurban bir istek göndermişse** ve **kaçırılan istek önce yanıtlanırsa**, **kaçırılan yanıt kurbanın alacağı** şekilde gönderilecektir. Bu nedenle, saldırgan, kurban tarafından "gerçekleştirilen" isteği **kontrol edecektir**.
Ortak **HTTP İstek Kaçırma** saldırısından farklı olarak, bir ortak kaçırma saldırısında, **hedefin isteğinin başlangıcını değiştirmenin** amaçlandığıdır. **HTTP Yanıt kaçırma saldırısında**, tam istekler gönderdiğinizden, bir yükte onlarca yanıtı**enjekte edebilirsiniz** ve bu, **enjekte edilen yanıtları alan onlarca kullanıcıyı desenkronize edecektir**.
Meşru kullanıcılara daha kolay bir şekilde onlarca saldırıyı**dağıtabilme** yeteneğinin yanı sıra, bu, sunucuda bir **Hizmet Dışı Bırakma**'ya neden olmak için de kullanılabilir.
Bu **zaman alıcı istek, kurbanın yanıtını çalmayı denemek** istiyorsanız 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** gönderileceği **1 veya daha fazla yük isteği**.
Bilinen HTTP İstek Kaçırma payloadları gibi, bu durumda **kurbanın isteğini çalabilirsiniz** ancak önemli bir farkla: Bu durumda, **yanıtta yansıtılacak içeriğe ihtiyacınız vardır**, **kalıcı depolama gerekmez**.
Sonra, **ilk istek** (mavi) **işlendikten sonra** ve **uyuyan** istek işlenirken (sarı) **kurban tarafından gelen bir sonraki istek**, **yansıtılan parametrenin hemen ardından kuyruğa eklenecektir**:
Sonra, **kurban**, **uyuyan** isteğin yanıtını alacak ve bu arada **saldırgan başka bir istek gönderirse**, **yansıtılan içerik isteğinden gelen yanıt ona gönderilecektir**.
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.
**HEAD** isteği gibi ilginç istekler vardır ki, bu isteklerin **yanıt gövdesinde hiçbir içerik olmaması gerektiği** belirtilmiştir ve (zorunlu olarak) **GET isteği gibi Content-Length** içermesi gerekmektedir.
Sonra, **kurban**, **HEAD** isteğinden gelen yanıtı alacak, bu yanıt **hiçbir içerik içermesine rağmen Content-Length içerecektir**. Bu nedenle, proxy, bu yanıtı kurbanın yanıtına göndermeyecek, ancak bir **içerik bekleyecek**, bu içerik aslında **saldırgan tarafından da enjekte edilen sarı isteğin yanıtı olacaktır**:
Önceki örneği takip ederek, **yanıtı alacak kurbanın vücudunu kontrol edebileceğinizi** ve bir **HEAD yanıtının genellikle başlıklarında****Content-Type ve Content-Length**'in bulunduğunu bilerek, XSS'ye neden olmak için aşağıdaki gibi bir istek gönderebilirsiniz:
Önceki yorumlanmış yanıt desenkronizasyonu İçerik Karışıklığı saldırısını istismar ederek, **önbelleğin, kurban tarafından gerçekleştirilen isteğin yanıtını sakladığını ve bu yanıtın XSS'e neden olan bir enjekte edilmiş yanıt olduğunu** varsayarsak, önbellek zehirlenir.
Bu durumda **"kurban" saldırgan ise** artık **rastgele URL'lerde önbellek zehirlenmesi yapabilir** çünkü kötü niyetli yanıtla **önbelleğe alınacak URL'yi kontrol edebilir**.
Bu saldırının **amacı**, **yanıt desenkronizasyonunu** tekrar kötüye kullanarak **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 bir web uygulamasının bir uç noktasını bulması** ve **HEAD yanıtının içeriğinin uzunluğunu bilmesi** gerekir.
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 sırasında 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 alacak**. Yanıt tamamen saldırgan tarafından oluşturulduğundan, aynı zamanda **proxy'nin yanıtı önbelleğe almasını sağlayabilir**.
