Bir çok platform, bazı güvenlik zafiyetlerine mahal vermemek için güvenlik mekanizmaları sunar. PHP bunu magic_quotes ile denedi, fakat bir çok sebepten dolayı çok mantıklı bir hareket değildi ve PHP 6 ile birlikte tarihe karışıyor.

.NET platformu üzerinde de buna benzer bir çok opsiyon mevcuttur. Örneğin XSS saldırıları için Request Validation mekanizmasını geliştirmiş ve varsayılı şartlarda bu opsiyon aktif olarak gelmektedir. Yani .NET uygulamanız hiçbir ayar yapmaksızın bir çok XSS saldırısına karşı korunmuş durumda.

Buradaki kritik nokta ise şu. Bu mekanizma bir şekilde alt edilirse, piyasadaki tüm .NET uygulamaları zafiyete maruz kalacak ve bu konuda patch çıkarmak çok basit değil. Çünkü çıkarılacak patch’i uygulamayan sistemlerde hala zafiyet olacak, çeşitli uyumluluk sorunları vs. Beraberinde gelecek. Bundan dolayı .NET Framework’de herhangi bir bug bulununca, onun giderilmesi için bir sonraki service pack ve/veya .NET sürümünü beklemelisiniz.

.NET 1.1 versiyonunda bu XSS korumasını aşmanın bir yolu bulunmuştu ve .NET 2.0 çıkana kadar XSS konusunda Request Validation’a dayanan her uygulamayı exploit edebiliyordunuz.

Bir diğer sorun ise kodun çalışacağı ortamdaki güvenlik opsiyonlarının bilinememesi sonucu developer’ların genellikle, zaten iki kere kod yazması gerekliliği. Örneğin PHP-MySQL uygulaması yazıyorsanız, genellikle magic_quotes bilgisini alıp kontrol edersiniz ve aktif değilse input’unuzu ilgili escape fonksiyonlarına gönderir ve sonrasında query’e dahil edersiniz. Eğer aktif ise doğrudan query’e ekleyebilirsiniz. Yani her halükarda iki durumu da handle etmeniz gerekiyor ise, zaten ilgili mekanizmanın bir faydasını görememiş oluyorsunuz.

İşin diğer ve sanırım en önemli kısmı ise kullanıcıların (yani yazılımcıların) bu mekanizmaları tam anlamaması sonucu doğru şekilde kullanamamaları ve zafiyete mahal vermeleri. Nasıl dediğinizi duyar gibiyim.

Basit bir örnek vermek gerekirse, integer haneye yapılan SQL Injection ataklarında magic_quotes ‘in açık olması sizi korumayacaktır. Çünkü exploit edebilmek için, hiçbir tırnak kullanmanıza gerek yok. Benzer durum .NET üzerindeki XSS koruması için de geçerli. Diyelim ki XSS şöyle bir hanede olsun :

<input type=”text” value=”<?echo $_REQUEST["input"]?>” />

Bu durumda sizi Request Validation korumayacaktır. Zira yapılacak atak şu şekildedir:
” style=”x:expression(alert(1))

Request Validation bu karakterlere kızmamaktadır. Request Validation konusunda daha detaylı bilgi almak için Onur’un Derinlemesine ASP.NET İstek Denetimi isimli yazısını okuyabilirsiniz.

Sanırım konu yeterince anlaşıldı. Kısaca platformun size sağladığı güzellik her case’i handle etmiyorsa kendi kontrolünüzü kendiniz yazın. Ediyorsa da yazmayı düşünün.

WGT olarak e-dergimizin 4. Sayısını yayınladık.

İçerisinde benim de JSON Hijacking konusunu ele aldığım bir makalem bulunuyor.

Hepimizin bildiği üzere; girdi denetimi hem web uygulaması güvenliğinin hem de genel itibariyle güvenlik sektörünün en çok yanlış yapılan şeylerinden biri.
Bir çok web uygulamasında, girdi denetiminin (sadece) javascript ile yapıldığını görüyorum. Bunun iki sebebi olabilir.

1. Girdi denetimi gibi angarya işleri (!) istemci tarafında hallederek sunucu tarafında performans kazanmak
   
2. Yanlış girilen inputu hemen göstererek response zamanını düşürmek
   

