HTTP Host Header açığı zayıflıklarını nasıl tanımlayıp kullanacağınızı öğrenmek için bu bölüme daha yakından bakacağız. Ardından, bunu nasıl kullanabileceğinize dair örnekler sunacağız ve kasıtlı olarak zayıf bir web sitesinde bu saldırıları pratik yapmak için kullanabileceğiniz birkaç etkileşimli laboratuvarı da sunacağız.
HTTP Host Header kullanarak zayıflıkları test etmek için, Burp Proxy gibi araya giren bir proxy ve Burp Repeater ile Burp Intruder gibi manuel test araçları gibi araçlara ihtiyacınız olacak.
Kısacası, Host Headerını değiştirip isteğinizle hedef uygulamaya hala erişip erişemediğinizi belirlemeniz gerekecek. Eğer öyleyse, bu başlığı kullanarak uygulamayı sorgulayabilir ve buğün yanıt üzerinde ne tür bir etki yaptığını gözlemleyebilirsiniz.
Host Headerı enjeksiyon zayıflıklarını sorgularken, ilk adım Host Headerı üzerinden tanınmayan bir alan adını ne zaman sağladığınızı test etmektir.
Bazı araya giren proxy'ler hedef IP adresini doğrudan Host Headerından türetir, bu da bu tür bir testi neredeyse imkansız hale getirir; başlıkta yaptığınız herhangi bir değişiklik sadece isteğin tamamen farklı bir IP adresine gönderilmesine neden olur. Ancak, Burp Suite Host Headerı ile hedef IP adresi arasındaki ayrımı doğru bir şekilde korur. Bu ayrım, istenen hedefe isteğin gönderilmesini sağlarken istediğiniz herhangi bir keyfi veya hatalı Host Headerı sağlamanıza olanak tanır.
Tüyo:
Hedef URL, ya panelin üstünde (Burp Repeater ve Proxy araya girmesi için) ya da Burp Intruder'daki 'Hedef' sekmesinde görüntülenir. Hedefi düzenlemek için kalem simgesine tıklayarak manuel olarak düzenleyebilirsiniz.
Bazen beklenmeyen bir Host Header sağlasanız bile hedef web sitesine hala erişebilirsiniz. Bu birkaç nedenle olabilir. Örneğin, sunucular bazen tanımadıkları alan adları için istek alırlarsa varsayılan veya yedek bir seçenekle yapılandırılmış olabilir. Eğer hedef web sitesi varsayılan ise şanslısınız demektir. Bu durumda uygulamanın Host Headerıyla ne yaptığını ve bu davranışın kullanılabilir olup olmadığını incelemeye başlayabilirsiniz.
Öte yandan, Host Headerı web sitelerinin çalışma biçiminin temel bir parçası olduğundan, onunla oynamak genellikle hedef uygulamaya hiç ulaşamayacağınız anlamına gelir. İsteklerinizi alan ön yüz sunucusu veya yük dengeleyici, nereye yönlendireceğini sadece bilemeyebilir ve bu da türden bir "Invalid Host header" hatasına yol açabilir. Bu özellikle hedefiniz bir CDN aracılığıyla erişiliyorsa daha olasıdır. Bu durumda, aşağıda belirtilen tekniklerin bazılarını denemeye devam etmelisiniz.
Geçersiz Host Headerı" yanıtı yerine isteğinizin bir güvenlik önlemi sonucu engellendiğini bulabilirsiniz. Örneğin, bazı web siteleri, Host Headerının TLS el sıkışmasındaki SNI ile eşleşip eşleşmediğini doğrular. Bu, Host Headerı saldırılarına karşı bağışık oldukları anlamına gelmez.
Web sitesinin Host Headerını nasıl ayrıştırdığını anlamaya çalışmalısınız. Bu bazen doğrulamayı atlamak için kullanılabilecek açıkların ortaya çıkmasına neden olabilir. Örneğin, bazı ayrıştırma algoritmaları, Host Headerından bağı limanı çıkarabilir, bu da yalnızca alan adının doğrulandığı anlamına gelir. Eğer sayısal olmayan bir liman sağlayabiliyorsanız, alan adını dokunmadan bırakarak hedef uygulamaya ulaştığınızdan emin olabilirken, liman aracılığıyla bir yük enjekte etme olasılığınız olabilir.
Diğer siteler, keyfi alt alanlar için izin vermek için eşleştirme mantığı uygulamaya çalışacaktır. Bu durumda, bir beyaz listelenenle aynı karakter dizisini bitiren keyfi bir alan adı kaydederek doğrulamayı tamamen atlayabilirsiniz:
Alternatif olarak, zaten kompromize ettiğiniz daha az güvenli bir alt alanı kullanabilirsiniz:
Ana bilgisayarı doğrulayan kod ve onunla zayıf bir şey yapan kod genellikle farklı uygulama bileşenlerinde veya hatta ayrı sunucularda bulunur. Host Headerını nasıl alıp aldıklarındaki farklılıkları tanımlayarak, hangi sistemin baktığına bağlı olarak farklı bir ana sahip gibi görünen belirsiz bir istekte bulunabilirsiniz.
Aşağıda, belirsiz istekler oluşturabileceğiniz bazı örnekler sadece birkaç örnek:
Tekrarlanan Host Headerları eklemeyi denemek bir yaklaşım olabilir. Kabul edilmelidir ki, bu genellikle isteğinizin engellenmesine neden olur. Ancak tarayıcının böyle bir isteği gönderme olasılığı düşük olduğundan, geliştiricilerin bu senaryoyu öngörmemiş olabileceği bazen karşınıza çıkabilir. Bu durumda, bazı ilginç davranışsal garip detaylarını ortaya çıkarabilirsiniz.
Farklı sistemler ve teknolojiler bu durumu farklı şekillerde ele alır, ancak genellikle iki başlıktan birinin diğerine üstünlük verildiği ve değerini geçersiz kıldığı yaygındır. Sistemler hangi başlığın doğru olduğu konusunda anlaşmazsa, bunu sömürme olasılığınız olan farklılıklara yol açabilir. Aşağıdaki isteği düşünün
HTTP Host Header kullanarak zayıflıkları test etmek için, Burp Proxy gibi araya giren bir proxy ve Burp Repeater ile Burp Intruder gibi manuel test araçları gibi araçlara ihtiyacınız olacak.
Kısacası, Host Headerını değiştirip isteğinizle hedef uygulamaya hala erişip erişemediğinizi belirlemeniz gerekecek. Eğer öyleyse, bu başlığı kullanarak uygulamayı sorgulayabilir ve buğün yanıt üzerinde ne tür bir etki yaptığını gözlemleyebilirsiniz.
Host Headerı enjeksiyon zayıflıklarını sorgularken, ilk adım Host Headerı üzerinden tanınmayan bir alan adını ne zaman sağladığınızı test etmektir.
Bazı araya giren proxy'ler hedef IP adresini doğrudan Host Headerından türetir, bu da bu tür bir testi neredeyse imkansız hale getirir; başlıkta yaptığınız herhangi bir değişiklik sadece isteğin tamamen farklı bir IP adresine gönderilmesine neden olur. Ancak, Burp Suite Host Headerı ile hedef IP adresi arasındaki ayrımı doğru bir şekilde korur. Bu ayrım, istenen hedefe isteğin gönderilmesini sağlarken istediğiniz herhangi bir keyfi veya hatalı Host Headerı sağlamanıza olanak tanır.
Tüyo:
Hedef URL, ya panelin üstünde (Burp Repeater ve Proxy araya girmesi için) ya da Burp Intruder'daki 'Hedef' sekmesinde görüntülenir. Hedefi düzenlemek için kalem simgesine tıklayarak manuel olarak düzenleyebilirsiniz.
Bazen beklenmeyen bir Host Header sağlasanız bile hedef web sitesine hala erişebilirsiniz. Bu birkaç nedenle olabilir. Örneğin, sunucular bazen tanımadıkları alan adları için istek alırlarsa varsayılan veya yedek bir seçenekle yapılandırılmış olabilir. Eğer hedef web sitesi varsayılan ise şanslısınız demektir. Bu durumda uygulamanın Host Headerıyla ne yaptığını ve bu davranışın kullanılabilir olup olmadığını incelemeye başlayabilirsiniz.
Öte yandan, Host Headerı web sitelerinin çalışma biçiminin temel bir parçası olduğundan, onunla oynamak genellikle hedef uygulamaya hiç ulaşamayacağınız anlamına gelir. İsteklerinizi alan ön yüz sunucusu veya yük dengeleyici, nereye yönlendireceğini sadece bilemeyebilir ve bu da türden bir "Invalid Host header" hatasına yol açabilir. Bu özellikle hedefiniz bir CDN aracılığıyla erişiliyorsa daha olasıdır. Bu durumda, aşağıda belirtilen tekniklerin bazılarını denemeye devam etmelisiniz.
Geçersiz Host Headerı" yanıtı yerine isteğinizin bir güvenlik önlemi sonucu engellendiğini bulabilirsiniz. Örneğin, bazı web siteleri, Host Headerının TLS el sıkışmasındaki SNI ile eşleşip eşleşmediğini doğrular. Bu, Host Headerı saldırılarına karşı bağışık oldukları anlamına gelmez.
Web sitesinin Host Headerını nasıl ayrıştırdığını anlamaya çalışmalısınız. Bu bazen doğrulamayı atlamak için kullanılabilecek açıkların ortaya çıkmasına neden olabilir. Örneğin, bazı ayrıştırma algoritmaları, Host Headerından bağı limanı çıkarabilir, bu da yalnızca alan adının doğrulandığı anlamına gelir. Eğer sayısal olmayan bir liman sağlayabiliyorsanız, alan adını dokunmadan bırakarak hedef uygulamaya ulaştığınızdan emin olabilirken, liman aracılığıyla bir yük enjekte etme olasılığınız olabilir.
Kod:
GET /example HTTP/1.1Host: vulnerable-website.com:bad-stuff-hereDiğer siteler, keyfi alt alanlar için izin vermek için eşleştirme mantığı uygulamaya çalışacaktır. Bu durumda, bir beyaz listelenenle aynı karakter dizisini bitiren keyfi bir alan adı kaydederek doğrulamayı tamamen atlayabilirsiniz:
Kod:
GET /example HTTP/1.1Host: notvulnerable-website.com
Kod:
GET /example HTTP/1.1Host: hacked-subdomain.vulnerable-website.comAna bilgisayarı doğrulayan kod ve onunla zayıf bir şey yapan kod genellikle farklı uygulama bileşenlerinde veya hatta ayrı sunucularda bulunur. Host Headerını nasıl alıp aldıklarındaki farklılıkları tanımlayarak, hangi sistemin baktığına bağlı olarak farklı bir ana sahip gibi görünen belirsiz bir istekte bulunabilirsiniz.
Aşağıda, belirsiz istekler oluşturabileceğiniz bazı örnekler sadece birkaç örnek:
Tekrarlanan Host Headerları eklemeyi denemek bir yaklaşım olabilir. Kabul edilmelidir ki, bu genellikle isteğinizin engellenmesine neden olur. Ancak tarayıcının böyle bir isteği gönderme olasılığı düşük olduğundan, geliştiricilerin bu senaryoyu öngörmemiş olabileceği bazen karşınıza çıkabilir. Bu durumda, bazı ilginç davranışsal garip detaylarını ortaya çıkarabilirsiniz.
Farklı sistemler ve teknolojiler bu durumu farklı şekillerde ele alır, ancak genellikle iki başlıktan birinin diğerine üstünlük verildiği ve değerini geçersiz kıldığı yaygındır. Sistemler hangi başlığın doğru olduğu konusunda anlaşmazsa, bunu sömürme olasılığınız olan farklılıklara yol açabilir. Aşağıdaki isteği düşünün
Kod:
GET /example HTTP/1.1[/SIZE][/CENTER][/SIZE][/CENTER][/SIZE][/CENTER]
[SIZE=4][CENTER][SIZE=4][CENTER][SIZE=4][CENTER]Host: vulnerable-website.com
Host: bad-stuff-hereDiyelim ki ön yüz, başlığın ilk örneğine öncelik veriyor, ancak arka yüz son örneği tercih ediyor. Bu senaryo verildiğinde, ilk başlığı kullanarak isteğinizin hedefe yönlendirilmesini sağlayabilir ve ikinci başlığı kullanarak sunucu tarafı koduna yüklemenizi iletebilirsiniz.
"İstek satırı genellikle istenen alan üzerindeki göreceli bir yolu belirtse de, birçok sunucu aynı zamanda mutlak URL'leri anlama şeklinde yapılandırılmıştır.
Mutlak bir URL ve bir Host Headerı sağlayarak oluşturulan belirsizlik, farklı sistemler arasında farklılıklara yol açabilir. Resmi olarak, isteği yönlendirirken istek satırına öncelik verilmelidir, ancak pratikte bu her zaman böyle olmaz. Aynı şekilde, çoğaltılmış Host Headerları gibi bu farklılıkları sömürme potansiyeliniz olabilir.
Kod:
GET https://vulnerable-website.com/ HTTP/1.1Host: bad-stuff-hereUnutmayın ki farklı protokollerle de deneme yapmanız gerekebilir. Sunucular, istek satırının bir HTTP veya HTTPS URL içerip içermediğine bağlı olarak farklı davranışlar sergileyebilir.
HTTP başlıklarını bir boşluk karakteri ile girintileyerek değişik davranışları açığa çıkarabilirsiniz. Bazı sunucular girintili başlığı sarılmış bir satır olarak yorumlar ve bu nedenle onu önceki başlığın bir parçası olarak kabul eder. Diğer sunucular girintili başlığı tamamen görmezden gelir.
Bu durumun son derece tutarsız şekilde işlenmesi nedeniyle, isteğinizi işleyen farklı sistemler arasında genellikle farklılıklar olacaktır. Örneğin, aşağıdaki isteği düşünün:
Kod:
GET /example HTTP/1.1[/SIZE][/CENTER][/SIZE][/CENTER][/SIZE][/CENTER]
[SIZE=4][CENTER][SIZE=4][CENTER][SIZE=4][CENTER] Host: bad-stuff-here
Host: vulnerable-website.comWeb sitesi birden fazla Host Headerı içeren istekleri engelleyebilir, ancak birini böyle girintileyerek geçebilirsiniz. Ön yüz girintili başlığı görmezden geldiğinde, istek vulnerable-website.com için normal bir istek olarak işlenir. Şimdi diyelim ki arka yüz başlangıçtaki boşluğu görmezden gelir ve çiftlerde ilk başlığa öncelik verir. Bu farklılık, "sarılı" Host Headerı aracılığıyla keyfi değerler iletebilmenize olanak tanıyabilir.
Diğer Teknikler
Bu, zararlı ve belirsiz istekler vermenin birçok mümkün yolunun sadece küçük bir örneğidir. Örneğin, birçok HTTP isteği kaçırma tekniğini Host Headerı saldırıları oluşturmak için de uyarlayabilirsiniz. Bu konuyu daha ayrıntılı olarak ele alacağız.
Eğer belirsiz bir istem kullanarak Host Hederını geçersiz kıramıyorsanız, bırakarak değerini aynı bırakırken bunun üstüne çıkmanın diğer olasılıkları vardır. Bu, sadece bu amaç için tasarlanmış birkaç başka HTTP başlığı aracılığıyla yüklemenizi içeren diğer seçenekleri içerir, daha masum kullanım durumları için olsa da.
Daha önce de tartıştığımız gibi, web siteleri genellikle bir yük dengeleyici veya ters proxy gibi bir aracı sistem aracılığıyla erişilir. Bu tür bir mimaride, arka yüz sunucusunun aldığı Host Headerı genellikle bu aracı sistemlerden birinin alan adını içerebilir. Bu genellikle istenen işlev için önemli değildir.
Bu sorunu çözmek için ön yüz, istemcinin ilk isteğinin Host Headerının orijinal değerini içeren
Kod:
X-Forwarded-Host
Kod:
X-Forwarded-HostBazen
Kod:
X-Forwarded-Host'u
Kod:
GET /example HTTP/1.1[/SIZE][/CENTER][/SIZE][/CENTER][/SIZE][/CENTER]
[SIZE=4][CENTER][SIZE=4][CENTER][SIZE=4][CENTER]Host: vulnerable-website.com
X-Forwarded-Host: bad-stuff-hereX-Forwarded-Host, bu davranış için genellikle kullanılan de facto standart olsa da, aynı amaç için hizmet eden diğer başlıklarla da karşılaşabilirsiniz, bunlar arasında:
- X-Host
- X-Forwarded-Server
- X-HTTP-Host-Override
- Forwarded
Bu başlıklar, Host Headerındaki doğrulamayı atlamak veya Host Headerına ek veri enjekte etmek için kullanılabilecek diğer seçeneklerdir.
Potansiyel Host Headerı saldırılarını sorgularken, doğrudan kullanılamayan gibi görünen ancak görünüşte savunmasız davranışlarla karşılaşabilirsiniz. Örneğin, Host Headerının HTML kodu olarak kodlanmadan yanıt işaretlemesinde yansıtıldığını veya hatta doğrudan betik içe aktarmalarda kullanıldığını bulabilirsiniz. Yansıtılan, istemci tarafındaki zayıflıklar, genellikle Host Headerı tarafından neden oluşturulduğunda sömürülemez. Bir saldırganın kurbanın tarayıcısını faydalı bir şekilde yanlış bir ana bilgisayar talebi göndermeye zorlama yolunu yoktur.
Ancak, hedef bir web önbelleği kullanıyorsa, bu kullanışsız, yansıtılan zayıflığı, önbellenmiş yanıtları diğer kullanıcılara sunarak tehlikeli, depolanmış bir zayıflığa dönüştürmek mümkün olabilir.
Bir web önbellek zehirleme saldırısı oluşturmak için, sunucudan enjekte edilmiş bir yükü yansıtan bir yanıt almanız gerekir. Zorluk, bunu yaparken diğer kullanıcıların isteklerine hala eşlenen bir önbellek anahtarı korumaktır. Başarılıysanız, bir sonraki adım bu kötü amaçlı yanıtın önbelleğe alınmasını sağlamaktır. Ardından etkilenen sayfayı ziyaret etmeye çalışan herhangi bir kullanıcıya sunulur.
Bağımsız önbellekler genellikle önbellek anahtarında Host Headerını içerir, bu nedenle bu yaklaşım genellikle entegre, uygulama düzeyi önbelleklerde daha iyi çalışır. Bununla birlikte, daha önce tartışılan teknikler bazen bağımsız web önbelleklerini bile zehirlemenizi sağlayabilir.
Her HTTP başlığı, klasik sunucu tarafı zayıflıklarını sömürmek için potansiyel bir vektördür ve Host Headerı istisna değildir. Örneğin, Host Headerı üzerinden SQL enjeksiyonu araştırma tekniklerini denemelisiniz. Başlığın değeri bir SQL ifadesine iletilirse, bu sömürülebilir olabilir.
Sınırlı işlevselliğe erişim
Oldukça açık nedenlerle, birçok web sitesinin belirli işlevselliğe erişimi yalnızca iç kullanıcılara sınırlamak yaygındır. Bununla birlikte, bazı web sitelerinin erişim kontrol özellikleri, Host Headerına basit değişiklikler yaparak bu kısıtlamaları atlaymanıza izin veren hatalı varsayımlar yapabilir. Bu, diğer saldırılara karşı artan bir saldırı yüzeyini ortaya çıkarabilir.
Şirketler bazen, hem kamuya açık erişilebilir web sitelerini hem de özel, iç sitelerini aynı sunucuda barındırma hatasını yaparlar. Sunucular genellikle hem kamusal hem de özel bir IP adresine sahiptir. İç ana bilgisayar adı özel IP adresine çözünüyorsa, bu senaryo DNS kayıtlarına bakarak her zaman tespit edilemez:
Kod:
www.example.com: 12.34.56.78[/SIZE][/CENTER][/SIZE][/CENTER][/SIZE][/CENTER]
[SIZE=4][CENTER][SIZE=4][CENTER][SIZE=4][CENTER]intranet.example.com: 10.0.0.132Bazı durumlarda, iç siteyle ilişkilendirilmiş kamusal bir DNS kaydı bile olmayabilir. Bununla birlikte, bir saldırgan genellikle ana bilgisayar adlarını tahmin edebilse bile erişebilir, erişim sağladıkları herhangi bir sunucuda herhangi bir sanal ana bilgisayara. Başka yollarla gizli bir alan adını keşfettilerse, örneğin bilgi sızıntısı gibi, bunu doğrudan talep edebilirler. Aksi takdirde, Burp Intruder gibi araçları kullanarak aday alt alanlarının basit bir kelime listesi kullanarak sanal ana bilgisayarları kaba kuvvet yöntemiyle deneyebilirler.
Bazen Host Headerını kullanarak yüksek etkili yönlendirme tabanlı SSRF (Sunucu Yanıtı İmleme) saldırıları başlatmak da mümkün olabilir. Bunlar bazen "Host Headerı SSRF saldırıları" olarak bilinir ve PortSwigger Research tarafından "Cracking the lens: targeting HTTP's hidden attack-surface" adlı çalışmada derinlemesine incelenmiştir.
Klasik SSRF zayıflıkları genellikle kullanıcı tarafından kontrol edilebilen girdiden türetilen bir URL'ye HTTP istekleri gönderen XXE veya sömürülebilir iş mantığına dayanır. Öte yandan yönlendirme tabanlı SSRF, çoğu bulut tabanlı mimaride yaygın olan aracı bileşenlerin sömürülmesine dayanır. Bunlar, yerel yük dengeleyicileri ve ters proxyleri içerir.
Bu bileşenler farklı amaçlar için dağıtılmış olsalar da temelde istekleri alır ve uygun arka uça ileterek çalışırlar. Eğer güvensiz bir şekilde yapılandırılmışlarsa ve doğrulanmamış bir Host Headerına dayalı istekleri iletmek için yapılandırılmışlarsa, saldırganın seçtiği herhangi bir sistem tarafından yanlış yönlendirilmelerini sağlamak mümkün olabilir.
Bu sistemler harika hedefler oluşturur. Kamusal webden doğrudan istekleri almak için ayrıcalıklı bir ağ konumunda bulunurlar ve aynı zamanda dahili ağın büyük bir kısmına erişim sağlarlar, eğer sağlam ve geçerli bir Host Headerı kullanılırsa, bu SSRF saldırıları için güçlü bir vektör olabilir, basit bir yük dengeleyicisini dahili ağın tamamına erişim sağlayan bir geçit haline getirebilir.
Bu tür zayıflıkları tanımaya yardımcı olmak için Burp Collaborator'ı kullanabilirsiniz. Eğer Collaborator sunucunuzun alanını Host Headerında sağlarsanız ve ardından hedef sunucudan veya başka bir in-path sistemi başka bir DNS sorgusu alırsanız, istekleri keyfi alanlara yönlendirebileceğinizi gösterir.
Bir aracı sistemi başarıyla isteklerinizi keyfi bir kamusal sunucuya yönlendirebildiğinizi doğruladıktan sonra, bir sonraki adım bu davranışı dahili yalnızca sistemlere erişmek için sömürüp sömüremeyeceğinizi görmektir. Bunun için hedefin dahili ağında kullanılan özel IP adreslerini tanımlamanız gerekecektir. Uygulama tarafından sızdırılan IP adreslerine ek olarak, şirkete ait olan ana bilgisayar adlarını tarama yaparak herhangi bir özel IP adresine çözülüp çözülmediğini kontrol edebilirsiniz. Her şey başarısız olursa, hala
gibi standart özel IP aralıklarını kaba kuvvetle taramayla geçerli IP adreslerini tanımlayabilirsiniz.
Performans nedeniyle birçok web sitesi, aynı istemciyle birden fazla istek/yanıt döngüsü için bağlantıları yeniden kullanır. Kötü bir şekilde uygulanan HTTP sunucuları bazen, belirli özelliklerin, örneğin Host Headerının, aynı bağlantı üzerinden gönderilen tüm HTTP/1.1 istekleri için aynı olduğu tehlikeli bir varsayım üzerinde çalışır. Bu, bir tarayıcı tarafından gönderilen istekler için doğru olabilir, ancak Burp Repeater'dan gönderilen bir dizi istek için her zaman böyle olmayabilir. Bu, bir dizi potansiyel soruna yol açabilir.
Örneğin, zaman zaman sadece yeni bir bağlantı üzerinden aldıkları ilk istek üzerinde detaylı doğrulama yapan sunucularla karşılaşabilirsiniz. Bu durumda, zararsız görünen bir başlangıç isteği göndererek bu doğrulamayı atlayabilir ve ardından aynı bağlantı üzerinden kötü amaçlı isteğinizi gönderebilirsiniz.
Çoğu ters proxy, istekleri doğru arka uca yönlendirmek için Host Headerını kullanır. Eğer bağlantı üzerindeki tüm isteklerin başlangıç isteğiyle aynı ana makineye yönlendirildiğini varsayarlarsa, bu bir dizi Host Headerı saldırısı için faydalı bir vektör sunabilir, bunlar arasında yönlendirme tabanlı SSRF, şifre sıfırlama zehirlenmesi ve önbellek zehirlenmesi bulunur.
Bir istek satırını düzgün bir şekilde doğrulamamış özel proxy'ler, sıradışı ve hatalı giriş sağlamanıza izin verebilir, bu da talihsiz sonuçlara yol açabilir.
Örneğin, bir ters proxy, istek satırından yolu alabilir, onu http://backend-server ile öne ekleyebilir ve isteği bu yukarıdaki URL'ye yönlendirebilir. Bu yol / karakteri ile başlarsa sorunsuz çalışır, ancak bunun yerine @ karakteri ile başlarsa ne olur?
Sonuçta yukarıdaki akım URL'si, çoğu HTTP kitaplığının, private-intranete backend-server kullanıcı adıyla erişim talebi olarak yorumladığı http://backend-server@private-intranet/example olacaktır.
Bazen Host Headerını kullanarak yüksek etkili yönlendirme tabanlı SSRF (Sunucu Yanıtı İmleme) saldırıları başlatmak da mümkün olabilir. Bunlar bazen "Host Headerı SSRF saldırıları" olarak bilinir ve PortSwigger Research tarafından "Cracking the lens: targeting HTTP's hidden attack-surface" adlı çalışmada derinlemesine incelenmiştir.
Klasik SSRF zayıflıkları genellikle kullanıcı tarafından kontrol edilebilen girdiden türetilen bir URL'ye HTTP istekleri gönderen XXE veya sömürülebilir iş mantığına dayanır. Öte yandan yönlendirme tabanlı SSRF, çoğu bulut tabanlı mimaride yaygın olan aracı bileşenlerin sömürülmesine dayanır. Bunlar, yerel yük dengeleyicileri ve ters proxyleri içerir.
Bu bileşenler farklı amaçlar için dağıtılmış olsalar da temelde istekleri alır ve uygun arka uça ileterek çalışırlar. Eğer güvensiz bir şekilde yapılandırılmışlarsa ve doğrulanmamış bir Host Headerına dayalı istekleri iletmek için yapılandırılmışlarsa, saldırganın seçtiği herhangi bir sistem tarafından yanlış yönlendirilmelerini sağlamak mümkün olabilir.
Bu sistemler harika hedefler oluşturur. Kamusal webden doğrudan istekleri almak için ayrıcalıklı bir ağ konumunda bulunurlar ve aynı zamanda dahili ağın büyük bir kısmına erişim sağlarlar, eğer sağlam ve geçerli bir Host Headerı kullanılırsa, bu SSRF saldırıları için güçlü bir vektör olabilir, basit bir yük dengeleyicisini dahili ağın tamamına erişim sağlayan bir geçit haline getirebilir.
Bu tür zayıflıkları tanımaya yardımcı olmak için Burp Collaborator'ı kullanabilirsiniz. Eğer Collaborator sunucunuzun alanını Host Headerında sağlarsanız ve ardından hedef sunucudan veya başka bir in-path sistemi başka bir DNS sorgusu alırsanız, istekleri keyfi alanlara yönlendirebileceğinizi gösterir.
Bir aracı sistemi başarıyla isteklerinizi keyfi bir kamusal sunucuya yönlendirebildiğinizi doğruladıktan sonra, bir sonraki adım bu davranışı dahili yalnızca sistemlere erişmek için sömürüp sömüremeyeceğinizi görmektir. Bunun için hedefin dahili ağında kullanılan özel IP adreslerini tanımlamanız gerekecektir. Uygulama tarafından sızdırılan IP adreslerine ek olarak, şirkete ait olan ana bilgisayar adlarını tarama yaparak herhangi bir özel IP adresine çözülüp çözülmediğini kontrol edebilirsiniz. Her şey başarısız olursa, hala
Kod:
192.168.0.0/16Performans nedeniyle birçok web sitesi, aynı istemciyle birden fazla istek/yanıt döngüsü için bağlantıları yeniden kullanır. Kötü bir şekilde uygulanan HTTP sunucuları bazen, belirli özelliklerin, örneğin Host Headerının, aynı bağlantı üzerinden gönderilen tüm HTTP/1.1 istekleri için aynı olduğu tehlikeli bir varsayım üzerinde çalışır. Bu, bir tarayıcı tarafından gönderilen istekler için doğru olabilir, ancak Burp Repeater'dan gönderilen bir dizi istek için her zaman böyle olmayabilir. Bu, bir dizi potansiyel soruna yol açabilir.
Örneğin, zaman zaman sadece yeni bir bağlantı üzerinden aldıkları ilk istek üzerinde detaylı doğrulama yapan sunucularla karşılaşabilirsiniz. Bu durumda, zararsız görünen bir başlangıç isteği göndererek bu doğrulamayı atlayabilir ve ardından aynı bağlantı üzerinden kötü amaçlı isteğinizi gönderebilirsiniz.
Çoğu ters proxy, istekleri doğru arka uca yönlendirmek için Host Headerını kullanır. Eğer bağlantı üzerindeki tüm isteklerin başlangıç isteğiyle aynı ana makineye yönlendirildiğini varsayarlarsa, bu bir dizi Host Headerı saldırısı için faydalı bir vektör sunabilir, bunlar arasında yönlendirme tabanlı SSRF, şifre sıfırlama zehirlenmesi ve önbellek zehirlenmesi bulunur.
Bir istek satırını düzgün bir şekilde doğrulamamış özel proxy'ler, sıradışı ve hatalı giriş sağlamanıza izin verebilir, bu da talihsiz sonuçlara yol açabilir.
Örneğin, bir ters proxy, istek satırından yolu alabilir, onu http://backend-server ile öne ekleyebilir ve isteği bu yukarıdaki URL'ye yönlendirebilir. Bu yol / karakteri ile başlarsa sorunsuz çalışır, ancak bunun yerine @ karakteri ile başlarsa ne olur?
Kod:
GET @private-intranet/example HTTP/1.1
Son düzenleme:
