XSS (Cross-Site Scripting) Nedir? Nasıl Engellenir?

Bir yorum kutusuna yazılan tek satırlık kod, ziyaretçilerinizin oturum bilgilerini bir saldırganın eline geçirebilir. XSS, web uygulamalarında yıllardır en sık karşılaşılan açık türlerinden biridir ve büyük kısmı birkaç doğru alışkanlıkla önlenebilir.

**Xss cross site scripting nedir nasıl engellenir**

XSS (Cross-Site Scripting), saldırganın bir web sayfasına zararlı JavaScript kodu yerleştirmesi ve bu kodun başka kullanıcıların tarayıcısında çalışmasıdır. Önlemenin temeli, kullanıcıdan gelen veriyi asla güvenilir saymamak, çıktıda bağlama uygun şekilde kodlamak (encoding) ve tarayıcıya ek güvenlik politikaları bildirmektir.

XSS nasıl çalışır?

Tarayıcı, bir sayfadaki betiğin siteden mi yoksa saldırgandan mı geldiğini ayırt edemez. Uygulama kullanıcı girdisini filtrelemeden sayfaya yazdığında, o girdi içindeki <script> gibi ifadeler sitenin kendi kodu gibi çalıştırılır. Betik, sitenin yetkileriyle çalıştığı için çerezleri okuyabilir, sayfa içeriğini değiştirebilir veya kullanıcı adına istek gönderebilir.

Basit bir örnek: arama sayfanız, aranan kelimeyi "… için sonuçlar" şeklinde ekrana yazıyor olsun. Kelime yerine betik içeren bir bağlantı hazırlanıp bir kullanıcıya gönderilirse, kullanıcı bağlantıya tıkladığında betik kendi tarayıcısında çalışır.

XSS türleri

Üç ana tür vardır ve savunma yöntemi türe göre küçük farklılıklar gösterir.

Depolanan XSS genellikle en tehlikelidir. Çünkü tek bir kayıt, sayfayı açan her ziyaretçiyi etkileyebilir ve kurbanın özel bir bağlantıya tıklamasına gerek kalmaz.

XSS saldırısı ne gibi zararlar verir?

Başarılı bir saldırının sonuçları, açığın bulunduğu sayfanın yetkisine bağlıdır. Yönetim paneliyle ilgili bir açık, sıradan bir ziyaretçi sayfasındakinden çok daha ciddi sonuçlar doğurur.

• Oturum çalma: Çerezler veya oturum belirteçleri saldırgana iletilebilir.
• Sahte arayüz: Sayfaya sahte bir giriş formu eklenip kullanıcı bilgileri toplanabilir.
• İstek taklidi: Kullanıcı adına şifre değiştirme, gönderi paylaşma gibi işlemler yapılabilir.
• Yönlendirme ve zararlı yazılım: Ziyaretçiler başka bir adrese yönlendirilebilir.
• İtibar kaybı: Sitenizde görünen istenmeyen içerik güveni zedeler.

Bilgi: XSS, sunucuya değil sitenizin ziyaretçilerine yönelir. Sunucunuz güvenli olsa bile uygulama kodundaki bir açık kullanıcılarınızı riske atabilir.

XSS nasıl engellenir?

Tek bir önlem yetmez; katmanlı savunma gerekir. Aşağıdaki adımlar, uygulamada en çok fark yaratan sıralamayla verilmiştir.