Şimdi sadece javascript (ya da herhangi bir istemci-taraflı dil) ile girdi denetimi yapıp, uygulamayı doğaya salmak beraberinde bir ton güvenlik problemi getirecektir. Atıyorum doldurduğunuz formun ad, soyad ve numara haneleri veritabanına yazılacak. Burada SQL Injection’dan haberi olan herhangi bir ortalama web uygulaması geliştiricisi,kabaca kullanıcıdan aldığı ad, soyad ve numara verilerini SQL Query’e eklemeden önce filtreleyecektir. Bu filtreleme işlemini javascirpt ile istemci tarafında yaparsa, javascript kodları çalıştıktan ve HTTP isteği browser’ınızdan çıktıktan sonra araya bir MITM saldırı proxy’si ile kolayca girilebilecek ve filtrelediğiniz veriler eski-zararlı hallerine çevirilecektir. Filtreleme yapılmış kabul ettiğiniz veriler SQL Query’e eklenecek ve sonrasında saldırganı cyber-orgazmlara gark edecektir.

Bonus Pack : MITM Saldırı Proxy’si Ne Demek ?
Herhangi bir linke tıkladığınızda ya da bir internet adresine girdiğinizde hepimizin bildiği üzere internet tarayıcınızdan, karşıdaki web sunucuya bir HTTP isteği gönderilir. Bu ikisi arasında MITM saldırı proxy’leri ile girebilir, bu yapılan istek içerisinde bulunan ; kullanıcıdan alınan parametreler, cookie ve sesion bilgileri, referer bilgilerini, yani HTTP paketinde bulunan ne varsa hepsini istediğiniz gibi değiştirebilir ya da olduğu gibi isteği iptal edebilirsiniz.

Piyasada kullanılan bir çok MITM saldırı proxy’si bulunuyor ve bunların başında WebScarab, Paros ve Burp geliyor. Bunların hepsi beraberce tasarlanmışcasına  (aslında cross-platform olup hem windows hem linux desteği vermek için ) java ile yazılmışlar.

Yukarıda anlattığımız üzere javascript , yani istemci seviyesinde yazılmış her türlü koruma çok basit şekillerde aşılabilir.

Peki Olması Gereken Nedir ?
Eğer söz konusu sistemde performans çok kritik ise
javascript seviyesinde de girdi denetimi konusu gündeme getirilebilir. Dediğimiz gibi uygulamanın kullanışlılığını arttırabilir. Ama bu tek başına yukarıda belirttiğimiz üzere güvenlik açısından oldukça yetersizdir. Bundan dolayı hem javascript hem de sunucu taraflı kod (aspx ? php ? perl ? …) seviyesinde kontroller yapılmalıdır. Javascript seviyesindeki kontrolden kurtulunsa bile sunucu tarafında yapılan kontrolde zararlı veriler yakalanacaktır. Aksi durumda ise zaten javascript seviyesinde iş çözüleceği için  sunucu tarafında yapılacak iş azalacaktır.

Olayın Psikolojik Yönü
Şimdi olayın teknik yanını bir tarafa bırakıp insani, ya da psikolojik yanlarından bahsedelim.
Bana kalırsa web uygulaması programcılarının bu hatayı yapmalarının psikolojik ve önemli bir sebebi de yukarıda yazdığım üzere hacker motivasyonundan bihaber olmalarıdır.
Zira okulda aldığım yazılım derslerinde hocalarım kullanıcıdan mümkün olduğunca az input alınması gerekliliğini vurguladılar. Bunun sebebi kullanıcının saçma sapan bir şey girmesi ve işlerin umduğunuz gibi gitmemesi sonucu programınızın crash olmasını engellemek olarak anlatıldı. Kimse güvenliğin farkında bile değildi. Herkeste olayın güvenlik boyutunun ders harici bırakılması gibi bir düşünce vardı sanırım.
Yine bu konuda bir örnek vermek gerekirse, bir dönemlik C ile Programlama derslerinde en az 10 kere stack overflow konusu geçer. Ama bugüne kadar programın crash olması haricinde, böyle bir hatanın çok kötü şekilde sömürülebileceğini(exploit edilebileceğini) anlatan bir hocaya rastlamadım.
Yani demek istediğim, bu tip saldırı konseptlerinden uzak olan developerlar genel itibariyle filtreleme işlerini “kullanıcı yanlışlıkla bir şeyleri bozmasın” temeline oturtuyorlar ve saldırganları düşünmüyorlar. Bundan dolayı böyle zayıf filtreleme mekanizması kullanıyorlar ve saldırganlar tarafından kolayca by-pass dilebiliyor.

