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.

Şekilde de görüldüğü üzere içinden çıkılmaz ve anlaşılmaz bir şekilde herşeyin “As A Service” olduğu bir yöne doğru hızla ilerliyoruz. Teknolojiye yabancı olanlar için kısaca özetlemek gerekirse ihtiyacınız olan yazılıma satın almadan kiralama usulü ile sahip olma. Fakat yanılmalar olmasın bu kiralama Microsoft’un lisans kiralama mantığında değil bir subscription mantığında yapılıyor ve genellikle ihtiyacınız olan yazılıma bulut üzerinden erişiyorsunuz. Zaten en büyük avantajlarda böyle başlıyor.

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.

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.

Haftalık olarak yayınlanan ve güvenlik dünyasındaki gelişmeleri aktaran Lifeoverip Güvenlik Bülteni’nin 2. sayısı yayınlanmış. Şiddetle tavsiye edilir.