HTTP isteği kaçakçılığı – 5 pratik ipucu

   Haziran 14, 2025  Posted in Mix


James Kettle (@albinowax) Portswigger’dan, altı ay önce kaçakçılığı yapan HTTP isteği üzerine çığır açan araştırmasını yayınladı, hemen bunun ayrıntılarına girmedim. Bunun yerine, bir müşteriye altyapı güvenliği konusunda tavsiyelerde bulunma zamanı gelene kadar, birkaç ay boyunca karmaşık bir saldırı türü olanı görmezden geldim, tüm yaygaraların ne olduğunu anladığımdan emin olduğumu hissettim.

O zamandan beri, değişen sonuçlarla bir dizi şık senaryodan tekniği kullanabildim. Bu yazı, saldırının savunmasız olduğu tespit edilen sunuculara ve web sitelerine karşı etkisini araştırırken yararlı bulduğum bir dizi pratik husus ve teknik üzerine odaklanıyor. HTTP isteği kaçakçılığına aşina değilseniz, aşağıda neyin takip ettiğini daha iyi anlamak için konuyu okumanızı şiddetle tavsiye ederim. Bunlar mutlak iki mutlaka okunmalıdır:

Özetlemek

Bir özet olarak, bir teknik olarak istek kaçakçılığı hakkında konuşurken kavramanız gereken bazı önemli konular vardır:

  1. Desenkronizasyon

Bir HTTP isteği kaçakçılığı güvenlik açığının kalbinde, iki iletişim sunucusunun birbiriyle senkronize olmamasıdır: Bir HTTP istek mesajı, kötü niyetli bir yükle ile bir sunucu, yükü isteğin sonu olarak yorumlayacak ve ikincisi, tek bir HTTP isteğine dahil olan “bir sonraki HTTP isteği” na geçecek ve tek bir HTTP’yi kullanacak ve bu tür bir isteği kullanacak.

  1. Zehirlenme isteyin

Başarılı bir desenkronizasyon saldırısı sonucunda, bir saldırgan kötü niyetli yüke eklenen HTTP talebinin yanıtını zehirleyebilir. Örneğin, bir sayfaya kaçak bir HTTP isteği yerleştirerek evil.htmlşüphesiz bir kullanıcı, sunucuya gönderdikleri bir talebe gerçek yanıttan ziyade kötü sayfanın yanıtını alabilir.

  1. Kaçakçılık Sonucu

Başarılı bir HTTP kaçakçılık saldırısının sonucu, sunucunun ve müşterinin zehirlenen talebe nasıl tepki verdiğine bağlı olacaktır. Örneğin, tek bir resim dosyasına ev sahipliği yapan statik bir web sitesine karşı başarılı bir saldırı, binlerce eşzamanlı aktif kullanıcıyla dinamik bir web uygulamasını başarıyla hedeflemekten çok farklı bir etkiye sahip olacaktır. Bir dereceye kadar, kaçakçılık saldırınızın sonucunu kontrol edebilirsiniz, ancak bazı durumlarda şanssız olabilirsiniz ve saldırının etkisinin gerçekten hiçbirinin yanında olmadığı sonucuna varmanız gerekebilir.

Pratik İpuçları

Genel olarak, deneyimlerimi iki kategoride başarılı istek kaçakçılığı saldırıları ile kategorize edebilirim: uygulama mantığından yararlanmak ve sunucu yönlendirmelerini kullanmak.

Zengin bir web uygulamasına sahip savunmasız bir web sitesini hedeflerken, mevcut uygulama özellikleri aracılığıyla hassas bilgileri yaymak genellikle mümkündür. Herhangi bir bilgi daha sonraki bir noktada almanız için saklanırsa (bir sohbet, profil açıklaması, günlükleri,….) Tam HTTP isteklerini daha sonra okuyabileceğiniz bir yerde saklayabilirsiniz.

Öte yandan sunucuyu yeniden yönlendirirken, iyi bir POC oluşturmak için iki şeyi düşünmeniz gerekir: bir yönlendirmenin zorlanması gerekir ve bir etkisi olması için saldırgan kontrollü bir sunucuya işaret etmelidir.

