.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.

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

AVANTAJLARI

• İhtiyacınız olan ürünü satın almadığınız ve kiraladığınız için fiyatlar düşüyor.
  
• Birçok vendor yıllık,6 aylık,3 aylık ve aylık gibi sürelerde subscription sağladığı için istediğiniz zaman iptal edebiliyor ve paranızı kurtarabiliyorsunuz.
  
• Aynı ürünün normal lisanslı versiyonunu aldığınızda muhtemel ihtiyacınız olan yazılımın kallaviyetine göre sunucu ve Windows tabanlı olduğunu düşünürsek bir de Windows Server lisansı eklenecektir.
  
• Ürünü üretici firmanın sunucularından kullandığınız için tüm kurulum ve bakım işlemlerini üretici firma ekibi gerçekleştiriyor,böylece siz bu iş içinde bir kaynak harcamamış oluyorsunuz.
  

DEZAVANTAJLARI

• Genel anlamda çok bir dezavantajı bulunmamasına rağmen bazı yazılımlar ve bazı kurumlar için pek efektif çözümler olmayabiliyor.
  
• Yönetimsel anlamda eğer çok ince detaylar arıyorsanız muhtemelen ürünün standart lisanslı versiyonuna göre daha az kurcalayacak özellik ve daha az raporlama bulabilirsiniz.
  

Hizmet Olarak Güvenlik

Teknolojiyi biraz tandığımıza göre güvenlik sektöründe bize neler getirir neler götürür biraz bakalım.

Geleceğin bu yönde gittiğini gören bazı güvenlik firmaları yaklaşık 2-3 senedir bu alanda çözüm üretiyorlar ve gün geçtikçe hizmet sayılarını arttırıyorlar. Bu konuda biraz daha temkinli davranan diğer güvenlik firmalarıda bugünlerde gelişimlerini tamamlayıp hizmetlerini sunmaya başladılar. Aslına bakarsanız bu konuda haksızda sayılmazlar çünkü güvenlik ürünleri kullanan kurumlar tüm dünyada bu konuda pekte bilinçli değil. Ama tabii ki bu konuda suçta onlarda değil. Ülkemizde bu teknolojinin gizlenme noktalarına kadar ulaştığını söyleyebilirim. Nedenide basit siz X firması olarak url filtering ürünü satıyorsanız ve bulunduğunuz dönemde firmanız bu ürünü birde servis olarak vermeye başladığında bunu aktif olarak yıllardır url filtering ürününüzü kullanan müşteriye anlatmak satış anlamında biraz zor oluyor. Çünkü bu müşteri için her yıl verdiğinden en azından %50 daha az ücret ödemek anlamına geliyor bu durumda siz firma olarakta %50 daha az ücret alıyorsunuz anlamına geliyor. Şunuda sektördeki herkes bilirki ürünün fiyatı artıkça satışın kar oranıda artar.

Bu nedenden dolayı müşteriler bu konudan bihaber oluyor. Fakat buna rağmen araştırmayı seven it yöneticileri yada ekibi olan kurumlar bu teknolojileri en azından denemek istiyor.

Güvenlik sektöründe bildiğim kadarıyla verilen hizmetler;

Web Content Filtering(Url Filtering,Content Filtering,Malware Protection)

Mail Content Filtering(Anti-Spam Protection,Malware Protection)

Anti-Malware

Bunları sağlayan bazı firmalar içerideki pclere iletişim için minik birer agent kurarken bazılarıda agent olmadan çalışabiliyor. Genelde Web Content Filtering çözümlerinin uygulanması,siz hizmete kayıt olduğunuzda size verilen size özel bir proxy adresini proxy ayarlarına girmeniz ile sağlanıyor. Mail Content Filtreleme sistemide mx kaydınızın yine servisi sağlayan firma tarafından size verilen bir sunucuya yönlendirilmesi ile sağlanıyor. Anti-Malware içinde bildiğim kadarıyla agentless bir yapı henüz sağlanabilmiş değil ve firma sunucuları ile iletişime geçecek bir client ihtiyacı duyuluyor. Eminimki buna yakın zamanda daha pratik bir çözüm getireceklerdir en azından active-x kullanan daha hafif bir agent ile işler hallolabilir. Bu konuda güvenlik firmalarıda oldukça tecrübesizler aslında nedenide birçoğunun bu hizmet ürünlerini sadece bu işi yapan emektar firmaları satın alarak sağladıkları ve bu yüzden kendileri ile gerçek anlamda henüz entegre edememeleri. Örnek olarak Symantec bu konuda belki de en iyi olan MessageLabs firmasını satın aldı fakat mail çözümleri konusunda alt yapıda henüz Symantec’in kaliteli Anti-Spam çözümü Brightmail kullanılmıyor ve MessageLabs’in kendi alt yapısı kullanılıyor. Tabii ki bunlar gün geçtikçe entegre olarak daha sağlam yapılarda duracaklar. Bu arada aklıma gelmişken güvenlik tarafında bu tür çözümlerin bir artısıda dünya üzerinde başlayan örneğin bir spam saldırısının hem bulut üzerinde networkünüze bulaşmadan engellenmesi hemde bu tür ani güncellemelerden en önce faydalanabiliyor olmanız.

Sonuç olarak dünyanın belki çok yeni bir teknoloji olarak görmesine ve birçok kişininde pek güvenmediği bu hizmetlerin önümüzdeki yakın günlerde çok daha fazla revaçta olacağı açıkça ortada. Bu aslında tam da Microsoft’un geçtiğimiz yıllarda başlattığı Live konseptiyle uyumlu. İnternet hızlarının tüm dünya üzerinde belirli bir seviyeye ulaştığınıda kabul edersek,(Ülkemizde bile ) yakında internet üzerinden işletim sistemimizi kullanıyor olacağımız gerçeğide git gide yaklaşıyor ve güvenlik sektörü olarakta bundan nasibimizi sonuna kadar alacağımızı düşünüyorum.

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

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.

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.

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