Şu zamanlara kadar çok fazla farkında değildim, lakin durum şöyle ki güncel ve stabil şekilde çalışan, ya da adam gibi çalışan, open source bir web güvenliği tarayıcısı yok!
Web güvenliği tarayıcı derken klasik anlamdaki tarayıcılardan bahsediyorum, fuzzer vs aksiyonları dahil etmiyorum.
Hemen varolan ve şu an aklınıza geçen alternatiflerin üzerinden geçeyim :

• w3af: Web Application Attack and Audit Framework
  

Open source ve web uygulaması güvenliği diyince ilk akla gelen araçlardan biri olabilir, ama stabil olmaktan hala çok uzak . Haricinde discovery plug-inlerinin pek verimsiz çalışıyor, standart bir web crawler'in linkleri takip ederek dandik bir regular expression ile bulabileceği bir çok şeyi kaçırıyor.
Ama açıkçası diğer araçlarla da kıyaslanınca, eğer stabil bir release'ini görebilirsek ticari rakiplerine karşı açık kaynak en kuvvetli alternatif. Geliştirilmeye açık yapısı, modülerliği ve "Metasploit for Web Applications" havası ile oldukça seksi duruyor.

• wapiti :Web Application Security Auditor
  

İlk denemelerimde dehşet bir iyimserlik taşıyordum bu yazılım hakkında da ,ama hem saldırı yeteneği w3af kadar gelişmiş değil hem de zafiyetleri tanımlama yeteneği pek doyurucu değil. Yani çok standart durumlarda bir şeyler bulabilse de, genelde eliniz boş dönüyorsunuz.

• nikto2
  

Şurada kendisine sayıp sövmüşlüğüm bulunmaktadır, ama  üzülerek söylüyorum ki güvenilirliği ve stabilitesi itibariyle hala open source alternatifler arasında en kuvvetli duran araç bu. Yeni nesil web uygulamalarını denetlemede elbette zayıf kalıyor, fakat karşınızda 4-5 yıl öncesinin sistemleri duruyorsa oldukça etkili ! (çaresiz pen-testerin yakarışı)

• Grendel-Scan

Anladığım kadarıyla bu tool daha yeni release edilmiş, henüz yeterince test edemedim ama gözüme çok hantal gözüktü. 512 mb ramli centrino bir laptopta yarıda bıraktığı bir taramanın raporunu 1 saat içerisinde oluşturmasını beklersiniz, ama tıkanıp kalabiliyor.
Yetenekler itibariyle değerlendirecek olursak, help dosyalarından incelediğim kadarıyla Nikto + her türlü girdi manipülasyonu oyunu eklenmiş gibi. Uzun lafın kısası bende artık hafif bir önyargı oluştu bu konuda ve ondan dolayı bu araca da pek güvenemiyorum, bakalım eğer beni şaşırtırsa ilerleyen günlerde detaylı bir şey yazarım.

Ticari web uygulaması güvenliği tarayıcıları bu araçlara göre çok daha yetenekli ve başarılı. Ama gelin görün ki IP sınırlaması olmaksızın satın almak için ciddi miktarlarda para ödemek gerekiyor.

Bunlar haricinde, pen-testing hayatım Mozilla Firefox eklentileri, MITM saldırı proxy'm ve tabii ki fuzzerlar ile idame ediyor.

Yani otomatize zafiyet tarama mekanizmam şu şekilde gerçekleşiyor, genel attack pattern'ları bir dosyada tutuyorum ve  fuzzer'ıma injection noktaları ile bu pattern dosyasını veriyorum ve outputları kontrol ediyorum. Çok fazla manuel efor var gibi görünebilir, netekim orta büyüklükte bir web sitesini ticari bir araçla taramaya kalktığınız zaman yazılım sizin için minimum 10000 http request gerçekleştirip sonuçlarını analiz ederken elle bu kadar işlem yapacak vaktiniz yok. İster istemez kritik noktalarda bu işlemi yapıyorsunuz, haricinde yukarıda sayıp sövdüğüm tarayıcılar , MITM proxy ile  input manipülasyonu ve arada firefox eklentileri ile yaşamaya çalışıyorsunuz.

Polonyalı bir araştırmacı, Nokia S40 serisi telefonlarda uzaktan erişim sağlayan kritik zafiyetler bulmuş. Uzaktan erişim derken kasıt telefon elinizdeyken neler yapabiliyorsanız, hepsini bu zafiyet sayesinde uzaktan da yapabileceğiniz. Yani telefon açabilecek, mesaj gönderebilecek, dosyaları okuyup yazabilecekseniz. Buna SIM karttaki mesajlar ve kontaktlar da dahil.

Açıkçası cep telefonları ile mesaj çekmekten öte münasebeti olmayan benim için bir önem arzetmese de kullananların haberi olsun. Ayrıca cep telefonlarında güvenlik zafiyetleri aslında uzun süredir var, ama galiba artık biraz daha ciddi bir hava oluşuyor bu konuda.

Araştırmacının bir takım demeçleri ve haberin detayları için şuradan devam edebilirsiniz.

