HTTP Request Smuggling / HTTP Desync Attack
Last updated
Last updated
AWS Hacking öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE) GCP Hacking öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Bu zafiyet, ön uç proxyleri ile arka uç sunucu arasında bir senkronizasyon bozukluğu olduğunda meydana gelir ve bu, bir saldırganın HTTP isteği göndermesine olanak tanır; bu istek ön uç proxyleri tarafından tek bir istek olarak ve arka uç sunucu tarafından 2 istek olarak yorumlanır. Bu, bir kullanıcının arka uç sunucusuna gelen bir sonraki isteği değiştirmesine olanak tanır.
Eğer bir mesaj hem Transfer-Encoding başlık alanı hem de Content-Length başlık alanı ile alınırsa, ikincisi GÖZARDI EDİLMELİDİR.
Content-Length
Content-Length varlık başlığı, alıcıya gönderilen varlık gövdesinin boyutunu, bayt cinsinden belirtir.
Transfer-Encoding: chunked
Transfer-Encoding başlığı, yük gövdesinin kullanıcıya güvenli bir şekilde aktarılması için kullanılan kodlama biçimini belirtir. Chunked, büyük verilerin bir dizi parça halinde gönderildiği anlamına gelir.
Ön Uç (bir yük dengeleme / Ters Proxy) content-length veya transfer-encoding başlığını işler ve Arka Uç sunucu diğerini işler, bu da iki sistem arasında bir senkronizasyon bozukluğu yaratır. Bu, bir saldırganın ters proxyye bir istek göndermesine olanak tanır ve bu istek arka uç sunucu tarafından 2 farklı istek olarak yorumlanır. Bu tekniğin tehlikesi, arka uç sunucunun 2. isteği enjekte edilmiş gibi yorumlaması ve o istemcinin gerçek isteğinin enjekte edilmiş isteğin bir parçası olmasıdır.
HTTP'de yeni bir satır karakteri 2 bayttan oluşur:
Content-Length: Bu başlık, isteğin gövdesinin bayt sayısını belirtmek için bir ondalık sayı kullanır. Gövdenin son karakterde bitmesi beklenir, isteğin sonunda yeni bir satıra ihtiyaç yoktur.
Transfer-Encoding: Bu başlık, gövde içinde bir onaltılık sayı kullanarak bir sonraki parçanın bayt sayısını belirtir. Parça, yeni bir satır ile bitmelidir ancak bu yeni satır uzunluk göstergesi tarafından sayılmaz. Bu aktarım yöntemi, 0 boyutunda bir parça ile 2 yeni satır ile bitmelidir: 0
Connection: Deneyimlerime dayanarak, istek Smuggling'in ilk isteğinde Connection: keep-alive kullanılması önerilir.
Burp Suite ile bunu sömürmeye çalışırken Update Content-Length ve Normalize HTTP/1 line endings seçeneklerini devre dışı bırakın çünkü bazı araçlar yeni satırları, taşıma dönüşlerini ve hatalı içerik uzunluklarını kötüye kullanır.
HTTP istek smuggling saldırıları, Content-Length (CL) ve Transfer-Encoding (TE) başlıklarının ön uç ve arka uç sunucular tarafından nasıl yorumlandığındaki tutarsızlıklardan yararlanan belirsiz istekler göndererek oluşturulur. Bu saldırılar, esas olarak CL.TE, TE.CL ve TE.TE olarak farklı biçimlerde ortaya çıkabilir. Her tür, ön uç ve arka uç sunucuların bu başlıkları nasıl önceliklendirdiğinin benzersiz bir kombinasyonunu temsil eder. Zafiyetler, sunucuların aynı isteği farklı şekillerde işlemesinden kaynaklanır ve beklenmedik ve potansiyel olarak kötü niyetli sonuçlara yol açar.
Önceki tabloya TE.0 tekniğini eklemelisiniz, CL.0 tekniği gibi ancak Transfer Encoding kullanarak.
Ön Uç (CL): İsteği Content-Length başlığına göre işler.
Arka Uç (TE): İsteği Transfer-Encoding başlığına göre işler.
Saldırı Senaryosu:
Saldırgan, Content-Length başlığının değeri gerçek içerik uzunluğuyla eşleşmeyen bir istek gönderir.
Ön uç sunucu, Content-Length değerine dayanarak tüm isteği arka uca iletir.
Arka uç sunucu, Transfer-Encoding: chunked başlığı nedeniyle isteği parça parça olarak işler ve kalan veriyi ayrı, sonraki bir istek olarak yorumlar.
Örnek:
Ön Uç (TE): İsteği Transfer-Encoding başlığına göre işler.
Arka Uç (CL): İsteği Content-Length başlığına göre işler.
Saldırı Senaryosu:
Saldırgan, parça boyutunun (7b) ve gerçek içerik uzunluğunun (Content-Length: 4) uyum sağlamadığı bir parça isteği gönderir.
Ön uç sunucu, Transfer-Encoding başlığını dikkate alarak tüm isteği arka uca iletir.
Arka uç sunucu, Content-Length başlığını dikkate alarak isteğin yalnızca ilk kısmını (7b bayt) işler ve geri kalanını istenmeyen bir sonraki isteğin parçası olarak bırakır.
Örnek:
Sunucular: Her ikisi de Transfer-Encoding destekliyor, ancak biri obfuscation yoluyla bunu göz ardı etmeye ikna edilebilir.
Saldırı Senaryosu:
Saldırgan, obfuscate edilmiş Transfer-Encoding başlıkları ile bir istek gönderir.
Hangi sunucunun (ön uç veya arka uç) obfuscation'ı tanımadığına bağlı olarak, bir CL.TE veya TE.CL zafiyeti sömürülebilir.
İsteğin işlenmemiş kısmı, sunuculardan biri tarafından görüldüğünde, sonraki bir isteğin parçası haline gelir ve smuggling'e yol açar.
Örnek:
Her iki sunucu da isteği yalnızca Content-Length başlığına dayanarak işler.
Bu senaryo genellikle smuggling'e yol açmaz, çünkü her iki sunucu da isteğin uzunluğunu yorumlama konusunda uyumludur.
Örnek:
Content-Length başlığının mevcut olduğu ve sıfırdan farklı bir değere sahip olduğu senaryoları ifade eder; bu, isteğin gövdesinin içerik taşıdığını gösterir. Arka uç, Content-Length başlığını göz ardı eder (bu 0 olarak kabul edilir), ancak ön uç bunu işler.
Smuggling saldırılarını anlamak ve oluşturmak için kritik öneme sahiptir, çünkü sunucuların bir isteğin sonunu belirlemesini etkiler.
Örnek:
Öncekine benzer ancak TE kullanarak.
Teknik burada rapor edilmiştir
Örnek:
Bu teknik, ilk HTTP verilerini okurken bir web sunucusunu kırmanın mümkün olduğu senaryolarda da faydalıdır, ancak bağlantıyı kapatmadan. Bu şekilde, HTTP isteğinin gövdesi bir sonraki HTTP isteği olarak kabul edilecektir.
Örneğin, bu yazıda açıklandığı gibi, Werkzeug'ta bazı Unicode karakterleri göndermek mümkündü ve bu sunucunun kırılmasına neden oluyordu. Ancak, HTTP bağlantısı Connection: keep-alive başlığı ile oluşturulmuşsa, isteğin gövdesi okunmayacak ve bağlantı hala açık kalacak, bu nedenle isteğin gövdesi bir sonraki HTTP isteği olarak işlenecektir.
Hop-by-hop başlıklarını kötüye kullanarak, proxy'ye Content-Length veya Transfer-Encoding başlığını silmesini belirtebilir ve böylece HTTP request smuggling'in kötüye kullanılmasını sağlayabilirsiniz.
For daha fazla bilgi için hop-by-hop başlıkları ziyaret edin:
hop-by-hop headersHTTP isteği kaçırma açıklarını tanımlamak genellikle zamanlama teknikleri kullanılarak gerçekleştirilebilir; bu teknikler, sunucunun manipüle edilmiş isteklere yanıt vermesi için ne kadar süre geçtiğini gözlemlemeye dayanır. Bu teknikler, özellikle CL.TE ve TE.CL açıklarını tespit etmek için faydalıdır. Bu yöntemlerin yanı sıra, bu tür açıkları bulmak için kullanılabilecek diğer stratejiler ve araçlar da vardır:
Yöntem:
Uygulama açık ise, arka uç sunucunun ek veri beklemesine neden olacak bir istek gönderin.
Örnek:
Gözlem:
Ön uç sunucu, isteği Content-Length temelinde işler ve mesajı erken keser.
Arka uç sunucu, parçalı bir mesaj bekleyerek, asla gelmeyecek olan bir sonraki parçayı bekler ve bu da bir gecikmeye neden olur.
Göstergeler:
Yanıt süre aşımı veya uzun gecikmeler.
Arka uç sunucudan 400 Bad Request hatası almak, bazen ayrıntılı sunucu bilgileri ile birlikte.
Yöntem:
Uygulama açık ise, arka uç sunucunun ek veri beklemesine neden olacak bir istek gönderin.
Örnek:
Gözlem:
Ön uç sunucu, isteği Transfer-Encoding temelinde işler ve tüm mesajı iletir.
Arka uç sunucu, Content-Length temelinde bir mesaj bekleyerek, asla gelmeyecek olan ek veriyi bekler ve bu da bir gecikmeye neden olur.
Farklı Yanıt Analizi:
Bir isteğin hafifçe farklı versiyonlarını gönderin ve sunucu yanıtlarının beklenmedik bir şekilde farklı olup olmadığını gözlemleyin; bu, bir ayrıştırma tutarsızlığını gösterir.
Otomatik Araçlar Kullanma:
Burp Suite'in 'HTTP Request Smuggler' eklentisi gibi araçlar, çeşitli belirsiz istekler göndererek ve yanıtları analiz ederek bu açıkları otomatik olarak test edebilir.
Content-Length Varyans Testleri:
Gerçek içerik uzunluğu ile uyumlu olmayan değişken Content-Length değerleri ile istekler gönderin ve sunucunun bu tür uyumsuzlukları nasıl ele aldığını gözlemleyin.
Transfer-Encoding Varyans Testleri:
Obfuscate edilmiş veya hatalı Transfer-Encoding başlıkları ile istekler gönderin ve ön uç ve arka uç sunucularının bu tür manipülasyonlara nasıl farklı yanıt verdiğini izleyin.
Zamanlama tekniklerinin etkinliğini doğruladıktan sonra, istemci isteklerinin manipüle edilip edilemeyeceğini doğrulamak önemlidir. Basit bir yöntem, isteklerinizi zehirlemeyi denemektir; örneğin, / isteği göndererek 404 yanıtı almak. Daha önce Temel Örnekler bölümünde tartışılan CL.TE ve TE.CL örnekleri, istemcinin farklı bir kaynağa erişmeye çalışmasına rağmen, istemci isteğini zehirleyerek 404 yanıtı elde etmenin nasıl yapılacağını göstermektedir.
Anahtar Dikkat Noktaları
Diğer isteklerle müdahale ederek istek kaçırma açıklarını test ederken, aklınızda bulundurmanız gerekenler:
Ayrı Ağ Bağlantıları: "Saldırı" ve "normal" istekler ayrı ağ bağlantıları üzerinden gönderilmelidir. Her iki istek için aynı bağlantıyı kullanmak, açığın varlığını doğrulamaz.
Tutarlı URL ve Parametreler: Her iki istek için de aynı URL'leri ve parametre adlarını kullanmaya çalışın. Modern uygulamalar genellikle istekleri URL ve parametrelere göre belirli arka uç sunucularına yönlendirir. Bunların eşleşmesi, her iki isteğin de aynı sunucu tarafından işlenme olasılığını artırır; bu, başarılı bir saldırı için bir ön koşuldur.
Zamanlama ve Yarış Koşulları: "Normal" istek, "saldırı" isteğinden gelen müdahaleyi tespit etmek için diğer eşzamanlı uygulama istekleriyle rekabet eder. Bu nedenle, "normal" isteği "saldırı" isteğinden hemen sonra gönderin. Yoğun uygulamalar, kesin bir açık doğrulaması için birden fazla deneme gerektirebilir.
Yük Dengeleme Zorlukları: Yük dengeleyici olarak hareket eden ön uç sunucular, istekleri çeşitli arka uç sistemlerine dağıtabilir. Eğer "saldırı" ve "normal" istekler farklı sistemlerde sonuçlanırsa, saldırı başarılı olmayacaktır. Bu yük dengeleme durumu, bir açığı doğrulamak için birkaç deneme gerektirebilir.
İstenmeyen Kullanıcı Etkisi: Eğer saldırınız başka bir kullanıcının isteğini (gönderdiğiniz "normal" isteği değil) istemeden etkiliyorsa, bu, saldırınızın başka bir uygulama kullanıcısını etkilediğini gösterir. Sürekli test, diğer kullanıcıları rahatsız edebilir; bu nedenle dikkatli bir yaklaşım gereklidir.
Bazen, ön uç proxy'leri güvenlik önlemleri uygular ve gelen istekleri inceler. Ancak, bu önlemler HTTP İsteği Kaçırma kullanılarak aşılabilir ve yetkisiz erişim sağlanabilir. Örneğin, /admin erişimi dışarıdan yasaklanmış olabilir ve ön uç proxy bu tür girişimleri aktif olarak engelleyebilir. Ancak, bu proxy, kaçırılmış bir HTTP isteği içindeki gömülü istekleri incelemeyi ihmal edebilir ve bu da bu kısıtlamaları aşmak için bir açık bırakır.
Aşağıdaki örnekler, HTTP İsteği Kaçırma'nın ön uç güvenlik kontrollerini aşmak için nasıl kullanılabileceğini, özellikle ön uç proxy tarafından genellikle korunan /admin yolunu hedef alarak göstermektedir:
CL.TE Örneği
CL.TE saldırısında, başlangıç isteği için Content-Length başlığı kullanılırken, sonraki gömülü istek Transfer-Encoding: chunked başlığını kullanır. Ön uç proxy, başlangıç POST isteğini işler ancak gömülü GET /admin isteğini denetlemeyi başaramaz, bu da /admin yoluna yetkisiz erişime izin verir.
TE.CL Örneği
Tersine olarak, TE.CL saldırısında, başlangıçtaki POST isteği Transfer-Encoding: chunked kullanır ve sonraki gömülü istek Content-Length başlığına göre işlenir. CL.TE saldırısına benzer şekilde, ön uç proxy, kaçırılan GET /admin isteğini göz ardı eder ve istemeden de olsa kısıtlı /admin yoluna erişim sağlar.
Uygulamalar genellikle gelen istekleri arka uç sunucusuna iletmeden önce değiştirmek için bir ön uç sunucusu kullanır. Tipik bir değişiklik, arka uca istemcinin IP'sini iletmek için X-Forwarded-For: <IP of the client> gibi başlıklar eklemeyi içerir. Bu değişiklikleri anlamak kritik olabilir, çünkü korumaları aşmanın veya gizli bilgileri veya uç noktaları açığa çıkarmanın yollarını ortaya çıkarabilir.
Bir proxy'nin isteği nasıl değiştirdiğini araştırmak için, arka uçta yanıt olarak yankılanan bir POST parametresi bulun. Ardından, bu parametreyi en sona koyarak aşağıdaki gibi bir istek oluşturun:
Bu yapıda, sonraki istek bileşenleri search= ifadesinden sonra eklenir; bu, yanıtta yansıtılan parametredir. Bu yansıma, sonraki isteğin başlıklarını açığa çıkaracaktır.
İç içe isteğin Content-Length başlığının gerçek içerik uzunluğu ile hizalanması önemlidir. Küçük bir değerle başlayıp yavaşça artırmak tavsiye edilir; çünkü çok düşük bir değer yansıtılan veriyi keserken, çok yüksek bir değer isteğin hata vermesine neden olabilir.
Bu teknik, bir TE.CL açığı bağlamında da uygulanabilir, ancak istek search=\r\n0 ile sonlanmalıdır. Yeni satır karakterlerinden bağımsız olarak, değerler arama parametresine eklenecektir.
Bu yöntem esasen ön uç proxy tarafından yapılan istek değişikliklerini anlamak için kullanılır ve temelde kendi kendine yönlendirilmiş bir araştırma yapar.
Bir POST işlemi sırasında bir parametrenin değeri olarak belirli bir isteği ekleyerek bir sonraki kullanıcının isteklerini yakalamak mümkündür. Bunu şu şekilde gerçekleştirebilirsiniz:
Aşağıdaki isteği bir parametrenin değeri olarak ekleyerek, sonraki istemcinin isteğini depolayabilirsiniz:
Bu senaryoda, comment parametresi, kamuya açık bir sayfadaki bir gönderinin yorum bölümündeki içerikleri saklamak için tasarlanmıştır. Sonuç olarak, sonraki isteğin içeriği bir yorum olarak görünecektir.
Ancak, bu tekniğin sınırlamaları vardır. Genel olarak, yalnızca kaçak istekte kullanılan parametre ayırıcıya kadar veri yakalar. URL kodlu form gönderimleri için bu ayırıcı & karakteridir. Bu, mağdur kullanıcının isteğinden yakalanan içeriğin ilk & ile duracağı anlamına gelir; bu, sorgu dizesinin bir parçası bile olabilir.
Ayrıca, bu yaklaşımın TE.CL zafiyeti ile de geçerli olduğunu belirtmek gerekir. Bu tür durumlarda, istek search=\r\n0 ile sona ermelidir. Satır sonu karakterlerinden bağımsız olarak, değerler arama parametresine eklenecektir.
HTTP Request Smuggling, Yansıyan XSS'e karşı savunmasız web sayfalarını istismar etmek için kullanılabilir ve önemli avantajlar sunar:
Hedef kullanıcılarla etkileşim gerekmez.
İsteğin normalde ulaşılamayan kısımlarında, örneğin HTTP istek başlıklarında XSS'in istismarına olanak tanır.
Bir web sitesinin User-Agent başlığı aracılığıyla Yansıyan XSS'e karşı savunmasız olduğu senaryolarda, aşağıdaki yük, bu zafiyeti nasıl istismar edeceğini göstermektedir:
Bu yük, açığı istismar etmek için şu şekilde yapılandırılmıştır:
Smuggling'in başlangıcını belirtmek için Transfer-Encoding: chunked başlığı ile, görünüşte tipik bir POST isteği başlatmak.
Chunked mesaj gövdesinin sonunu işaret eden bir 0 ile devam etmek.
Ardından, User-Agent başlığına bir script, <script>alert(1)</script>, enjekte edilen bir smuggled GET isteği tanıtmak; bu, sunucu bu sonraki isteği işlediğinde XSS'i tetikler.
User-Agent'ı smuggling ile manipüle ederek, yük normal istek kısıtlamalarını aşar ve böylece yansıtılan XSS açığını standart dışı ama etkili bir şekilde istismar eder.
Kullanıcı içeriği, Content-type gibi bir yanıt içinde yansıtıldığında, XSS'in çalışmasını engelleyebilir. Eğer sunucu HTTP/0.9 destekliyorsa, bunu aşmak mümkün olabilir!
HTTP/0.9 sürümü, 1.0'dan önceydi ve yalnızca GET fiillerini kullanır ve başlıklar ile yanıt vermez, sadece gövdeyi kullanır.
bu yazıda, bir istek smuggling ile ve kullanıcının girişi ile yanıt verecek bir açık uç noktası ile istismar edildi; HTTP/0.9 ile bir istek smuggling yapmak için. Yanıtta yansıtılacak parametre, geçerli başlıklar ve gövde ile sahte bir HTTP/1.1 yanıtı içeriyordu, böylece yanıt geçerli çalıştırılabilir JS kodu içerecek ve Content-Type olarak text/html olacaktır.
Uygulamalar genellikle yönlendirme URL'sindeki Host başlığından hostname kullanarak bir URL'den diğerine yönlendirir. Bu, Apache ve IIS gibi web sunucularında yaygındır. Örneğin, bir klasörü sonuna eğik çizgi olmadan istemek, eğik çizgiyi dahil etmek için bir yönlendirme ile sonuçlanır:
Sonuçlar:
Görünüşte zararsız olan bu davranış, kullanıcıları harici bir siteye yönlendirmek için HTTP request smuggling kullanılarak manipüle edilebilir. Örneğin:
Bu kaçak istek, sonraki işlenen kullanıcı isteğinin bir saldırgan kontrolündeki web sitesine yönlendirilmesine neden olabilir:
Sonuçlar:
Bu senaryoda, bir kullanıcının JavaScript dosyası için isteği ele geçirilir. Saldırgan, kötü niyetli JavaScript sunarak kullanıcıyı tehlikeye atabilir.
Web cache poisoning, ön uç altyapısının içerik önbelleğe alması durumunda gerçekleştirilebilir; bu genellikle performansı artırmak için yapılır. Sunucunun yanıtını manipüle ederek, önbelleği zehirlemek mümkündür.
Daha önce, sunucu yanıtlarının 404 hatası dönecek şekilde nasıl değiştirilebileceğini gözlemledik (bkz. Temel Örnekler). Benzer şekilde, sunucuyu /static/include.js isteğine yanıt olarak /index.html içeriği sunmaya kandırmak mümkündür. Sonuç olarak, /static/include.js içeriği önbellekte /index.html ile değiştirilir, bu da /static/include.js'nin kullanıcılara erişilemez hale gelmesine neden olur ve bu durum bir Hizmet Reddi (DoS) ile sonuçlanabilir.
Bu teknik, bir Açık Yönlendirme açığı keşfedildiğinde veya açık yönlendirmeye yerel bir yönlendirme olduğunda özellikle güçlü hale gelir. Bu tür açıklar, saldırganın kontrolündeki bir script ile /static/include.js'nin önbelleğe alınmış içeriğini değiştirmek için sömürülebilir ve bu da güncellenmiş /static/include.js'yi talep eden tüm istemcilere karşı yaygın bir Cross-Site Scripting (XSS) saldırısına olanak tanır.
Aşağıda, önbellek zehirlenmesi ile açık yönlendirmeye yerel bir yönlendirme kombinasyonunun sömürülmesine dair bir illüstrasyon bulunmaktadır. Amaç, saldırgan tarafından kontrol edilen JavaScript kodunu sunmak için /static/include.js'nin önbellek içeriğini değiştirmektir:
Not edin ki, /post/next?postId=3 hedefleyen gömülü istek var. Bu istek, Host başlık değeri kullanılarak alan adını belirlemek için /post?postId=4'e yönlendirilecektir. Host başlığını değiştirerek, saldırgan isteği kendi alanına yönlendirebilir (yerinde yönlendirme ile açık yönlendirme).
Başarılı socket zehirlenmesi sonrasında, /static/include.js için bir GET isteği başlatılmalıdır. Bu istek, önceki yerinde yönlendirme ile açık yönlendirme isteği tarafından kirletilecek ve saldırgan tarafından kontrol edilen scriptin içeriğini alacaktır.
Sonrasında, /static/include.js için yapılan her istek, saldırganın scriptinin önbelleğe alınmış içeriğini sunacak ve etkili bir geniş XSS saldırısı başlatacaktır.
Web önbellek zehirlenmesi ile web önbellek aldatması arasındaki fark nedir?
Web önbellek zehirlenmesi'nde, saldırgan uygulamanın önbellekte bazı kötü niyetli içerikleri saklamasına neden olur ve bu içerik diğer uygulama kullanıcılarına önbellekten sunulur.
Web önbellek aldatması'nda, saldırgan uygulamanın önbellekte başka bir kullanıcıya ait bazı hassas içerikleri saklamasına neden olur ve saldırgan daha sonra bu içeriği önbellekten alır.
Saldırgan, hassas kullanıcıya özel içeriği alacak şekilde kaçırılmış bir istek hazırlar. Aşağıdaki örneği düşünün:
Eğer bu kaçak istek, statik içerik için tasarlanmış bir önbellek girişini zehirliyorsa (örneğin, /someimage.png), mağdurun /private/messages adresindeki hassas verileri statik içeriğin önbellek girişi altında önbelleğe alınabilir. Sonuç olarak, saldırgan bu önbelleğe alınmış hassas verilere erişim sağlayabilir.
Bu yazıda eğer sunucuda TRACE yöntemi etkinse, bunun HTTP Request Smuggling ile istismar edilebileceği önerilmektedir. Bunun nedeni, bu yöntemin sunucuya gönderilen herhangi bir başlığı yanıtın gövdesinin bir parçası olarak yansıtmasıdır. Örneğin:
Gönderecek bir yanıt şöyle olacak:
Bir davranışı kötüye kullanma örneği, önce bir HEAD isteği sızdırmak olacaktır. Bu istek, yalnızca bir GET isteğinin başlıklarıyla yanıtlanacaktır (Content-Type bunlar arasında). Ve HEAD'den hemen sonra bir TRACE isteği sızdırmak, bu istek gönderilen verileri yansıtacaktır.
HEAD yanıtı bir Content-Length başlığı içereceğinden, TRACE isteğinin yanıtı HEAD yanıtının gövdesi olarak kabul edilecek ve bu nedenle yanıt içinde rastgele verileri yansıtacaktır.
Bu yanıt, bağlantı üzerinden bir sonraki isteğe gönderilecektir, bu nedenle bu, örneğin rastgele JS kodu enjekte etmek için önbelleğe alınmış bir JS dosyasında kullanılabilir.
bu gönderiyi takip etmeye devam etmek, TRACE yöntemini kötüye kullanmanın başka bir yolunu önermektedir. Yorumlandığı gibi, bir HEAD isteği ve bir TRACE isteği sızdırarak, HEAD isteğine yanıt olarak yansıtılan bazı verileri kontrol etmek mümkündür. HEAD isteğinin gövdesinin uzunluğu esasen Content-Length başlığında belirtilmiştir ve TRACE isteğine verilen yanıtla oluşmaktadır.
Bu nedenle, yeni fikir, bu Content-Length ve TRACE yanıtında verilen verileri bilerek, TRACE yanıtının Content-Length'ın son baytından sonra geçerli bir HTTP yanıtı içermesini sağlamak, bir saldırganın bir sonraki yanıt için isteği tamamen kontrol etmesine olanak tanımaktır (bu, bir önbellek zehirlenmesi gerçekleştirmek için kullanılabilir).
Örnek:
Bu yanıtları üretecektir (HEAD yanıtının bir Content-Length'e sahip olduğunu ve TRACE yanıtının HEAD gövdesinin bir parçası haline geldiğini ve HEAD Content-Length'i sona erdiğinde geçerli bir HTTP yanıtının sızdırıldığını not edin):
Bir HTTP İstek Kaçırma açığı buldunuz ve bunu nasıl istismar edeceğinizi bilmiyorsunuz. Bu diğer istismar yöntemlerini deneyin:
HTTP Response Smuggling / DesyncTarayıcı HTTP İstek Kaçırma (İstemci Tarafı)
HTTP/2 Düşürmelerinde İstek Kaçırma
From https://hipotermia.pw/bb/http-desync-idor
From: https://hipotermia.pw/bb/http-desync-account-takeover
https://github.com/bahruzjabiyev/t-reqs-http-fuzzer: Bu araç, garip istek kaçırma tutarsızlıklarını bulmak için yararlı olan dil bilgisi tabanlı bir HTTP Fuzzer'dır.
AWS Hacking öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE) GCP Hacking öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
