TOPIC:

Bu yazı, web uygulamalarında HTTP istekleriyle gönderilen parametrelerin tekrarlanmasıyla yapılan bir saldırı türünden bahsetmektedir.

Bilindiği gibi web uygulamaları temelde HTTP istekleriyle çalışıyor. En yoğun kullanılan iki HTTP metodu GET, POST ve bu isteklere parametre de eklenebiliyor. Günümüzdeki dinamik web uygulamalarında bu parametrelerin bir kısmını kullanıcıdan alınan girdiler oluşturuyor.

Yeterli girdi denetimi yapılmayan uygulamalarda SQL Enjeksiyonu ve XSS gibi tehlikeli türden birçok zafiyet olabiliyor. Burada belki de bir süre sonra yukarıdaki iki zafiyetle beraber adı anılacak yeni bir enjeksiyon tipinden bahsediliyor. İlk defa 2009 yılında adı konulan bu zafiyet henüz ilgi görmüş değil. Literatüre “HTTP Parameter Pollution” ismiyle geçen zafiyeti Stefani di Paola ve Luca Carettoni OWASP EU09 konferansında duyurmuştur. Bu yazı kapsamındaki çalışma gerçekten hesaba katılması gereken bir zafiyet midir değil midir durumunu incelemek için yapılmıştır.

Saldırının amacı ve etkileri?

Parametre tekrarı zafiyeti, var olan bir parametrenin istekte aynı isim farklı değerle tekrar kullanılarak sunucu tarafında gerçek olan parametrenin ezilmesi ya da diğeriyle birleştirilmesi durumunda ortaya çıkar. Uygulama mantığını ilgilendiren saldırının amacı; uygulamanın davranışını değiştirmek, girdi denetim noktalarını atlatmak ve sunucu tarafındaki direk erişim izni olmayan değişkenleri manipüle etmek ve sömürmektir. Saldırının sonuçları uygulamanın yaptığı işe göre değişecektir, çok basit ve önemsiz bir etki olabileceği gibi uygulama mantığının tamamen ele geçirilmesiyle de sonuçlanabilmektedir.

Senaryo

Kötü amaçla oluşturulmuş bir linki (parametre tekrarı zafiyeti barındıran URL) bir kullanıcının (kurban) ziyaret etmesi ve beklemediği bir sonuçla karşılaşması tipik bir senaryo örneğidir. Buradaki kurgumuz ise şu şekilde olacak, oylama yapılan bir sayfayı düşünelim. İstek URL’i iki tane parametre içersin; “anket_id” ve “anket”. Uygulama mantığı da şu şekilde olsun; parametre olarak gelen “anket_id” değerine göre anket içeriği oluşsun.

Örnek URL,

http://sunucu/anketler.jsp?anket_id=123456&anket=sampiyon

Bu URL adresi çağrılınca gelecek olan sayfa içinde bulunacak iki linkin HTML kodu şu şekilde olacaktır.

Link 1: <a href=”pt.jsp?anket_id=123456&anket=sampiyon&takim=gs”>Galatasaray</a>

Link 2: <a href=”pt.jsp?anket_id=123456&anket=sampiyon&takim=fb”>Fenerbahçe</a>

hpp-1-normal-istek.png
Fenerbahçe taraftarı olan bir saldırganın oylama sonuçlarını etkilemek istediği bir durumu düşünelim. Sayfayı analiz eden saldırgan uygulamanın “anket” parametresini yeterli girdi kontrolünden geçirmediğini tespit eder. Bu parametreye bir enjeksiyon yaparak sonuçları manipüle edecek bir URL oluşturur ve internet ortamında linki yayar.

http://sunucu/anketler.jsp?anket_id=123456&anket=sampiyon%26takim=fb

Linki bir şekilde bulup tıklayan kurban gerçek oylama sayfasını açmış olur fakat oluşan sayfa artık zehirlidir. URL’de görüldüğü gibi gerçek adresten farklı olarak URL adresinin sonuna “%26takim=fb” şeklinde bir ek yapılmıştır. Kısaca açılacak sayfada “takim” parametresi aşağıdaki gibi tekrarlanacaktır. Kurbanın hangi linke tıklayacağının bir öneminin kalamadığı linkler de aşağıdaki gibi olacaktır.

Link 1: <a href=”pt.jsp?anket_id=12345&anket=sampiyon&takim=fb&takim=gs”>Galatasaray</a>
Link 2: <a href=”pt.jsp?anket_id=12345&anket=sampiyon&takim=fb&takim=fb”>Fenerbahçe</a>

Bu sayfadan yapılacak isteklerde sunucu tarafına iki tane “takim” parametresi gidecektir ve tüm isteklerdeki ilk “takim” parametresi “fb” olarak sabitlenmiştir. Kilit noktaya geldik. Uygulama kod kesiminde “takim” parametresinin içindeki değeri ver denildiğinde, ilk parametrenin mi son parametrenin mi değerinin verileceğine uygulama sunucusu karar veriyor.

Her uygulama sunucusu kendi parametre işleme tekniğine göre hangi parametreyi seçeceğini belirlemiştir. Yukarıdaki senaryo uygulamasında Tomcat kullanılmıştır ve Tomcat ilk gelen parametreyi seçmektedir. Senaryodaki uygulamada sunucu hep “fb” değerini vereceği için hangi linke tıklanılırsa tıklansın oyun gideceği takım değişmeyecektir.

Yeri gelmişken yaygın kullanılan diğer uygulama sunucularında da aşağıdaki şekilde seçimler yapılmaktadır.

Sunucu

Seçim

Örnek

Apache Tomcat

İlk

par1=val1

Oracle WebLogic

İlk

par1=val1

IBM WebSphere

İlk

par1=val1

JBoss

İlk

par1=val1

ASP .NET/IIS

Hepsi

par1=val1,val2

PHP/Apache

Sonuncu

par1=val2

Uygulama sunucum tespit edilemiyor, güvende miyim?

Maalesef hayır. İlle de uygulama sunucusunun tespit edilmesi şart değil, sunucunun nasıl işlem yaptığını tespit etmekte yeterli olacaktır. Uygulamadaki herhangi bir parametre yukarıda anlatıldığı gibi tekrar edilir ve uygulamanın davranışı incelenir, bu saldırının nasıl yapılması gerektiğini söyleyecektir.

Örnek olarak, Google'da "q" parametresiyle yapılan denemede parametrelerin birleştirildiği görülmektedir. Yani uygulama sunucusu aynı isimli parametrelerin değerini birleştirecek şekilde yorum yapmaktadır.

hpp-2-google.png

Yahoo'da ise "p" parametresiyle yapılan denemede sunucunun sadece son parametreyi işleme aldığı görülmektedir.

hpp-3-yahoo.png

Gerçek hayat

Sıklıkla kullandığımız uygulamalarda veya geliştirdiğimiz uygulamalarda bu zafiyet var mıdır diye sorarsanız, yukarıda bahsedildiği gibi oylama türünden işlemlerin olduğu, içinde ekle, düzenle ve sil gibi iş mantıklarının yürütüldüğü uygulamaların URL adreslerini test edebilirsiniz.

Önlem

Yazılımcı için kullanılan uygulama sunucusunun davranışı bilindiği sürece bir sıkıntı yoktur. Ayrıca bunu önlemek için sunucu tarafında alınabilecek birçok önlem de mevcuttur. En kötü durumda, bir istekte aynı parametre birden fazla kez tekrarlanıyorsa istek reddedilecek şekilde bir geliştirme yapılabilir.