Aşağıda, bir HTTP isteği kaçakçılık kırılganlığının etkisini belirlemede yararlı bulduğum beş pratik ipucu bulunmaktadır.

#1 – Bir yönlendirmeyi zorla

Kötü niyetli bir yükü kaçırmaya çalışmadan önce, hangi yükün istenen sonuca ulaşmanıza yardımcı olacağını belirlemeye değer. Bunu test etmek için, genellikle Kenar vakalarını nasıl ele aldığını görmek için savunmasız sunucuya bir dizi doğrudan istek gönderiyorum. Bir sunucu doğrudan (HTTP durum kodu 30x) ile sonuçlanan bir istek bulduğunuzda, bir sonraki adıma geçebilirsiniz.

Bir yönlendirme ararken rutinime dahil etmeye başladığım bazı testler:

  • /aspnet_client Microsoft IIS’de her zaman bir takipçiye ekleyecek ve yönlendirecek/aspnet_client/
  • Bunu yapma eğiliminde olan diğer bazı dizinler /content– /assets–/images– /styles,…
  • Genellikle HTTP istekleri HTTPS’ye yönlendirilir
  • Referans başlığının yolunun yeniden yönlendirmek için kullanıldığı bir örnek buldum, yani Referer: https://www.company.com//abc.burpcollaborator.net/hacked yönlendirir mi //abc.burpcollaborator.net/hacked
  • Bazı siteler, belirli bir dosya uzantısı olan tüm dosyaları yeniden yönlendirecektir, örneğin test.php ile test.aspx

#2 – Özel bir ana bilgisayar belirtin

Bir yönlendirme ile sonuçlanan bir istek bulduğunuzda, bir sonraki adım, farklı bir sunucuya yönlendirmeye zorlayıp zorlayamayacağınızı belirlemektir. Bunu aşağıdakilerin her birini deneyerek başarabildim:

  • Aşağıdaki başlıklardan herhangi birini ekleyerek ve sunucunun bunlara nasıl yanıt verdiğini araştırarak sunucunun kaçak isteğinizi ayrıştıracağı ana bilgisayar adını geçersiz kılın:
    • Host: evil.com
    • X-Host: evil.com
    • X-Forwarded-Host: evil.com
  • Benzer şekilde, kaçırılan isteğin ilk satırına geçersiz kılınan ana bilgisayar adını dahil etmek işe yarayabilir: GET http://evil.com/ HTTP/1.1
  • Kaçak olunan talebin ilk satırını yasadışı bir şekilde biçimlendirmeyi deneyin: GET .evil.com HTTP/1.1 Sunucu URI’yi mevcut ana bilgisayar adına eklerse çalışacaktır: Location: https://vulnerable.com.evil.com

#3 – Sızıntı Bilgileri

Saldırgan kontrollü bir sunucuya yönlendirip veremediğinize bakılmaksızın, savunmasız sunucuda çalışan uygulamanın özelliklerini araştırmaya değer. Bu, hedeflediğiniz uygulama türüne bağlıdır, ancak arayabileceğiniz şeylerin birkaç işaretçisi:

  • E -posta Özellikleri – Bir kopya alan bir e -postanın içeriğini tanımlayıp tanımlayamayacağınızı görün;
  • Sohbet özellikleri – Kaçak bir istekte bulunabiliyorsanız, sohbet pencerenizdeki tam HTTP isteğini okuyabilirsiniz;
  • Profili Güncelle (Ad, Açıklama,…)-Yazabileceğiniz ve okuyabileceğiniz herhangi bir alan, özel ve yeni satır karakterlere izin verdiği sürece yararlı olabilir;
  • JSON’u klasik bir yazı gövdesine dönüştürün – bir uygulama özelliğinden yararlanmak istiyorsanız, ancak JSON üzerinden iletişim kurar (örn. {"a":"b", "c":"3"}), kodlamayı bir klasik olarak değiştirip değiştiremeyeceğinize bakın a=b&c=3 başlıkta biçim Content-Type: application/x-www-form-urlencoded.

#4 – Kaçak kalmış isteğinizi mükemmelleştirin

