XSS (Cross-Site Scripting) Nedir ve Nasıl Çalışır?
Bir web uygulamasında yorum yazıyor, arama yapıyor veya profil bilgilerinizi güncelliyorsanız, sistemin girdiğiniz veriyi nasıl işlediği doğrudan güvenliğinizle ilgilidir. Örneğin uygulama kullanıcıdan aldığı veriyi doğru şekilde kontrol etmeden sayfaya aktarırsa, tarayıcı bu içeriği beklenmeyen bir kod olarak yorumlar.
Peki XSS saldırıları tam olarak nasıl çalışır?Bu yazıda XSS’in çalışma mantığını, saldırı türlerini, gerçek hayat senaryolarını, yaygın geliştirici hatalarını ve kurumların bu tehdide karşı alabileceği önlemleri inceliyoruz.
XSS(Cross-Site Scripting), web uygulamalarının kullanıcı girdisini güvenli işleyememesinden kaynaklanan; tarayıcıda istenmeyen kod çalıştırmaya olanak tanıyan kritik bir güvenlik açığıdır. Özellikle Stored, Reflected ve DOM-Based olmak üzere üç temel türü vardır.
XSS (Cross-Site Scripting) Nedir?
XSS; bir web uygulamasının kullanıcıdan aldığı veriyi güvenli biçimde işleyememesi ve tarayıcının bu veriyi çalıştırılabilir bir kod olarak çalıştırması sonucunda ortaya çıkan kritik bir güvenlik açığıdır.
Bir web uygulaması kullanıcı girdisini alabilir, veritabanına kaydedebilir ve daha sonra bu içeriği başka kullanıcılara gösterebilir. Ancak, uygulama bu veriyi uygun şekilde filtrelemeden, kodlamadan veya güvenli bir bağlamda işleme almadan sayfaya eklerse, saldırganın hazırladığı içerik uygulamanın normal işleyişinin bir parçası gibi çalışır.
Normalde sistem, kullanıcının girdiği metni ekranda yalnızca yalın metin olarak göstermelidir. Bununla birlikte, güvenlik kontrolleri yetersiz olduğunda tarayıcı, bu içeriği bir bölümünü çalıştırılabilir bir kod ya da doğrudan işleyeceği özel bir metin olarak görür.
XSS Saldırıları Nasıl Çalışır?
Bir web sitesine giriş yaptığınızda, yorum yazdığınızda veya bir arama kutusuna bilgi girdiğinizde tarayıcınızın yalnızca veri görüntülediğini düşünebilirsiniz. Ancak uygulama, kullanıcıdan aldığı veriyi doğru şekilde kontrol etmeden sayfaya aktarıyorsa tarayıcı bu içeriği beklenmeyen bir kod olarak yorumlar.
XSS’in Üç Temel Bileşeni
1. Saldırgan Tarafından Kontrol Edilen İçerik
Saldırganın uygulamadaki bir giriş alanına yerleştirdiği kötü amaçlı içerik.
2. Güvenli İşleyemeyen Web Uygulaması
Girdiyi yeterli güvenlik kontrollerinden geçirmeden sayfaya aktaran uygulama.
3. Bu İçeriği İşleyen Kullanıcı Tarayıcısı
İçeriği uygulamanın güvenilir bir parçası olarak değerlendiren ve işleyen tarayıcı.
İlk olarak saldırgan, uygulamada kullanıcı girdisi kabul eden bir alan arar. Örneğin bu alan bir yorum kutusu, profil bilgisi, arama parametresi, mesajlaşma alanı veya başka bir kullanıcının görebileceği herhangi bir veri alanı olabilir.
Daha sonra uygulama bu girdiyi yeterli güvenlik kontrolünden geçirmeden işlediğinde içeriği ekrana aktarır. Böylece başka bir kullanıcı bu sayfayı ziyaret ettiğinde tarayıcı, içeriği uygulamanın güvenilir bir parçası olarak çalıştırır.
Saldırı Türleri
Kötü amaçlı içeriğin uygulama içinde nasıl işlendiğine göre XSS saldırıları farklı türlere ayrılır.
| Tür | Nasıl Çalışır? | Kalıcılık | Hedef |
|---|---|---|---|
| Stored XSS | Saldırgan zararlı içeriği veritabanına kaydeder, ziyaretçilere sunar | Kalıcı | Sayfayı ziyaret eden tüm kullanıcılar |
| Reflected XSS | Sistem, istek içindeki zararlı içeriği doğrudan yanıtta yansıtır | Geçici | Hazırlanmış bağlantıyı açan kullanıcı |
| DOM-Based XSS | İstemci tarafındaki JS, kullanıcı girdisini güvensiz şekilde DOM’a aktarır | Değişken | İstemci tarafı veri akışını tetikleyen kullanıcı |
Stored XSS (Kalıcı XSS)
Bu tür, saldırganın gönderdiği içeriği uygulamanın veya veritabanının saklamasıyla ortaya çıkar.
Örneğin bir forumdaki yorum alanını düşünelim. Saldırgan, yorum bölümüne özel olarak hazırlanmış bir içerik gönderir. Uygulama bu içeriği filtrelemeden veritabanına kaydeder. Sonuç olarak, başka bir kullanıcı forum sayfasını açtığında tarayıcı kaydedilen bu içeriği sayfada çalıştırır.
Reflected XSS (Yansıtılan XSS)
Buna karşın, Reflected XSS saldırısında uygulama kötü amaçlı içeriği kalıcı olarak saklamaz. Bunun yerine uygulama, kullanıcının gönderdiği isteği işler ve sonucu doğrudan yanıt içerisinde kullanıcıya geri döndürür.
Örneğin bir arama sayfası, kullanıcının gönderdiği arama terimini sonuç sayfasında doğrudan gösteriyor olabilir. Dolayısıyla uygulama bu değeri güvenli biçimde kodlamadan sayfaya eklerse saldırgan, özel olarak hazırlanan bir bağlantı üzerinden kurbanı hedefleyebilir.
DOM-Based XSS
Bu zafiyet, sunucu tarafındaki yanıt üretiminden ziyade istemci tarafında çalışan kodun veriyi güvensiz işlemesinden kaynaklanır.
Özellikle modern web uygulamalarında JavaScript, sayfanın içeriğini dinamik olarak değiştirmek için yoğun biçimde çalışır. Bu yüzden, kullanıcıdan gelen verileri güvenli şekilde işlemeden DOM yapısına aktarırsanız XSS riski doğar. Bu tür saldırılarda sunucunun zararlı içeriği doğrudan oluşturması gerekmez.
XSS(Cross-Site Scripting) Açığı Nasıl Tespit Edilir?
Kısacası XSS tespiti, uygulamanın verileri nasıl aldığı ve işlediğini incelemekle başlar. Özellikle güvenlik testlerinde ekipler yalnızca form alanlarını değil; arama kutularını, URL parametrelerini ve diğer veri kaynaklarını detaylıca inceler.
Giriş Noktalarının Belirlenmesi
İlk olarak güvenlik ekibi, uygulamadaki tüm kullanıcı giriş noktalarını (form alanları, URL parametreleri, cookie değerleri, HTTP header’ları) sistematik olarak listeler.
Veri Akışının İncelenmesi
Ardından ekip, bu verilerin uygulama içinde hangi bileşenlere aktarıldığını ve nasıl çıktıya dönüştüğünü analiz eder.
Bağlam Analizi
Daha sonra güvenlik uzmanları, kullanıcının kontrol ettiği verinin HTML veya JavaScript içinde nasıl çalıştığını değerlendirir.
Etkinin Değerlendirilmesi
Son olarak uzmanlar, test girdilerinin yarattığı gerçek etkiyi analiz eder.
Gerçek Hayat Senaryosu: Yönetici Panelinde XSS
Örnegin bir müşteri destek platformunu ele alalım. Müşteriler, yaşadıkları sorunlarla ilgili destek talebi oluşturabiliyor. Bu talepleri daha sonra destek ekibi yönetim panelinde inceliyor.
Bir saldırgan, destek talebi oluştururken uygulamanın beklemediği bir içerik gönderir. Uygulama ise bu içeriği yeterince denetlemeden veritabanına kaydeder.
Daha sonra bir yetkili bu talebi açtığında, zararlı içerik doğrudan yöneticinin tarayıcısında çalışır.
Saldırının Olası Etkisi
- Saldırgan doğrudan yönetici hesabının parolasını ele geçirmeden işlem yapabilir
- Yöneticinin tarayıcısında yetkili işlemler gerçekleştirmeyi hedeflediğinde
- Oturum bilgilerine erişim, yetkisiz işlem tetikleme ve veri sızdırma gibi sonuçlar doğurur
En Etkili Korunma Yöntemleri
Özellikle XSS riskini azaltmak için tek bir güvenlik kontrolüne güvenmek yerine, çok katmanlı bir savunma mekanizması kurmalısınız. Bunun yanı sıra, kullanıcı girdilerini güvenli işlemek ve çıktıları doğru kodlamak savunmanın temelini oluşturur.
Output Encoding
Kullanıcıdan gelen verileri HTML veya farklı bir bağlamda göstericekseniz, veriyi doğru biçimde kodlamalısınız. Çünkü encoding işlemi her bağlam için aynı şekilde çalışmaz; nitekim HTML, JavaScript ve URL bağlamları farklı güvenlik kuralları gerektirir.
Güvenli Girdi Doğrulama
Girdi doğrulama, uygulamanın beklenen veri biçimini tanımlamasını sağlar. Böylece yalnızca sayısal değer beklenen bir alanda farklı karakterleri reddederek riski azaltırsınız.
Güvenli Framework ve Kütüphane Kullanımı
Modern web geliştirme framework’leri, bir çok durumda kullanıcı girdisini güvenli biçimde işler. Ancak geliştiriciler bu güvenlik mekanizmalarını devre dışı bırakan özellikleri dikkatli kullanmalıdır.
Content Security Policy (CSP)
CSP, tarayıcıda hangi kaynakların çalışacağını belirleyen ek bir katmandır. Doğru yapılandırılmış bir CSP, saldırıların etkisini ciddi oranda azaltır.
Güvenli Cookie Yapılandırması
Oturum çerezlerini güvenli parametrelerle yapılandırmak riskleri azaltır. Özellikle istemci tarafı kodların çerezlere erişimini kısıtlayarak olası saldırıları doğrudan engellersiniz.
Otomatik Araçlar ve Manuel Test Karşılaştırması
Otomatik test araçları, geniş tarama yüzeylerini hızlıca analiz etme avantajı sunar. Ancak bu araçlar iş mantığını kavrama konusunda yetersiz kalabilir. Bu yüzden en etkili yaklaşım, otomatik ve manuel testleri birlikte yürütmektir.
| Özellik | Otomatik Araçlar | Manuel Test |
|---|---|---|
| Hız | Yüksek — geniş yüzeyi kısa sürede tarar | Daha yavaş — derinlemesine analiz gerektirir |
| Kapsam | Geniş — çok sayıda endpoint | Seçici — yüksek riskli alanlara odaklanır |
| Bağlam Anlayışı | Sınırlı — iş mantığını kavrayamaz | Güçlü — kullanıcı rolleri ve akışlar analiz edilir |
| Karmaşık Senaryolar | Zayıf — çok adımlı senaryolarda yetersiz kalabilir | Güçlü — uygulamaya özgü açıklar tespit edilebilir |
| Bulgu Doğrulama | Yanlış pozitif oranı yüksek olabilir | Manuel analiz ile doğrulama yapılır |
XSS Konusunda Sık Yapılan Hatalar
Özellikle XSS güvenliğinde tek bir kontrole güvenmek büyük hatalara yol açabilir. Bu nedenle geliştiricilerin ve test ekiplerinin yaygın yapılan hataları bilmesi gerekir.
⚠ Kullanıcı girdisine güvenmek
Ekipler her girdiyi potansiyel tehdit olarak değerlendirmeli ve doğrulamalıdır.
⚠ Sadece giriş doğrulamasına güvenmek
Girdi doğrulama tek başına yeterli değildir; çıktı kodlama da zorunludur.
⚠ Her yerde aynı filtreyi kullanmak
HTML, JavaScript, CSS ve URL bağlamları farklı kodlama gereksinimleri gerektirir.
⚠ Güvenli framework varsayılanlarını devre dışı bırakmak
Geliştiriciler, framework’lerin varsayılan güvenlik mekanizmalarını bilinçsizce devre dışı bırakmamalıdır.
⚠ Yönetici panellerini test kapsamı dışında bırakmak
Yönetici panelleri, yüksek etkili XSS senaryoları için birincil hedef olabilir.
⚠ WAF’ı tek güvenlik çözümü olarak görmek
WAF önemli bir katman olsa da karmaşık XSS vektörlerine karşı tek başına tüm tehditleri engelleyemez.
⚠ Sadece otomatik tarama yapmak
Otomatik araçlar, iş mantığına bağlı ve uygulamaya özgü XSS açıklarını gözden kaçırabilir.
XSS Neden Düzenli Olarak Test Edilmelidir?
Çünkü web uygulamaları zaman içinde sürekli değişir ve gelişir.
Dolayısıyla daha önce güvenli olan bir sayfa, yeni bir güncelleme sonrası XSS riski barındırabilir.
Tekrar Test Gerektiren Durumlar
- Yeni kullanıcı giriş alanları eklendiğinde
- Yeni yorum veya mesajlaşma özellikleri geliştirildiğinde
- Yönetim panelleri değiştirildiğinde
- Frontend framework veya kütüphaneler güncellendiğinde
- Yeni API endpoint’leri oluşturulduğunda
- Üçüncü taraf entegrasyonlar eklendiğinde
- Kimlik doğrulama ve yetkilendirme akışları değiştirildiğinde
- Büyük çaplı uygulama mimarisi değişiklikleri yapıldığında
Sık Sorulan Sorular
XSS ile SQL Injection arasındaki fark nedir?
SQL Injection doğrudan veritabanı sunucusunu hedef alırken, XSS web uygulamasını kullanan kurbanın tarayıcısında çalışır. Örneğin SQL Injection ile veritabanından hassas veriler sızdırılabilirken, XSS ile kullanıcının oturum çerezleri çalınabilir veya yetkisi dâhilinde işlemler yürütülebilir. Dolayısıyla her iki zafiyet de sistem güvenliğini tehdit etse da hedef aldıkları katmanlar ve çalışma mekanizmaları tamamen birbirinden farklıdır.
XSS yalnızca JavaScript ile mi gerçekleşir?
Çoğu XSS saldırısı JavaScript kodları üzerinden yürütülse de HTML ögeleri ve CSS gibi istemci taraflı farklı yapılar da kullanılabilir.Temel risk, tarayıcının güvenilmeyen içeriği bir kod bileşeni olarak algılayıp çalıştırmasından kaynaklanır.
ORM kullanmak XSS riskini ortadan kaldırır mı?
ORM teknolojileri veritabanı sorgularını güvenli hale getirerek temel olarak SQL Injection saldırılarını engellemeye odaklanır. Buna karşın XSS, veritabanı katmanında değil, verinin ekrana yansıtıldığı istemci tarafında ortaya çıkan bir güvenlik zafiyetidir. Bu nedenle ORM kullanımı XSS riskini tek başına ortadan kaldırır ve ek olarak çıktı kodlama (output encoding) önlemleri alınmalıdır.
XSS açığı her zaman kritik seviyede midir?
Zafiyetin etki seviyesi; uygulamanın mimarisine, işlenen verinin hassasiyetine ve hedeflenen kullanıcının yetki düzeyine göre değişiklik gösterir. Örneğin yetkisiz bir kullanıcı sayfasındaki XSS kısıtlı bir etki üretirken, yönetici panelinde çalışan bir XSS tüm sistemin kontrolüne yol açabilir. Dolayısıyla her XSS açığı aynı doğrudan etkiyi yaratmasa da her durumda kritik bir güvenlik riski olarak değerlendirilmelidir.
WAF XSS saldırılarını tamamen engeller mi?
Web Uygulaması Güvenlik Duvarı (WAF), bilinen zararlı imza ve kalıpları filtreleyerek önemli bir ilk savunma katmanı sunar. Ancak saldırganlar karmaşık kodlama ve filtre atlatma (bypass) teknikleri kullanarak WAF engellerini aşabilir.
XSS yalnızcaHerkese açık web sitelerinde mi görülür?
XSS açıkları yalnızca dış dünyaya açık web sitelerinde değil, kurum içi yerel ağlarda çalışan özel uygulamalarda da görülebilir. Dolayısıyla erişim kısıtlaması ne olursa olsun tüm web yazılımlarının XSS zafiyetlerine karşı taranması ve korunması gerekir.
Sonuc
Özetle XSS, korunma yöntemleri bilinmesine rağmen halen sıkça karşılaştığımız bir zafiyettir.
Bu nedenle kurumların uygulamadaki tüm veri akışlarını düzenli olarak test etmesi gerekir.
Sibertim ile Web Uygulamalarınızı XSS’e Karşı Test Edin
Web uygulamalarınızın XSS ve diğer uygulama güvenlik risklerine karşı mevcut durumunu görmek istiyorsanız, düzenli güvenlik testleri ve sızma testleriyle zafiyetlerinizi saldırganlardan önce tespit edebilirsiniz.
Sibertim, web uygulamalarınızı güvenlik standartları ve gerçek saldırı senaryoları çerçevesinde değerlendirerek tespit edilen riskleri önceliklendirmenize ve güvenlik seviyenizi güçlendirmenize yardımcı olur.