16: XSS (Cross Site Scripting)

• En ciddi etkiyi 2006 yılında yapmaya başladı. "Yeni buffer overflow artık XSS"
• Tanımı: İstemci tarafında html/dhtml/css veya javascript kodunun izinsiz olarak kurbanın tarayısında çalıştırılması. Sunucudaki açıklık kullanılarak kurbanın browser'ına saldırılıyor.
• 3 çeşidi var:
• Reflected XSS
• En çok görülen XSS türüdür.
• Senaryo: Saldırgan, sunucudaki açıklığı kullanacak bir link oluşturur. Linki kullanıcıya gönderir ve kullanıcıyı o linki kullanarak uygulamaya girmeye ikna eder. Kullanıcı linke tıklar, sunucu da isteğe uygun web sayfası içeriği hazırlayıp kullanıcıya yollar. Bu cevapta saldırganın hazırladığı URL nedeniyle kötü amaçlı yapısal değişiklikler vardır. Kullanıcının tarayıcısında dönen sayfa çalıştığında yetkisiz kod çalıştırılmış olur.
• Kullandığımız zayıflık sunucunun açıklığı fakat hedefimiz kullanıcının tarayıcısı. Saldırgan, zehirli URL'ini kullanarak kurbana sunucuyu zehirlettiriyor; daha sonra kurban uygulamanın veritabanından zehirli bölgeye erişince kendisi zehirleniyor.
• Burada kullanıcıyı ikna etmek session fixation'a göre daha kolay, çünkü domain olarak kullanıcı doğru domain'i görür, şüphelenmez.
• Stored XSS
• Saldırgan sunucuda bir açıklık görür ve bir istek gönderir. O istek sunucuda saklanır (store).
• Hiç kimseyi ikna etme gereksinimi yok, kullanıcı kendisi geliyor uygulamaya. Misal, gazetelerin yorum sayfaları. Browserda sayfa görüntülendiğinde script çalıştırılmış oluyor.
• Reflected XSS'e göre daha etkili, çünkü
• Kimseyi ikna etme derdi yok.
• Bir kere yükledikten sonra herkes etkileniyor.
• DOM-based XSS
• Bir denetlemeye gittiğimiz zaman şunu mutlaka sormalıyız: Birilerinin input girdiği, diğerlerinin bu inputu okuduğu bir arayüz var mı? Mesajlaşma vs.
• Bilinen ilk XSS wormu: 2005 yılında MySpace sosyal paylaşım sistemini etkileyen SamyJSWorm. Samy, profiline (sevdiği kitaplar benzeri bir alana) javascript yazıp gönderiyor. Bakıyor ki veritabanına kaydedildi, profil geri geldiğinde Samy'nin sayfasına, o script çalışıyor. Samy, profiline browserda çalıştığında (profiline baktığı anda bakan kişinin tarayıcısında) kendisini arkadaş olarak ekleyen bir kod gömüyor. Script aynı zamanda kendisini profili açan kişinin profiline de kopyalıyor ki solucan dağılsın. 24 saat içinde Samy'nin 1 milyonun üzerinde arkadaşı oluyor.
• Stored XSS'i önlemenin 3 yöntemi var:
• Black List: Keyword'leri yasaklamak. Bu yanlış bir çözüm, kesinlikle bu yöntem kullanılmamalı.
• Input alanında sadece girilmesi gereken karakterlere izin ver. [a..zA..0..9][.,] gibi. Yada sayısal bir alana sadece 0..9 ve . karakterlerine izin vermek gibi.
• O alana karakter encoding kodunu da, HTML taglerini de, javascript taglerini de koymak istiyoruz. Bu durumda da 2 yöntem var:
• Sayfayı kullanıcıdan aldıktan sonra HTML encode'dan geçiririz. Mesela < işaretini &lt'ye çeviririz, browser onu tag starter olarak yorumlamaz. Ama bu yeterli değil, link içindeyse karakter URL encode, javascript ile gönderiyorsa javascript encode... developer bunu bilip o encode'u uygulaması lazım.
• Sadece temiz HTML kabul eden API'ler çıktı. Örnek: HTML Prufier (PHP), OWASP Anti-Samy API'si (Java muhtemelen).
• Neden olduğu problemler:
• Bilgi hırsızlığı: Session bilgisi (cookie) çalınabilir, clipboarddaki veri çalınabilir (IE7'den itibaren bir başkasının clipboard bilgisini almak istediği konusunda browser uyarıyor)
• İçerik değişikliği (Defacement)
• Geçmiş tarama, port tarama
• Dahili IP çalma, Web Spidering, XSS Botnet
• Açıklık tarma, Worm.
• Whitehat Security 2009 istatistiği: test edilen sistemlerde bulunan açıklıkların %65'i XSS açıklığı. Büyük çoğunluğu reflected XSS.
• XSS ile zombie bilgisayarlar (botnet) oluşturmak için bir uygulama: http://www.bindshell.net'ten erişilebilecek BeEF uygulaması.
• Stored XSS-Manuel test teknikleri:
• Input alanına "Hello<qwe>" girelim, sonuç stringinde <qwe> görülmezse ve fakat sayfanın source'unda <qwe> bir HTML tag gibi görülüyorsa stored XSS açıklığı var demektir.
• Input alanına <plaintext> girilir. Bu HTML tag'i bundan sonrası düz bir texttir demektedir; bundan sonra gelen tüm HTML tagleri artık HTML değil de string olarak algılanır ve sayfayı o şekilde basılır. Input alanına bunu girdiğimizde sayfanın kalanı bozulursa XSS açıklığı var demektir. Yalnız canlı sistemlerde bunu kullanmamak lazım, açıklık varsa sayfayı bozmuş oluruz.
• Bak: XSS Cheat Sheet; ha.ckers.org/xss.html. Bir sürü XSS test tekniği mevcut.
• XSS konusunda en popüler cheatsheet dokümanı yöneten Rsnake (Robert Hansen), sayfasında “XSS Locator” olarak adlandırdığı bir test dizgisi barındırmaktadır. Bu dizgi test  sayfasında “XSS Locator” olarak adlandırdığı bir test dizgisi barındırmaktadır. Bu dizgi test edilecek her parametrenin değeri olarak eşitlenir ve tarayıcıda bir javascript alert kutucuğu görülürse uygulamada ilgili parametre XSS zafiyetinin olduğu anlaşılır. 
• RSnake tarafından yazılmış http://ha.ckers.org/xss.html adresindeki tüm kalıpları bir otomatik tarayıcı kullanması gerekir.
• alert() metodu, IDS (Intrusion Detection System) sistemleri tarafından yakalanıyor genelde. Bunun yerine prompt() kullanabiliriz; bu metodu bazen kaçırabiliyorlar.