1. Çıktıyı bağlama göre kodlayın. HTML gövdesi, HTML öznitelikleri, JavaScript ve URL için kodlama kuralları farklıdır. Veriyi yazdığınız yere uygun kodlamayı kullanın.
2. Girdiyi doğrulayın. Beklenen formatı (sayı, e-posta, belirli uzunluk) tanımlayın ve uymayanı reddedin. Doğrulama tek başına yeterli değildir, kodlamanın yerini almaz.
3. Güvenli şablon motorlarını kullanın. Modern çerçeveler (React, Angular, Vue ve Django/Laravel şablonları) varsayılan olarak çıktıyı kodlar. Bu korumayı dangerouslySetInnerHTML, v-html veya |safe gibi yapılarla devre dışı bırakmaktan kaçının.
4. DOM işlemlerinde güvenli API seçin. innerHTML yerine textContent kullanın. eval() ve document.write() gibi yöntemlerden uzak durun.
5. HTML içeriğine izin veriyorsanız temizleyin. Zengin metin editörleri gibi durumlarda, kanıtlanmış bir HTML temizleme (sanitization) kütüphanesi kullanın. Kendi düzenli ifadelerinizle filtre yazmaya çalışmayın.
6. Çerezleri koruyun. HttpOnly, Secure ve SameSite bayraklarını kullanın. Bu, XSS çalışsa bile oturum çerezinin JavaScript ile okunmasını engeller.
7. Content Security Policy (CSP) uygulayın. Hangi kaynaklardan betik yüklenebileceğini tarayıcıya bildirin.

Content Security Policy ile ek katman

CSP, bir HTTP yanıt başlığıdır ve tarayıcıya hangi betiklerin çalışabileceğini söyler. Doğru yapılandırıldığında, enjekte edilmiş satır içi betiklerin çalışmasını büyük ölçüde engeller.

Örnek bir başlık:

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-RASTGELE_DEGER'; object-src 'none'; base-uri 'self'

İpucu: CSP'yi doğrudan zorunlu hâle getirmeden önce Content-Security-Policy-Report-Only başlığıyla deneyin. Böylece mevcut sayfalarınızın neyi bozacağını görür, politikayı kademeli sıkılaştırırsınız. unsafe-inline ifadesini politikaya eklemek, korumanın büyük bölümünü ortadan kaldırır.

Bağlama göre kodlama örnekleri

Aynı veri, yazıldığı yere göre farklı kodlanmalıdır. Tablo, sık yapılan hataları gösterir.

XSS açığı nasıl test edilir?

Geliştirme sürecinde açıkları erken yakalamak, yayına çıktıktan sonra düzeltmekten çok daha ucuzdur. Yalnızca kendi sistemlerinizi veya yazılı izin aldığınız uygulamaları test edin.

• Form alanlarına, URL parametrelerine ve başlıklara zararsız test dizeleri girerek çıktının nasıl işlendiğine bakın.
• Kod incelemesinde innerHTML, eval ve kodlama devre dışı bırakılan şablon yapılarını arayın.
• Otomatik güvenlik tarayıcıları ve bağımlılık denetim araçlarını CI/CD sürecine ekleyin.
• Tarayıcı geliştirici araçlarında CSP ihlal raporlarını izleyin.
• Düzenli aralıklarla bağımsız bir sızma testi yaptırın.

Sunucu ve hosting tarafında alınabilecek önlemler

XSS'nin asıl çözümü uygulama kodundadır; ancak altyapı katmanı ek koruma sağlar. Hosting ortamınızda şunlara dikkat edin:

• Güvenlik başlıklarını (CSP, X-Content-Type-Options, Referrer-Policy) sunucu veya uygulama düzeyinde tanımlayın.
• Web sitenizi her zaman HTTPS üzerinden sunun; Secure çerez bayrağı bunu gerektirir.
• CMS, eklenti ve tema güncellemelerini zamanında yapın. WordPress gibi sistemlerde XSS açıklarının önemli kısmı güncel olmayan eklentilerden gelir.
• Mümkünse bir web uygulama güvenlik duvarı (WAF) kullanın. WAF, bilinen saldırı kalıplarını engeller; ancak kod düzeltmesinin yerine geçmez.
• Yönetim paneline erişimi kısıtlayın ve iki aşamalı doğrulama kullanın.

