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.