Ekstra Okuma
Input Validation – An Application Perspective, Making Secure Applications

Böyle bir yazı dizisi yazmaya karar verdim. Tecrübelerim el verdiğince web uygulaması güvenliğinde sıkça yapılan hataları kaleme alacağım. Muhtemelen her hafta bir tane hatadan bahsedeceğim, ve henüz bir makale indeksi / zaman çizelgesi gibi bir şey çıkarmadım. Dolayısıyla yazı dizimizin ne kadar süreceğini de kestiremiyorum şu an için.

Neleri Kapsayacak ?

Yazı dizimiz sıkça yapılan yanlışları ele aldığı için zaman zaman çok klasik şeyleri konuşacağız. Kimi zaman ise garip durumları anlatacağım. Konumuz web uygulaması güvenliği olduğu için genel itibariyle girdi denetimi çevresinde dolaşıyor olsak da bunun yanında sistem seviyesinde yapılan hatalardan, felsefi yanlışlardan ve daha bir çok şeyden bahsedeceğim.

Ayrıca belirtmem gereken bir nokta daha var ki, OWASP-TOP 10 gibi bir şey değil, yani XSS web uygulaması güvenliğinde en sık yapılan hatadır şöyledir böyledir diye anlatmayacağım. Daha spesifik ve bir çok yerde karşılaştığım şeylerden bahsedeceğim.

Detay

Genellikle detaylarıyla ve alt seviyeden anlatmaya çalışacağım. Sık yapılan hatalar olduklarına göre çoğunluğun bu noktalarda problemi var ve anlatım itibariyle bilgi seviyesi anlamında ilgili herkesi kapsamaya çalışacağım.

Tarz

Problmleri bahsederken enel itibariyle subjektif olacak. Yani atıyorum  “sunucu taraflı kod” değil de “asp.net” diyeceğim. Çünkü genel durumlardan değil sık yapılan spesifik yanlışlardan bahsediyoruz, ondan dolayı en yaygın hali ile yazacağım. Haricinde yazıların içeriğinde ise tabii ki daha objektif kavramlar kullanacağım.

Uzunluk

Kimi yazılar uzun uzadıya gidecek ve “makale” tagini yakalayacak. Haricinde kimilerinde ise problem şudur, yapmayın böyle şeyler diyip 10 satırda bitireceğim.

Format, Site İşleri vs

Yazı dizisi için kullanacağım başlık notasyonu WUG-SYH # Sıra : Konu Adı şeklinde olacak. Başlık tercihi konusunda “Sıkça Yapılan Hatalar” ile “Sıkça Yapılan Yanlışlar” arasında kaldım ilk etapta. Sonra yaptığım google araması sonucu bu ismin yaygın olarak kullanıldığını görüp kararımı verdim.İlgili makalelerin blog içinde takibinin kolay olması açısından wug-syh şeklinde tag vereceğim. Hatta sağ tarafta bir WUG-SYH bölümü bile açılabilir!

Neyse, geyik çevirmeyi bırakıp aksiyona geçelim!

Out-of-Band attacks are widely known and have been using for exploiting SQL Injection vulnerabilities. The main point is making a HTTP/DNS/etc request with containing sensitive data to the server that has been controlling by the attacker via the vulnerable channel.

Basic Info

When we need OoB Channels to check XSS?

For SQL Injection attacks, they can be very useful for totally-blind SQL Injections. Because there isn’t any error message or any kind of difference at output.

Also If we don’t have permission to see the XSS vulnerable script, it can be classified as blind XSS vulnerability.

Many of blog / portal softwares stores some portions of HTTP header such as HTTP_REFERER ,USER_AGENT and HTTP_X_FORWARDED_FOR for informational purposes.Also they show these information from their administrative panels.

