URL'in Elli Tonu
URL, yani Uniform Resource Locator, web'in en önemli, temel bileşenlerinden biri. Talep ettiğimiz kaynak nereden ve nasıl talep edilecek, hangi yetkilerle talep edilecek URL'ler vasıtası ile bildirebiliyoruz.
URL, yani Uniform Resource Locator, web'in en önemli, temel bileşenlerinden biri. Talep ettiğimiz kaynak nereden ve nasıl talep edilecek, hangi yetkilerle talep edilecek URL'ler vasıtası ile bildirebiliyoruz.
URL'e dair önemli ayrıntılar bilinmediğinde, özellikle istemci-taraflı zafiyetler konusunda aldığımız tüm tedbirler boşa çıkabilir. Elbette bu yazıda sözü edilecek trickler ile blacklist bypass edip, sunucu taraflı (örneğin SSRF) zafiyetleri de exploit edebilmek mümkün. Ama önemli bir kısmı client-side yani istemci taraflı zafiyetlerde kullanılabilir. Zira çoğu tarayıcı töleransı ile alakalı.
Şimdi Hackerone'da yayınlanan bir zafiyet dolayısıyla URL yapısını daha yakından inceleyelim.
Zafiyet Phabricator isminde, açık kaynak kütüphanelerden müteşekkil bir kod yönetimi programında tespit ediliyor. Chrome'un yeni versiyonları ile artık tümden hayatımızdan çıkacak olan bir zafiyet: Tabnabbing
https://hackerone.com/reports/306414
Tabnabbing zafiyeti, sitenizden referans verdiğiniz harici linkler şayet yeni bir pencere açılıyor ise (target="blank") bu açılan yeni pencere kendi DOM'undaki opener işaretçisi/nesnesi vasıtası ile kendisini açan sayfanın location.href değerini değiştirip, kendisini açan sayfanın başka bir adrese yönlenmesini sağlayabiliyor:
opener.location.href="http://www.attacker.com";Bu yolla bir oltama (phishing) saldırı gerçekleştirilebilir.
Hackerone'da raporlanan zafiyetin detaylarına dönecek olursak:
Zafiyeti raporlayan araştırmacı, yorum olarak harici link paylaşıldığında, rel="noreferrer" attribute'ü eklendiğini belirtiyor. Fakat URL'i tanımlayan RFC'lerdeki boşluklardan hareketle hazırladığı payload sayesinde, external bir domain'inin tespit edilmesini engelleyebiliyor.
Örneğin http://www.example.com linki eklendiğinde, Phabricator bu linki aşağıdaki şekle dönüştürüyor:
<a href="http://www.example.com" rel="noreferrer">Test</a>Burada bir es verip URL'in yapısını inceleyelim.
URL'in Yapısı
[1]<scheme>:[2]//[3]<user>:<password>@[4]<host>:[5]<port>/[6]<path>;[7]<params>?[8]<query>#[9]<fragment>Tüm URL'ler bu 9 parçayı içermeyebilir. En çok kullanılan URL öğeleri, şema, host ve path'dir.
scheme://hostname[:port]/[path/]file[?param=value]1) Schema (Şema)
Kaynağın hangi protokol ile getirileceğini belirtir. Büyük küçük harf duyarlı değildir. Şema adından sonra (Örneğin http) iki nokta gelir.
ftp, http, https gibi yaygın şemalar yanında, javascript, data gibi pseudo şemalar da mevcuttur.
2) Hiyeraşik URL Göstergesi (//)
Tüm absolute / hiyeraşik URL'ler bu göstergeyi içermek zorundadır. Absolute URL ve Relative URL farkı şudur. Absolute URL'de istenen kaynağın tüm bir yolu ve gerekli tüm bilgiler vardır:
http://www.example.com/test.html
Oysa Relative URL'de, ziyaret ettiğimiz sayfadan hareketle kaynağın yeri çözümlenir ve istek yapılır.
Örneğin http://www.example.com/test.html sayfasını ziyaret ettiğimizde bu sayfa aşağıdaki gibi bir link içeriyorsa:
<a href="product.html">Product</a>Bu linke tıklandığında adres http://www.example.com/product.html olarak çözümlenecektir.
3) Credentials
Eğer talep edilen kaynak bir yetki gerektiriyorsa şemaya uygun olarak kullanıcı adı ve parola bilgileri, 3 numara olarak işaretlediğimiz alan vasıtası ile yapılmaktadır:
Örneğin: ftp://[email protected]
Şöyle bir senaryo düşünelim. Kullanıcıdan aldığı url datası şayet example.com datası içeriyorsa verilen adrese istek yapan bir uygulama düşünelim. Saldırgan buradaki blacklist'i kolaylıkla aşağıdaki gibi bir yöntem ile bypass edebilir:
Yukarıdaki payload ile istek doğrudan attacker.com 'a yapılacaktır.
4) Server (Host)
Kaynağın kendisinden getirileceği sunucuyu belirtir. URL'deki sunucu adı için büyük-küçük harf duyarlığı yoktur. Bir domain name olabileceği gibi IPv4 adresi, IPv6 adresi (örneğin, [0:0:0:0:0:0:0:1]) de kaynağın talep edileceği sunucu olarak verilebilir.
RFC'ye göre klasik IP notasyonu kabul edilse de, C ile geliştirilen kütüphaneler octal, decimal, hex-decimal formundaki IP adreslerini de kabul etmektedir:
Yani:
http://127.0.0.1
http://0x7f.1/
http://017700000001/Adresleri aslında 127.0.0.1 adresine işaret etmektedir. SSRF zafiyeti istismarında yerel kaynaklara erişmemeniz için 127.0.0.1 adresi kara listeye alındı ise yukarıdaki yöntemi kullanabilirsiniz.
5) Port
Talep ettiğimiz kaynağın hedef sunucunun hangi portundan servis edileceğini belirttiğimiz URL alanı.
6) Path
Talep edilen kaynağın sunucu üzerindeki yolu ve kaynağın kendisi
7)Path Param
Her bir path için ayrı parametre gönderebilmek mümkün. Örneğin Java uygulamalarında URL'den gönderilen Cookie değerlerinin JSESSIONID adı ile path param olarak gönderildiğini görebilirsiniz.
http://www.example.com/index.jsp;JSESSIONID=XXXX
IIS 6.0 öncesi versiyonlarda istismarı mümkün olan File Upload zafiyetinin de kökeni esasen budur.
Örneğin index.asp;.jpg şeklinde bir dosya adı ile uzantı (extension) kontrolü yapan bir karalisteyi geçebilmek mümkün. Fakat bu dosya adındaki ";" noktalı virgülden sonraki kısım path param olarak işlenecek, dosya uzantısı asp olarak kabul edilecektir.
8) Query
URL'in "?" kısmından sonraki kısmı Query partı olarak telakki edilir. Query kısmı ile URL üzerinden query string parametreleri göndermek mümkündür.
http://www.example.com/index.html?some=value
9) Fragment
Sunucuya gönderilmeyerek doğrudan tarayıcı tarafından sayfanın fragment alanı ile işaret edilen elemana kaydırılması sağlanır.
Uzun bir sayfa düşünelim:
http://www.example.com/index.html#contact
Yukarıdaki URL ziyaret edildiğinde id değeri contact olan elemana sayfanın odaklandığı görülecektir.
Bu kısa girişten sonra zafiyetimize geri dönelim.
External linklerin eklendiği link elemanlarına ref="noreferrer" attribute'ı ekleyerek Tabnabbing'in engellendiğini söylemiş idik.
Zafiyeti raporlayan araştırmacı /\attacker.com URL'i ile bu karalisteyi aşıyor.
Sadece bu kadar değil, URL kontekstinde tarayıcıların tölerans gösterdiği pek çok durum mevcut. Örneğin RFC'ye göre hiyeraşik URL'de bulunması gereken çift forward-slash 'ın olmadığı, tek bir tane olduğu ya da ikiden fazla olduğu hatta ve hatta forward slash yerine back-slash kullanılan durumlara da tölerans gösterilebiliyor.
Örnek 1: http://example.com&gibberish=1234@167772161/
Phishing saldırısı için harika bir örnek. Bu URL'e istek yapıldığında 167772161 değeri 10.0.0.1 adresine decode edilecek. Peki bu nasıl oluyor?
Yukarıdaki URL'i @ işaretinden itibaren iki parçaya ayırdığımızı düşünelim. @ işaretinin sol kısmı credentials kısmını imliyordu, yani istek yaptığımız kaynak bir yetki gereksiniyorsa username.password formatında credentialsları iletebiliyorduk. URL'in diğer kısımlarından farklı olarak bu credentials kısmında =, < ,=""> ,& gibi karakerler kullanabiliyoruz. Şimdi @ işaretinin sağ tarafına bakalım. Yukarıda sözünü ettiğimiz gibi bu kısımda yani @ işaretinin hemen solundan başlayan kısımda URL'in host, server bilgilerini veriyoruz. Burada da IPv4 bilgisi, Ipv6 adresi, DNS name kullanabiliyorduk. IP adresinin de decimal, octal, hex-decimal gibi formlarını verebildiğimizi söylemiş idik.
Örnek 2: http://example.com\@coredump.cx/
Yukarıdaki URL 'e istek yapıldığında tarayıcı bu isteği coredump.cx adresine gönderecek.
Son olarak, aşağıdaki URL'in tümü decode edilip, example.com olarak yorumlanmaktadır.
http://example.com/
http://%65xample.%63om/
http://%65%78%61%6d%70%6c%65%2e%63%6f%6d/