Bir kaçakçılık saldırısı başlatırken sorunlarla karşılaşıyorsanız ve beklenen yönlendirmeyi görmüyorsanız, ancak beklenmedik hata kodlarıyla karşı karşıya kalıyorsanız (örn. 400 Kötü Talep), kaçak isteğinize biraz daha bilgi vermeniz gerekebilir. Bazı sunucular, HTTP isteğinde beklenen öğeleri bulamadığında başarısız olur. İşte bazen çalışan bazı şeyler:

  • Tanımlamak Content-length Ve Content-Type başlıklar;
  • Ayarladığınızdan emin olun Content-Type ile application/x-www-form-urlencoded Bir sonrası isteği kaçak yapıyorsanız;
  • Kaçak bir isteğin içerik uzunluğu ile oynayın. Birçok durumda, kaçak içerik uzunluğunu artırarak veya azaltarak sunucu farklı yanıt verecektir;
  • Switch Post isteğine ulaşır, çünkü bazı sunucular sıfır olmayan bir gövdeye sahip istekleri almayı sevmez.
  • Sunucunun birden fazla almadığından emin olun Host Başlıklar, yani eklenen isteği kaçak isteğinizin posta gövdesine iterek;
  • Bazen, zehirlenmiş HTTP isteğinizi yansıtan farklı bir sayfa bulabiliyorsanız, bu tür sorunların giderilmesine yardımcı olur, örneğin post bedenlerde değerleri döndüren sayfaları arayın, örneğin bir hata mesajı olan bir hata sayfası. Aktarılan isteğinizin içeriğini okuyabiliyorsanız, yükünüzün neden sunucu tarafından kabul edilmediğini anlayabilirsiniz;
  • Sunucu, Cloudflare, Akamai veya benzeri gibi tipik bir yük dengeleyicinin arkasındaysa, genel IP’sini SecurityTrails gibi bir hizmet aracılığıyla bulup bulamayacağınıza bakın ve HTTP isteği kaçakçılığı saldırısını doğrudan bu “arka uç” e yönlendirebilir;
  • Şifreli olmayan (HTTP) hizmetin sunucuda dinlemenin HTTP talep kaçakçılığı saldırılarına karşı savunmasız olduğu durumlarda, güvenli kanal (HTTPS) hizmeti ve başka bir şekilde de gördüm. Hem ayrı olarak test ettiğinizden emin olun ve her iki hizmetin de etkisini ayrı ayrı araştırdığınızdan emin olun. Örneğin, HTTP savunmasız olduğunda, ancak tüm uygulama mantığı yalnızca HTTPS sayfalarında sunulduğunda, etki göstermek için uygulama mantığını kötüye kullanmakta zorlanacaksınız.

#5 – İyi bir POC oluşturun

  • Uygulama mantığını hedefliyorsanız ve zehirli taleplerinize çarpan keyfi mağdurların bir oturum kaçırma saldırısına dayanan tüm HTTP gövdesini rastgele taleplerin tamamını ortadan kaldırabilirseniz, istek başlıklarında oturum çerezlerini görebilir ve tarayıcı tarafındaki enstrigasyonlar tarafından engellenemezseniz, http-only Tipik bir XSS senaryosunda bayrak. Bu, saldırganın bakış açısından ideal senaryo;
  • Başarılı bir yönlendirme bulduğunuzda, birkaç isteği zehirlemeyi deneyin ve sunucunuza hangi bilgilerin gönderildiğini görmek için saldırgan sunucunuzu izleyin. Tipik olarak bir tarayıcı, istemciyi farklı bir etki alanına yönlendirirken oturum çerezleri eklemez, ancak bazen başsız istemciler daha az güvenlidir: yönlendirmeler beklemeyebilir ve farklı bir sunucuya yönlendirildiğinde bile hassas bilgiler gönderebilirler. Sulu bilgi için parametreleri, gövdeleri gönderin ve başlıkları isteyin;
  • Bir yönlendirme başarılı olduğunda, ancak yolunuza duyarlı bir şey almadığınızda, istek zehirlenmesini depolanmış bir XSS’ye dönüştürmek için javascript dosyaları içeren bir sayfa bulun, yönlendirme bir JavaScript yüküne (örneğin https://xss.honoki.net.net/) bir grup oluşturan bir poC oluşturan bir poC oluşturun ve bir poC oluşturan bir poC oluşturun.



    Source link