The Problem

From an attacker’s perspective, there is a big problem if no input sanitization were made because these sections of HTTP header can be manipulated and also can be used for attack purposes such as:

1) SQL Injection :This can occur at storing these data to the database server.

2) XSS : This can occur when administrator looks for Referers or User-Agent statistics.

In this situtation, SQL Injection may be realized but XSS can’t be tested because, only administrator can see the working of attack. So, basic XSS testing method- “<script>alert(1)</script>” – can not be used to test this kind of XSS vulnerabilities.

This attack will be very critical because XSS attack will be performed against the administrator.

Exploiting Phase

To perform the attack, you must fill the HTTP_REFERER and USER-AGENT with the attack payload and wait for HTTP/DNS/etc requests.

Sure that advanced payloads can be developed with many filter bypassing abilities and etc.The one thing must be done is to wait for administrators to check his site’s referrers or user-agents.

Thanks & Credits

Thanks Bedirhan Urgun for DNS-channel javascript payload.

Web Application Security Consortium web uygulaması güvenliği ile alakalı zafiyet istatistiklerini derleyip yayınlamış.

Bu gibi çalışmaların esas itibariyle raporu derleyen firmaların reklamları dışında pek kimseye faydası yokmuş gibi görünse de, web uygulaması güvenliği konulu tez, sunum vs. lerde kullanılması açısından işe yarayabilir.

Dünkü Web Güvenliği Topluluğu buluşmasında İbrahim Saruhan(sunumunun adresini bulamadim, bulabilen comment atsın) bu konuda keyifli bir sunum yaptı.

Eğer çok sayıda kişinin kullandığı bir Facebook uygulaması sahibiyseniz, uygulamanızı Underground Marketlerde DoS (Denial of Service) hizmeti olarak satmamanız için hiçbir sebep yok. Söz konusu atak ile sizin uygulamanızı kullanan Facebook kullanıcılarını kullanarak hedef alınan domain ‘e çok sayıda istek yaparak DoS atağı gerçekleştirmek mümkün. Problem facebook uygulamalarında iframe ‘ler aracılığı ile DoS kurbanı olacak hedefe istekler yapılabilmesi. Aşağıdaki örnek kod [1], ilgili atağın tek teknik gereksinimi :

Kodun ilk 3 satırı önemli. Koddaki iframe objesinin src parametresi http://victim-host/image1.jpg
adresindeki resim için HTTP isteği gerçekleştiriyor. Bir istek DoS yapmak için yeterli değil, haliyle sonsuz bir döngü içerisinde durmadan hedef domain ‘e HTTP istekleri oluşturacak bir kod lazım ve bunu yazmak da oldukça basit. Burada saldırının teknik tarafı bitiyor, insanların ilgili uygulamayı kullanmalarını bekliyorsunuz ve uygulama çalıştıkça kurbanınızın browser’ı sizin için hedef domain ‘e durmadan istekler yolluyor.

İki bottleneck’e dikkat çekmek gerekirse :

• Atağın tek gereksinimi popüler bir uygulamaya sahip olmak
• Uygulamanın ne yaptığı anlaşılır anlaşılmaz Facebook tarafından silinecektir.

Söz konusu atak vektörü Yunanistan’lı bir grup araştırmacı tarafından geliştirilmiştir. Orjinal makaleye referanslardan erişilebilir.

Sonuçlar

• Diğer sosyal platformlarda da benzer atak vektörleri geliştirilebilir.
• Web2.0 ile beraber popülerleşen istemci tabanlı ataklara bir yenisi daha eklendi ve eklenmeye devam edecek.
• Kayıt olduğunuz uygulamalara dikkat edin, saldırıya alet olabilirsiniz.

Referanslar

1. E. Athanasopoulos, A. Makridakis, S. Antonatos, D. Antoniades, S. Ioannidis, K. G. Anagnostakis2, E. P. Markatos, “Antisocial Networks: Turning a Social Network into a Botnet”, http://i.zdnet.com/blogs/facebotisc08.pdf

Blog yazılımımız değiştiği için RSS feed adresi de değişmiş bulunmaktadır. Eski feed adresimiz artık çalışmamaktadır. Yeni feed’imize subscribe olunuz.