Bildiğimiz üzere Rusya ile Gürcistan arasında geçtiğimiz günler içerisinde savaş çıktı. Anlaşılan savaş gerçek hayatla sınırlı kalmayıp, sanal ortama da sıçramış ve iki ülke arasında sanal savaş da başlamış. Rus saldırganlar Gürcistan sitelerine karşı  DDoS saldırılarına başlamışlar.
İki ülkeden birinden hosting alıyorsanız, özellikle Gürcistan'dan - verilerinizi acilen yedeklemeniz tavsiye olunur, aksi takdirde önümüzdeki günlerde datalarınızın akibetinin ne olacağı bilinmez .

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

Web uygulaması güvenliği işi yapıyorsanız, hayatınız belli bir bölümü firefox ve eklentileri ile geçiyor demektir.
Bundan dolayı pen-testleri kolaylaştıracak etrafta bir yığın add-on var, ben de bir tanesinden bahsedeyim dedim. Benim en severek kullandığım addonlardan birisidir HackBar .Kısaca XSS ve SQLi denemelerinizi kolaylaştırıyor. Sadece QueryString değil, POST ve Referer'i de manipüle edebiliyorsunuz.

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.

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

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!

Bir iki yıl kadar önce www.phpguvenligi.org adresinde Türkiye'nin en iyi PHP güvenliği sitesi host edilirdi, daha sonra ne olduysa oldu ve bir süre yayından kalktı.
Şimdi forum şeklinde açılmış, eski yazılar foruma eklenmiş. Hayırlı olsun.

PHP Güvenliği ile bir şekilde ilgiliyseniz, site ilginizi çekecektir. Hep formda kalmaları dileğiyle..

Aslında eski filmler olsalar da, ben anca seyredebildim. Haftasonu itibariyle bir oturuşta ikisini de izledim.

Operation Takedown (aslında bir ton teknik saçmalık ihtiva etmesine rağmen) biraz daha teknik olarak iyi ve hacker motivasyonunu daha iyi yansıtmış. Swordfish ise daha çok heyecan, gerilim,aksiyon filmi olmuş. Hacker'lik muessesesi sadece biraz daha heyecan katmış olaya.

Bildiğim kadarıyla Kevin Mitnick ile film yapımcılarının arası pek iyi değil, ve yasal sınırlamalar belli bir yıl sonra ortadan kalkınca "The Untold Story of Kevin Mitnick" isimli bir kitap yazıp yaşadıklarını anlatacakmış.

Bu arada Swordfish filminde , film başında tutuklanıp sorguda faili meçhule giden hacker'ın adının Axl Torvalds olması ve Finni olması dikkatimi çekti. Linus Torvalds'a bir gönderme mi var diye düşünsem de Linus'un underground bir olayını duymamıştım, muhtemelen "ilgili ya da ilgisiz bilgisayar dunyasi ile ilgili her şeyi kullanmalıyız" mantığı ile böyle bir şey yapmışlar, tesadüf olduğunu düşünmüyorum.

Son olarak eklemem gerekir ki filmdeki bir sahnede gülmekten yerlere yattım.DoD'un hacklendiği, 60 snlik garip sahne sonrası konuşma :
 
Gabriel :How did you do it?
Stanley   :Look, I don't know what exactly, just see the code in my head. I can't explain.
 

Bugün webappsec@securityfocus.com'da Michal Zalewski Ratproxy'yi duyurdu. Ratproxy, temelinde bir http proxy uygulaması olmasına karşın genel itibariyle üzerinden geçen trafiği inceleyip farkettiği web uygulaması güvenliği zafiyetlerini raporluyor.

Yazılımın en güzel özelliklerinden biri, command line'dan çalıştırdıktan sonra tamamen hand-free biçimde analiz yapması. Yani siz uygulama üzerinde kafanıza göre geziyor, linklere tıklıyorsunuz, o arka planda rastladığı problemleri log dosyasına yazıyor

Yazılımın hand-free olmayan tek yanı, test edilecek uygulamayi elle crawl etmeniz durumu. wget ya da başka bir crawler'a proxy olarak ratproxy'i gosterip çalıştırmak muhakkak bu süreci otomatize etmek adına akıllara gelecektir, ama manuel'deki nota göre bu aksiyonun pek bir faydası yok. Eminim faydası olsa bu yazılımın üzerine bir crawler eklenir ve web application security scanner olarak önümüze gelirdi.

Yaptığı test ve incelemeleri manuel'denn copy paste yapmak istemiyorum ama XSS, XSRF, javascript problemleri, mime-type, redirection ve daha çok client tabanlı ataklar. Testler itibariyle piyasadaki tool'lardan biraz daha yeni.
Yani uygulamanın tutup da tüm zafiyetleri ortaya çıkarmaktan çok, web 2.0 tehditleri üzerinde durmuşlar. Bundan dolayı deli gibi trafiğe ve dolayısıyla crawler'a, fuzzer'a ya da başka bir kaba kuvvet aracına ihtiyacınız yok.

Haricinde mükemmel bir rapor tasarımı yapmışlar. Netekim /tools dizinimin favorilerinden biri olacağı kesin.

Tüm dökümantasyona ve koda bu adresten ulaşılabilir.