H-Security Labs - WUG - SYH category

WUG-SYH #3 : Zayıf Oturum Yönetimi

Mon, 18 Aug 2008 09:59:11 GMT

Web uygulaması güvenliğindeki problemlerin hepsi zayıf girdi denetimi sebebiyle oluşmaz. Bir çok zafiyetin sebebi "bussiness logic" de denilen, aslında mantıksal hatalardan kaynaklı zafiyetlerdir.

Peki Bunlar Nelerdir?
Benim en çok karşılaştıklarım uygulamanın tasarım problemi içerdiği ve dolayısıyla kimlik doğrulama problemleri içeren durumlar. Yani atıyorum e-mail servisi veren bir web uygulamasının sil.php?mID=324 parametresi ile 324. maili silme isteği gönderen kişinin gerçekten o mailin sahibi mi, yoksa başkası mı olduğunun kontrolünün yapılmadığı durum. Aslında çok basit bir şeymiş gibi görünse de bir çok web uygulamasında bu tip mantıksal problemler var.

Başka bir örnek ise yine e-posta servisimizdeki mail gönderme örneği olabilir. Diyelim ki mailinizi yazıyorsunuz, daha sonra yolla butonuna basınca şu şekilde bir HTTP isteği oluşuyor.
http://xxxx.com/mail/yolla.php?alici=hasan&yollayan=ahmet&mesaj=...

Burada muhtemelen yolla.php biraz daha modüler olsun diye alici ve yollayan parametresi dışarıdan alınıyor. Bu durumda sunucu tarafında gerekli kontroller yapılmıyorsa -her türlü HTTP isteğinin içindeki parametrelerin manipüle edilebileceğini ilk yazımızda gündeme getirmiştik- yollayan parametresi değiştirilip bir başka kişiden küfür dolu maili herhangi birisine yollayabilme durumunuz mevcut.

Peki Çözüm?
Bu durumda aslında sunucu tarafında doğru kontroller yapılabilir gibi duruyorsa da bence asıl yapılması gereken uygulama mantığını değiştirmek. Zira kullanıcı için, o ana özel şekilde değişmeyen her şey veritabanından alınmalı, gerekmiyorsa kullanıcıya sorulmamalıdır.
Netekim elimizde uygulamaya giriş yapmış kullanıcının cookie'si var, bu insanin kim olduğunu biliyorsak yolla.php sayfasına bu adamın adını yollamak pek mantıklı değildir. Bunun yerine yapılması gereken yolla.php içerisinde kullanıcının cookie'sine bakarak veritabanından ilgisi ismi çekmek olmalıdır. Bu arada unutmadan ekleyelim, cookie, sesion gibi bilgiler de manipüle edilebilir, ama bir kullanıcı diğerinin session bilgisini bilmesi doğal olarak mantıklı değildir, biliyorsa ortada session fixation gibi bir gariplik var demektir ve bu apayri bir zafiyettir.

Unutulmaması gereken bir şey vardır ki, kullanıcıdan alınan bilgiler her zaman web uygulaması güvenliği için ölümcül değere sahiptir. Kullanıcıdan alınan her türlü bilgi için iki defa düşünülmesi gerekmekte, gerekmiyorsa hem mantıksal anlamda bir hata yapmamak hem de çeşitli input oyunlarına gelmemek için, kullanıcıdan veri alınmamalıdır.

WUG-SYH #2 : Kara Listeleme

Sun, 10 Aug 2008 09:27:52 GMT

Web uygulamalarında en sık karşılaştığım problemlerden, problem olmasa da yanlış pratiklerden, birisi de blacklisting (kara listeleme) mantığıdır.

Teori & Laf Salatası
Blacklisting dediğimiz olayın pratiğini günlük hayatta pek çok yerde görebiliriz. Örneğin markete giderken genellikle ihtiyaçlarımızın listesini daha önceden bir kağıda yazmamız ve markette sadece bu ürünleri alıp çıkmamız tavsiye edilir. Sebebi ise açıktır, marketteki bir ton ürünü görüp ihtiyacımız olmasa bile almayı engellemek içindir.
Web uygulaması güvenliğinde de olay tam olarak böyle olmasa bile buna yakındır. Kullanıcıdan alınan girdinin, tanımladığımız doğru girdi tanımı ile birebir örtüşmesi gerekir. Bunun dışında kalan durumları ise tamamen reddetmeliyiz. Bu mantığa kısaca whitelisting deniyor.
Kötü pratik olarak geçen şey ise ; önümüzdeki bir market dolusu maldan işimize yaramayanların bir kısmını listeleyip geri kalanların hepsini almaya benziyor. Pratik olarak işinize yaramayacak olanların hepsini listelemeniz pek mümkün değil, düşünmediğiniz bir ton case çıkacak ve sonunda ister istemez işinize yaramayacak bir ton şeyi satın almış olacaksınız.
Bu olumlu ama yetersiz yaklaşıma ise blacklisting deniyor. Nitekim gelen kötü inputların hepsini ayıklayamadığınız için her türlü girdi manipülasyonu oyununa karşı korumasız kalıyorsunuz.

Gerçek Hayat İmplementasyonları
Bir çok web uygulamasında alınan parametrenin filtrelenmesi aşamasında blacklisting yapıldığını görüyorum.
Örneğin karşımda bir arama scripti var, "foo" katarını aratıyorum ve karşıma

'foo' aratıldı dönen sonuçlar :

şeklinde bir sonuç sayfası dönüyor.
Bu noktada ilk akla gelen şüphesiz ki SQL Injection ve XSS. Ben burada örneğe XSS üzerinden devam edeceğim.
Burada XSS testi yapmak isteyenler hemen en genel XSS payload'u olan <script>alert(1)</script> gibi bir şeyi deneyecektir. Dönen sonuç sayfası :

'alert(1)' aratıldı dönen sonuçlar :

Hissedeceğiniz üzere arka planda çalışan kodda <script> tag'i filtreleniyor. Yani karşı tarafta bir kara liste var, ve gönderdiğiniz input kara listede varsa filtrelenecek, yoksa sessiz sedasız atağınızı gerçekleştireceksiniz.
Ortalama bir saldırganın bu noktada deneyeceği şey :

<image src="" on error="alert(/XSS/)>

olacaktır. Bu noktada kara listenizde image tagı bulunmuyorsa atak yine başarıyla gerçekleşecek. <p> tagında bile XSS yapılabiliyorken kara listeleme mantığı tamamen zayıf ve yetersiz kalmaktadır.

Peki Çözüm Nedir ?
Görüldüğü üzere her türlü blacklisting filtresini geçmenin bir yolu bulunabilir. Çözüm ise gayet açık, yazının daha başında bahsettiğim whitelisting bakış açısı. Yani sadece olması gerektiği gibi girdiyi tanımlayıp, bu tanımla örtüşenleri kabul edip, gerisini reddetmek.

Ekstra Okuma & Referans
Cross Site Scripting Blacklist Protection
Unusual XSS Vectors

WUG-SYH #1 : Javascript ile Girdi Denetimi

Sat, 02 Aug 2008 15:37:35 GMT

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 üç sebebi olabilir.

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

Ş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

Web Uygulaması Güvenliğinde Sıkça Yapılan Hatalar

Sat, 02 Aug 2008 15:23:27 GMT

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!