Netlen İnternet Hizmetleri gibi sunucu, web hosting ve alan adı hizmeti sunan sağlayıcılarda SSL sertifikası, sunucu yapılandırması ve güncel yazılım sürümleri gibi altyapı konularında teknik destek alabilirsiniz. Uygulama içindeki açıkların giderilmesi ise yine geliştirici sorumluluğundadır.

Sık yapılan hatalar

Deneyimlerde tekrar eden birkaç yanlış yaklaşım var:

• Kara liste filtreleri: <script> kelimesini silmek yeterli değildir; olay işleyicileri (onerror, onload) ve farklı kodlamalarla filtre aşılabilir.
• Yalnızca istemci tarafı doğrulama: Tarayıcıdaki kontrol, doğrudan istek gönderen saldırgan için engel değildir.
• Girişte kodlayıp çıkışta unutmak: Veriyi kayıt sırasında kodlamak, farklı bağlamlarda yanlış sonuç verir. Kodlama çıktı anında yapılmalıdır.
• Üçüncü taraf betiklere körü körüne güvenmek: Harici betikler de sitenizde çalışır; kaynaklarını sınırlayın ve mümkünse Subresource Integrity (SRI) kullanın.

Uyarı: XSS ile ilgili test ve araştırmaları yalnızca sahibi olduğunuz veya yazılı izin aldığınız sistemlerde yapın. İzinsiz deneme yasal sorumluluk doğurur.

Sık Sorulan Sorular

XSS ile SQL Injection arasındaki fark nedir?

XSS, zararlı kodun kullanıcının tarayıcısında çalışmasına yol açar ve ziyaretçileri hedef alır. SQL Injection ise veritabanı sorgularına müdahale eder ve sunucu tarafındaki veriyi hedefler. İkisinin de kökeni kullanıcı girdisinin güvensiz işlenmesidir, ancak savunma yöntemleri farklıdır.

HttpOnly çerez bayrağı XSS'yi tamamen engeller mi?

Hayır. HttpOnly, JavaScript'in çerezi okumasını engeller ve oturum çalmayı zorlaştırır. Ancak saldırgan betik yine de sayfayı değiştirebilir, kullanıcı adına istek gönderebilir veya sahte form gösterebilir. Bu nedenle çıktı kodlaması ve CSP ile birlikte kullanılmalıdır.

WordPress sitem XSS saldırısına karşı nasıl korunur?

Çekirdek, tema ve eklentileri güncel tutun, kullanmadığınız eklentileri kaldırın ve güvenilir kaynaklardan indirin. Kullanıcı rollerini sınırlayın, yönetim hesaplarında iki aşamalı doğrulama kullanın. Ek olarak güvenlik başlıklarını yapılandırmak ve bir WAF kullanmak riski azaltır.

Modern JavaScript çerçeveleri XSS'ye karşı güvenli mi?

Varsayılan kullanımda büyük ölçüde korur, çünkü değişkenleri otomatik olarak kodlarlar. Ancak dangerouslySetInnerHTML, v-html gibi ham HTML basan özellikleri kullandığınızda bu koruma devre dışı kalır. Bu durumlarda içeriği mutlaka bir temizleme kütüphanesinden geçirin.

XSS açığı bulursam ne yapmalıyım?

Kendi sitenizde buldıysanız önce ilgili girdiyi geçici olarak kapatın, ardından çıktı kodlamasını düzeltin ve CSP ekleyin. Kullanıcı verisinin etkilenmiş olabileceğini düşünüyorsanız oturumları sıfırlayın ve gerekirse kullanıcıları bilgilendirin. Başka bir sitede bulduysanız, site sahibine sorumlu bir şekilde bildirin.

HTTPS kullanmak XSS'yi önler mi?

Hayır. HTTPS, verinin iletim sırasında şifrelenmesini sağlar; ancak uygulamanın kullanıcı girdisini nasıl işlediğini değiştirmez. XSS açığı olan bir site HTTPS üzerinden de savunmasız kalır. Yine de HTTPS, Secure çerez bayrağı ve genel güvenlik için gereklidir.