XSS Nedir XSS Açıkları Nasıl Bulunur?
Sizlere bu konumuzda internet ortamında toplayıp ve derlediğimiz XSS üzerine detaylıca konuyu anlatmaya çalışacağız. Anlayacağınız dilden bu anlatımı yapmaya çalışırken yinede aklınıza takılan soruları yorum bölümünden bildirebilirsiniz.
 |
| XSS - Temel Bilgiler |
XSS Nedir?
XSS, herkesin bildiği ve sıklıkla karşılaştığı önemli bir güvenlik açığıdır. Owasp Top 10’de bulunur. XSS saldırıları çok yaygın olmamasına rağmen, XSS açığı çoğu sistemde bulunur. Bizde bu konumuzda bu açığın nerelerde ortaya çıktığını, çeşitlerinin neler olduğunu, nasıl exploit edildiğini, nasıl korunmamız gerektiğini ve daha bir çok detaylarıyla konuya detaylıca giriş yapalım. Öncelikle bilmeniz gereken önemli bir husus, bu açığın manuel (yani elle) olarak bulunmasından bahsedeceğiz. Hazır araçlardan bahsetmeyeceğiz özetle ve sadece Burp Suite kullanacağız. Örneğin, zaten Beef gibi frameworkler hakkında bir çok konu mevcut olduğu için konuyu daha fazla uzatmadan başlangıcı yapalım başlayalım.
Cross Site Scripting
Adım adım başlangıcı yapalım sizlere. Şimdi sizler için bu konumuzda, cross-site scripting’in ne olduğunu, cross-site scripting güvenlik açıklarının farklı çeşitlerini ve cross-site scripting açığı ve önleme yöntemlerini açıklayalım.
Cross-Site Scripting (XSS) nedir?
Cross-site scripting (XSS olarak da bilinir), bir saldırganın kullanıcıların savunmasız bir uygulamayla olan etkileşimlerini tehlikeye atmasına izin veren bir web güvenlik açığıdır. Cross-site scripting güvenlik açığı normalde bir saldırganın mağdur kullanıcı olarak maskelenmesine, kullanıcının gerçekleştirebileceği tüm eylemleri gerçekleştirmesine ve kullanıcının verilerine erişmesine izin verir. Mağdur kullanıcının uygulama içinde ayrıcalıklı erişimi varsa, saldırgan uygulamanın tüm fonksiyonları ve verileri üzerinde tam kontrol sahibi olabilir.
Vikipedi kaynağını ekleyerek XSS Nedir açıklmasını yapacak olursak;
Siteler arası betik çalıştırma (İngilizce: Cross-Site Scripting, kısaca XSS), genellikle web uygulamalarında bulunan bir tür bilgisayar güvenlik açıklığıdır. XSS, diğer kullanıcılar tarafından görüntülenen web sayfalarına istemci taraflı kodun 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 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. 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.
XSS nasıl çalışır?
Cross-site scripting; herhangi bir web sitesinde kullanıcıdan alınan inputun (yani girdi) filtrelenmeden doğrudan tekrar ekrana basılmasıyla oluşur, filtre olmadığı için biz bu alanda istediğimiz doğrultuda javascript kodları çalıştırarak kurbanı dilediğimiz şekilde yönlendirme imkanına sahip olacağız.
XSS Saldırılarının Türleri Nelerdir?
Üç ana XSS saldırısı türü vardır:
- Reflected XSS: Kötü amaçlı script’in geçerli HTTP isteğinden gelir.
- Stored XSS: Kötü amaçlı script’in web sitesinin veri tabanından gelir.
- DOM-based XSS: Güvenlik açığı sunucu tarafında bulunmak yerine istemci tarafında bulunur.
Reflected XSS:
Bu kısımda, reflected cross-site scripting’in ne olduğunu, reflected XSS saldırılarının etkisini ve reflected XSS güvenlik açıklarının nasıl bulunacağını açıklayalım.
Reflected Cross-Site Scripting Nedir?
Reflected XSS: Kullanıcının girilmesi beklenen parametre yerine Javascript kodu girerek bunu ekrana yansıtması ile tespit edilebilen XSS çeşitidir. Daha açık ifadeyle Reflected cross-site scripting (veya XSS), bir uygulama bir HTTP isteğinde veri aldığında ve bu verileri güvenli olmayan bir şekilde anında yanıt içine dahil ettiğinde ortaya çıkar.
Bir web sitesinde, kullanıcı tarafından sağlanan arama terimini, bir URL parametresinde yer alan bir arama fonksiyonu olduğunu varsayalım:
Örnek: akblog.net/search?term=gift
Uygulama, bu URL‘ye yanıt olarak, aradığımız terimi terimini verir:
<p> You searched for: gift</p>
Uygulamanın verilerin başka bir işlemini gerçekleştirmediğini varsayarsak, bir saldırgan aşağıdaki gibi bir saldırı oluşturabilir:
Örnek: https://www.akblog.net/status?message=<script>/*Bad+stuff+here.
Bu URL aşağıdaki yanıtı verir:
<p> You searched for: <script>/* Bad stuff here.....*/</script></p>
Uygulamanın başka bir kullanıcısı saldırganın URL‘ini isterse, saldırgan tarafından sağlanan script, kurbanın tarayıcısında, uygulama oturumları içeriğinde çalıştırılır.
Örnek web sitesindeki arama kısmında XSS açığını kontrol ediyoruz:
Reflected XSS açığı olduğu için, ekranımıza JavaScript çıktısı veriyor:
Reflected XSS Saldırılarının Etkisi
Bir saldırgan, kurbanın tarayıcısında çalıştırılan bir scripti kontrol edebilirse, o kullanıcının güvenliğini tamamen bozabilir. Ayrıca saldırgan şunları da yapabilir:
Uygulama içinde kullanıcının gerçekleştirebileceği herhangi bir eylem gerçekleştirebilir.Kullanıcının görüntüleyebileceği tüm bilgileri görüntüleyebilir.Kullanıcının değiştirebileceği bilgileri değiştirebilir.İlk kurban kullanıcıdan kaynaklandığı anlaşılan kötü niyetli saldırılar da dahil olmak üzere diğer uygulama kullanıcılarıyla etkileşimleri başlatabilir.
Saldırganın, mağdur kullanıcıyı reflected XSS saldırısı yapmak üzere kontrol etmelerini istemesinin çeşitli yolları vardır. Bunlar arasında, saldırgan tarafından kontrol edilen bir web sitesine veya içeriğin oluşturulmasına izin veren başka bir web sitesine veya bir e-postaya, tweet‘e veya başka bir iletiye bağlantı gönderilmesi de dahildir. Saldırı doğrudan bilinen bir kullanıcıya karşı hedeflenebilir veya uygulamanın herhangi bir kullanıcısına karşı bir saldırı olabilir:
Saldırı için harici bir dağıtım mekanizmasına duyulan ihtiyaç, reflected XSS‘nin etkisinin, korunmasız uygulamanın kendisinde bağımsız bir saldırının gerçekleştirilebileceği stored XSS‘den genellikle daha az şiddetli olduğu anlamına gelir.
Farklı Alanlarda Reflected XSS
Reflected Cross-Site Scripting’in birçok farklı çeşidi vardır. Verilerin uygulamanın yanıtı içindeki konumu, bu veriden yararlanmak için ne tür bir payloadın gerekli olduğunu belirler ve güvenlik açığının etkisini de etkileyebilir.
Buna ek olarak, uygulama gönderilen veriler üzerinde yansıtılmadan önce herhangi bir doğrulama veya başka bir işlem yaparsa, bu genellikle ne tür bir XSS payloadının gerekli olduğunu etkiler.
Reflected XSS Açıklarını Bulma ve Test Etme
Reflected XSS açıklarını manuel test etmek için aşağıdaki adımları takip edebilirsiniz:
Her giriş noktasını test edin. Uygulamanın HTTP isteklerindeki veriler için her giriş noktasını ayrı ayrı test edin. Bu, URL sorgu dizesi ve ileti gövdesi ve URL dosya yolundaki parametreleri veya diğer verileri içerir. Ayrıca HTTP headerlerini de içerir, ancak yalnızca belirli HTTP headerleri aracılığıyla tetiklenebilen XSS benzeri davranışlar pratikte kullanılamayabilir.
Rastgele değerler gönderin. Her giriş noktası için benzersiz bir rastgele değer gönderin ve değerin yanıta yansıtılıp yansıtılmadığını belirleyin. Değer, çoğu giriş doğrulamasından kurtulmak için tasarlanmalıdır, bu nedenle oldukça kısa olması ve yalnızca alfasayısal karakterler içermesi gerekir. Ancak, yanıt içinde kazayla eşleşmeler olmaması için yeterince uzun olması gerekir. Normalde yaklaşık 8 karakterlik rastgele bir değer idealdir. Uygun rastgele değerler oluşturmak için Burp Intruder‘ın “ Number Payloadlarını” rastgele oluşturulmuş onaltılık değerlerle kullanabilirsiniz. Ayrıca, gönderilen değeri içeren yanıtları otomatik olarak işaretlemek için Burp Intruder‘ın “Grep Payloads” seçeneğini kullanabilirsiniz.
Yanıt içeriği belirleyin. Yanıt içindeki rastgele değerin her konum için içeriğini belirleyin. Bu, HTML etiketleri arasında, alıntılanabilecek bir etiket özelliğinde, bir JavaScript dizesinde vb. Olabilir.
Bir aday payloadı test edin. Yanıt içeriğine bağlı olarak, yanıt içinde değiştirilmemiş olarak reflected JavaScript çalıştıırlmasını tetikleyecek ilk aday XSS payloadını test edin. Payloadları test etmenin en kolay yolu, isteği Burp Repeater‘a göndermek, aday payloadı ekleme isteğini değiştirmek, isteği yayınlamak ve daha sonra payloadın çalışıp çalışmadığını görmek için yanıtı gözden geçirmektir. Çalışmanın etkili bir yolu, orijinal rastgele değeri istekte bırakmak ve aday XSS payloadını önce veya sonra yerleştirmektir. Ardından, Burp Repeater‘ın yanıt görünümünde rastgele değeri arama terimi olarak ayarlayın. Burp, arama teriminin göründüğü her yeri vurgulayarak reflected XSS’i hızlı bir şekilde bulmanızı sağlar.
Alternatif payloadları test edin. Aday XSS payloadı uygulama tarafından değiştirildiyse veya tamamen engellendiyse, yanıt içeriğine ve yapılan giriş doğrulama türüne bağlı olarak çalışan bir XSS saldırısı sağlayabilecek alternatif payloadları ve teknikleri test etmeniz gerekecektir. Daha fazla ayrıntı, yazının ilerleyen kısımlarında anlatılacaktır.
Saldırıyı bir tarayıcıda test edin. Son olarak, Burp Repeater‘da çalışıyor gibi görünen bir payload bulmayı başarırsanız, saldırıyı gerçek bir tarayıcıya aktarın (URL‘yi adres çubuğuna yapıştırarak veya Burp Proxy‘nin intersection görünümünde isteği değiştirerek inject edilip edilmediğine bakın. JavaScript gerçekten çalıştırılır. Genellikle, saldırı başarılı olursa tarayıcıda görünür bir açılır pencere tetikleyecek uyarı (document.domain gibi basit bir JavaScript çalıştırmak en iyisidir.
Reflected Croess-Site Scripting Hakkında Sık Sorulan Sorular
Reflected XSS ve Stored XSS arasındaki fark nedir? Reflected XSS, bir uygulama, bir HTTP isteğinden bazı girdiler aldığında ve bu girdiyi güvenli olmayan bir şekilde anında yanıta kattığında ortaya çıkar. Stored XSS ise reflected’ın aksine uygulama bunun yerine girdiyi depolar ve daha sonraki bir yanıta güvenli olmayan bir şekilde ekler.
Reflected XSS ve Self-XSS arasındaki fark nedir? Self-XSS, normal reflected XSS ile benzer uygulama davranışı içerir, ancak hazırlanmış bir URL veya bir cross-domain request yoluyla veya normal yollarla tetiklenemez. Bunun yerine, güvenlik açığı yalnızca kurbanın XSS payloadını tarayıcılarından göndermesi durumunda tetiklenir. Self-XSS saldırısı yapmak, normal olarak kurbanın saldırgan tarafından sağlanan bazı girdileri tarayıcılarına yapıştırması için sosyal olarak mühendislik işlemlerini içerir. Bu nedenle, normalde düşük etkili bir sorun olarak kabul edilir.
Stored XSS
Bu kısımda, Stored Cross-Site Scripting’i, stored XSS saldırılarının etkisini ve stored XSS güvenlik açıklarının nasıl bulunacağını açıklayalım.
Stored Cross-Site Scripting Nedir?
Stored cross-site scripting (ikinci derece veya kalıcı XSS olarak da bilinir), bir uygulama, güvenilir olmayan bir kaynaktan veri aldığında ve bu verileri daha sonraki HTTP yanıtlarına güvenli olmayan bir şekilde eklediğinde ortaya çıkar.
Bir web sitesinin, kullanıcıların diğer kullanıcılara gösterilen blog yayınlarına yorum göndermesine izin verdiğini varsayalım. Kullanıcılar aşağıdaki gibi bir HTTP isteği kullanarak yorum gönderir:
Bu yorum gönderildikten sonra, blog gönderisini ziyaret eden tüm kullanıcılar uygulamandan şu şekilde yanıt alır:
Uygulamanın verilerin başka bir işlemini gerçekleştirmediğini varsayarsak, bir saldırgan aşağıdaki gibi kötü amaçlı bir yorum gönderebilir:
Bu yorum URL olarak şu şekilde kodlanır: Blog gönderisini ziyaret eden tüm kullanıcılar artık uygulamanın yanıtı içinde aşağıdakileri alacaktır:
Saldırgan tarafından sağlanan script, kurbanın tarayıcısında, uygulamayla oturumları içeriğinde çalıştırılır.
Uygulama
Örnek web sitesindeki bir gönderinin altındaki yorum kısmında stored XSS açığı arayalım:
Yorumu gönderince bir şey değişmedi fakat tekrar aynı sayfaya geri döndüğümüzde, JavaScript mesajı ile karşılaşıyoruz:
Stored XSS Saldırılarının Etkisi
Bir saldırgan, kurbanın tarayıcısında çalıştırılan bir scripti kontrol edebilirse, o kullanıcının güvenliğini tamamen bozabilir. Saldırgan, reflected XSS güvenlik açıklarının etkisine uygulanabilecek eylemlerden herhangi birini gerçekleştirebilir.
Kullanılabilirlik açısından, reflected ve stored XSS arasındaki temel fark, stored XSS güvenlik açığının uygulamanın kendisinde bulunan saldırılara izin vermesidir. Saldırganın, diğer kullanıcıları, exploitlerini içeren belirli bir istekte bulunmaya çalışmanın harici bir yolunu bulması gerekmez. Aksine, saldırgan exploitini uygulamanın kendisine yerleştirir ve kullanıcıların onunla karşılaşmasını bekler.
Stored cross-site scripting açıklarının bağımsız yapısı, XSS açığının yalnızca şu anda uygulamada oturum açmış kullanıcıları etkilediği durumlarda geçerlidir. Reflected XSS olursa, saldırı sezgisel olarak zamanlanmalıdır: Saldırganın oturum açmadıkları bir zamanda istekte bulunması için uyarılan bir kullanıcı tehlikeye girmez. Buna karşılık, stored XSS açığı varsa, kullanıcının exploitle karşılaştığı anda oturum açması garanti edilir.
Farklı Alanlarda Stored XSS
Stored cross-site scripting’in birçok farklı çeşidi vardır. Saklanan verilerin uygulamanın yanıtı içindeki konumu, bundan yararlanmak için ne tür bir payloadın gerekli olduğunu belirler ve güvenlik açığının etkisini de etkileyebilir.
Ayrıca, uygulama saklanmadan önce veya saklanan verilerin yanıtlara dahil edildiği noktada veriler üzerinde herhangi bir doğrulama veya başka bir işlem yaparsa, bu genellikle ne tür bir XSS payloadının gerekli olduğunu etkiler.
Stored XSS Güvenlik Açıklarını Bulma ve Test Etme
Not: Birçok stored XSS güvenlik açığı, Burp Suite‘in web güvenlik açığı tarayıcısı gibi araçlar kullanılarak bulunabilir.
Stored XSS güvenlik açıklarını manuel olarak test etmek zor olabilir. Saldırgan tarafından kontrol edilebilen verilerin uygulamanın işlenmesine girebileceği tüm ilgili "giriş noktalarını" ve bu verilerin uygulamanın yanıtlarında görünebileceği tüm "çıkış noktalarını" test etmeniz gerekir.
Uygulamada giriş noktaları şunları içerir:
URL sorgu dizesi ve ileti gövdesi içindeki parametreler veya diğer veriler.
URL dosya yolu.
Reflected XSS ile ilgili olarak yararlanılamayabilecek HTTP istek başlıkları.
Bir saldırganın uygulamaya veri iletebildiği bant dışı yollar vardır. Bu yollar tamamen uygulama tarafından uygulanan işlevselliğe bağlıdır: bir web postası uygulaması e-postalarda alınan verileri işleyecektir; Twitter özet akışını görüntüleyen bir uygulama, üçüncü taraf tweet‘lerinde bulunan verileri işleyebilir; bir haber toplayıcı diğer web sitelerindeki verileri de içerecektir.
Stored XSS saldırılarının çıkış noktaları, her durumda her türlü uygulama kullanıcısına döndürülen olası HTTP yanıtlarıdır.
Stored XSS güvenlik açıklarını test etmenin ilk adımı, bir giriş noktasına gönderilen verilerin bir çıkış noktasından yayıldığı giriş ve çıkış noktaları arasındaki bağlantıları bulmaktır. Bunun zor olabilmesinin nedenleri:
Herhangi bir giriş noktasına gönderilen veriler prensip olarak herhangi bir çıkış noktasından gönderilebilir. Örneğin, kullanıcı tarafından sağlanan görünen adlar, yalnızca bazı uygulama kullanıcıları tarafından görülebilen belirsiz bir denetim günlüğünde görünebilir.
Şu anda uygulama tarafından depolanan verilerin, uygulama içinde gerçekleştirilen diğer eylemler nedeniyle genellikle üzerine yazılmasına açıktır. Örneğin, bir arama fonksiyonu, kullanıcılar başka aramalar yaparken hızla değiştirilen son aramaların bir listesini görüntüleyebilir.
Giriş ve çıkış noktaları arasındaki bağlantıları kapsamlı bir şekilde tanımlamak, her bir permütasyonu ayrı ayrı test etmeyi, giriş noktasına belirli bir değer göndermeyi, doğrudan çıkış noktasına gitmeyi ve değerin orada görünüp görünmeyeceğini belirlemeyi içerir. Ancak, bu yaklaşım birkaç sayfadan fazla olan bir uygulamada pratik değildir.
Bunun yerine, daha gerçekçi bir yaklaşım, veri giriş noktalarında sistematik olarak çalışmak, her birine belirli bir değer göndermek ve gönderilen değerin göründüğü durumları tespit etmek için uygulamanın yanıtlarını izlemek. Blog yazılarındaki yorumlar gibi ilgili uygulama fonksiyonlarına özellikle dikkat edilebilir. Gönderilen değer bir yanıtta gözlendiğinde, verilerin hemen yanıtta yansıtılmasının aksine, verilerin gerçekten farklı istekler arasında depolanıp depolanmadığını belirlemeniz gerekir.
Uygulamanın işlenmesinde giriş ve çıkış noktaları arasında bağlantılar belirlediğinizde, stored XSS güvenlik açığının olup olmadığını belirlemek için her bağlantının özel olarak sınanması gerekir. Bu, saklanan verilerin göründüğü yanıt içindeki içeriğin belirlenmesini ve bu bağlam için geçerli olan uygun aday XSS payloadının test edilmesini içerir. Bu noktada, test metodolojisi reflected XSS güvenlik açıklarını bulmakla büyük ölçüde aynıdır.
DOM-Based XSS
Bu kısımda, DOM-based cross-site scripting’i, DOM-based XSS güvenlik açıklarını nasıl, DOM-based XSS‘i farklı kaynak ve sink’lerle nasıl kullanılacağını açıklayacağım ve DOM XSS güvenlik açıklarının reflected ve stored biçimlerini açıklayacağım.
DOM-based XSS, bir HTML parçasında değil DOM (Document Object Model)’da meydana gelen XSS açığıdır. Stored ve Reflected XSS saldırılarında, saldırı sonrası dönen sayfada XSS atağını görmek mümkünken; DOM tabanlı XSS saldırılarında HTML kaynağı ve dönen yanıt, tamamen aynı olacaktır.
DOM-Based Cross-Site Scripting Nedir?
DOM-based XSS (DOM XSS olarak da bilinir), bir uygulama güvenilir olmayan bir kaynaktan gelen verileri genellikle DOM içindeki potansiyel olarak tehlikeli bir sink’e yazarak güvenli olmayan bir şekilde işleyen bazı istemci tarafı JavaScript içerdiğinde ortaya çıkar.
Kaynak (Source) , saldırganın kontrol edebileceği verileri içeren bir JavaScript özelliğidir. Kaynağa örnek olarak, sorgu dizesinden girdi okuyan “location.search” verilebilir.
Sink, JavaScript kodunun çalıştırılmasına veya HTML oluşturulmasına izin veren bir fonksiyon veya DOM nesnesidir. Kod çalıştırma sink’inin bir örneği “eval” ve HTML havuzunun bir örneği ise “document.body.innerHTML”dir.
Bir XSS saldırısı yapmak için, verileri bir kaynağa yerleştirmeniz gerekir, böylece bir sink’e yayılır ve zorunlu olmayan JavaScript‘in çalıştırılmasına neden olur.
DOM-Based Cross-Site Scripting Nasıl Test Edilir ?
DOM-based cross-site script’i manuel olarak test etmek için genellikle Chrome gibi geliştirici araçlarına sahip bir tarayıcı kullanmanız gerekir. Mevcut her bir kaynak üzerinde sırayla çalışmanız ve her birini ayrı ayrı test etmeniz gerekir.
HTML Sink’lerini Test Etme
HTML havuzunda DOM XSS‘i test etmek için, kaynağa (location.search gibi) rastgele değerler yerleştirin, ardından HTML‘i incelemek ve girilen değerlerin nerede göründüğünü bulmak için geliştirici araçlarını kullanın. Tarayıcının "Kaynağı görüntüle" ifadesinin, HTML‘de JavaScript tarafından gerçekleştirilen değişiklikleri dikkate almadığı için DOM XSS testi için çalışmayacağını unutmayın. Chrome‘un geliştirici araçlarında, DOM‘de dizenizi aramak için Control + F (veya MacOS‘da Command + F) kullanabilirsiniz.
Girdiğiniz değerin DOM içinde göründüğü her konum için içeriğini tanımlamanız gerekir. Daha sonra bu içeriğe göre, nasıl işlendiğini görmek için girdinizi hassaslaştırmanız gerekir. Örneğin, girdiğiniz değerler çift tırnak içinde görünüyorsa, çift tırnak içinden çıkıp çıkamayacağınızı görmek için girdinize çift tırnak eklemeyi deneyin.
Tarayıcıların URL kodlaması, Chrome, Firefox ve Safari ile ilgili olarak farklı davrandığını unutmayın. Verileriniz işlenmeden önce URL kodlamalıysa, bir XSS saldırısının çalışması mümkün değildir.
JavaScript Çalıştırma Sink’lerini Test Etme
DOM-based XSS için JavaScript çalıştırma sink’lerini test etmek biraz daha zordur. Bu sink’lerde, girdiniz DOM içinde hiçbir yerde görünmez, bu yüzden onu arayamazsınız. Bunun yerine, girişinizin bir havuza gönderilip gönderilmediğini ve nasıl gönderileceğini belirlemek için JavaScript hata ayıklayıcısını kullanmanız gerekir.
Konum gibi her potansiyel kaynak için, önce sayfanın JavaScript kodunda kaynağa referansta bulunulan olayları bulmanız gerekir. Chrome‘un geliştirici araçlarında, sayfanın tüm JavaScript kodunu kaynak için aramak için Control + Shift + F (veya MacOS‘ta Command + Alt + F) tuşlarını kullanabilirsiniz.
Kaynağın nerede okunduğunu bulduğunuzda, bir kırılma noktası eklemek ve kaynağın değerinin nasıl kullanıldığını takip etmek için JavaScript hata ayıklayıcısını kullanabilirsiniz. Kaynağın diğer değişkenlere atandığını görebilirsiniz ve daha sonra bir sink’e ulaşıncaya kadar bu değişkenleri izlemeniz gerekir. Bir sink’e aktarılıp aktarılmadığını görmek için bu değişkenleri izlemek için arama fonksiyonunu tekrar kullanabilirsiniz. Kaynaktan veri atanmış bir sink bulduğunuzda, sink’e gönderilmeden önce değerini göstermek için değişkenin üzerine gelip değeri incelemek için hata ayıklayıcıyı kullanabilirsiniz. Ardından, HTML sink’lerinde olduğu gibi, başarılı bir XSS saldırısı yapıp yapamayacağınızı görmek için girişinizi hassaslaştırmanız gerekir.
DOM XSS‘yi Farklı Kaynak ve Sink’lerde Kullanma
Prensipte, verilerin kaynaktan kaynağa yayılabileceği çalıştırılabilir bir yol varsa, bir uygulama DOM-based cross-site scripting’e karşı savunmasızdır. Uygulamada, farklı kaynaklar ve sink’ler, exploit edilebilirliği etkileyebilecek ve hangi tekniklerin gerekli olduğunu belirleyebilecek farklı özelliklere ve davranışlara sahiptir. Ayrıca, uygulamanın script’i bir güvenlik açığını exploit etme sırasında barındırılması gereken verilerin doğrulanmasını veya başka işlemlerini gerçekleştirebilir. DOM-based güvenlik açıklarıyla ilgili çeşitli kaynaklar ve sink’ler vardır.
“document.write” sink’i, script öğeleriyle çalışır, böylece aşağıdaki gibi basit bir payload kullanabilirsiniz.
Uygulama
Örnek bir web sitesinde arama kısmına rastgele değerler giriyoruz:
Ardından bu kutunun kaynak kodunu inceliyoruz:
Kaynak kodunda “img” değerinin kullanıldığını gördüm. Bunu bypass etmek için ise şu şekilde arama yapıyoruz:
Ardından JavaScript mesajı karşımıza geliyor.
Bununla birlikte, bazı durumlarda “document.write” öğesine yazılan içeriğin, exploitimizde dikkate almanız gereken bir bağlam içerdiğini unutmayın. Örneğin, JavaScript payloadınızı kullanmadan önce mevcut bazı öğeleri kapatmanız gerekebilir.
Uygulama
Örnek sitemizdeki ürünlerde bir adet “Stoğu Kontrol Et” butonu var:
Bu kısmın kaynak kodunu inceliyoruz:
Kaynak kodundan anlıyoruz ki, yazacağımız payloadı öncelikle “select” fonksiyonu ile kapatmamız lazım. Bir de URL kısmına bakalım:
Bu kısma, şu şekilde bir payload yazabiliriz:
Ardından ekrana JavaScript mesajını verecektir:
“innerHTML” havuzu herhangi bir modern tarayıcıda script öğelerini kabul etmez ve yükleme olaylarını tetiklemez. Bu, “img” veya “iframe” gibi alternatif öğeler kullanmanız gerektiği anlamına gelir. “onload” ve “onerror” gibi olay işleyicileri bu öğelerle birlikte kullanılabilir. Örneğin:
Uygulama
Örnek web sitemizde yine bir arama kısmı var. Buraya şu şekilde payloadımızı ekliyoruz:
Ardından arama yaptığımızda JavaScript mesajını ekrana veriyor:
JQuery gibi bir JavaScript kitaplığı kullanılıyorsa, sayfadaki DOM öğelerini değiştirebilecek havuzlara bakın. Örneğin, jQuery‘deki “attr” fonksiyonu DOM öğelerindeki öznitelikleri (attribute) değiştirebilir. Veriler, URL gibi kullanıcı tarafından kontrol edilen bir kaynaktan okunur ve ardından “attr” fonksiyonuna iletilirse, XSS‘ye neden olmak için gönderilen değeri değiştirmek mümkün olabilir. Örneğin, burada bir bağlantı elemanının “href” özelliğini URL‘deki verileri kullanarak değiştiren bazı JavaScript‘lerimiz var:
URL‘i “/B]location.search” kaynağının kötü amaçlı bir JavaScript URL‘i içerecek şekilde değiştirerek bundan yararlanabilirsiniz. Sayfanın JavaScript‘i bu kötü amaçlı URL‘yi arka bağlantının “href‘”ine uyguladıktan sonra, back link’e tıklamak onu çalıştırır:
Uygulama
Örnek sitemizde bir geri bildirim formu var. Bu form sayfasının URL adresini inceleyelim
Formun altında bulunan “back” butonunu tıkladığımızda, URL’de görüldüğü gibi bizi ana sayfaya yollayacak:
URL’de, “/” dizini yerine herhangi bir değer yazalım ve enter’a basalım:
Ardından “back” butonuna tıklayıp ne olduğuna bakalım:
Sayfaya böyle bir yazı geliyor. Demek ki burada bir XSS payloadı yazabiliriz:
URL kısmını bu şekilde değiştirip enter’a basıp ardından da “back” butonuna tıkladığımızda, JavaScript mesajı karşımıza geliyor:
AngularJS gibi bir framework kullanılırsa, JavaScript‘i açılı parantezler veya eventler olmadan çalıştırmak mümkün olabilir. Bir sitedeki HTML öğesinde “ng-app” özelliğini kullandığında, AngularJS tarafından işlenir. Bu durumda AngularJS, JavaScript‘i doğrudan HTML‘de veya özniteliklerde (attribute) ortaya çıkabilen çift süslü parantezler içinde çalıştırılır.
Uygulama
Yine örnek web sitemizde bir adet arama butonu var:
Bu butonu kullanarak arama yapıp, çıkan sayfanın kaynak kodunu inceleyim:
Kaynak kodunda “ng-app” kısmı dikkatimizi çekiyor. Yani AngularJS kullanılıyor. Biz de AngularJS kodu ekleyebiliriz:
Bu şekilde bir payload yazıp aradığımızda, JavaScript mesajını ekrana veriyor:
DOM ve Reflected Verilerle Birleştirilmiş DOM XSS
Bazı saf DOM-based güvenlik açıkları tek bir sayfada bulunur. Bir script URL‘deki bazı verileri okur ve tehlikeli bir sink’e yazarsa, güvenlik açığının tamamı bu sayfada bulunur.
Diğer durumlarda, güvenlik açığı, istemci tarafı script’i tarafından güvenli olmayan bir şekilde işlenen girişin sunucu tarafından yanıtlanmasını veya depolanmasını içerir:
Reflected + DOM güvenlik açığında, sunucu tarafı uygulaması istekteki verileri işler ve verileri yanıta yansıtır. Yansıtılan veriler bir JavaScript dizesi hazır bilgisine veya DOM içindeki form alanı gibi bir veri öğesine yerleştirilebilir. Daha sonra sayfadaki bir script, yansıtılan verileri güvenli olmayan bir şekilde işler ve sonuçta tehlikeli bir sink’e yazar.
Stored + DOM güvenlik açığında, sunucu tarafı uygulaması bir istekten veri alır, depolar ve daha sonra verilere daha sonraki bir yanıta ekler. Daha sonraki yanıttaki bir script, verileri güvenli olmayan bir şekilde işler.
XSS Ne İçin Kullanılabilir?
Cross-site scripting güvenlik açığından yararlanan bir saldırgan genellikle şunları yapabilir:
Mağdur kullanıcı olarak kimliğe bürünmek veya maskelenmek.
Kullanıcının gerçekleştirebileceği tüm işlemleri gerçekleştirmek.
Kullanıcının erişebildiği tüm verileri okumak
Kullanıcının oturum açma kimlik bilgilerini yakalamak.
Web sitesini ele geçirmek.
Web sitesine trojan saklamak.
XSS Güvenlik Açıklarının Etkisi
Bir XSS saldırısının gerçek etkisi genellikle uygulamanın doğasına, işlevselliğine ve verilerine ve güvenliği ihlal edilmiş kullanıcının durumuna bağlıdır. Örneğin:
Tüm kullanıcıların anonim olduğu ve tüm bilgilerin herkese açık olduğu bir broşür uygulamasında, etki genellikle minimum düzeyde olacaktır.
Bankacılık işlemleri, e-postalar veya sağlık kayıtları gibi hassas veriler içeren bir uygulamada, etki genellikle ciddi olacaktır.
Güvenliği ihlal edilen kullanıcı uygulama içinde ayrıcalıklara sahipse, etki genellikle kritik öneme sahip olur ve saldırganın güvenlik açığı olan uygulamanın tam kontrolünü ele geçirmesine ve tüm kullanıcıların ve verilerinden ödün vermesine izin verir.
XSS Güvenlik Açıklarını Bulma ve Test Etme
XSS güvenlik açıklarının büyük çoğunluğu Burp Suite‘in web güvenlik açığı tarayıcısı gibi araçlar kullanılarak hızlı ve güvenilir bir şekilde bulunabilir.
Reflected ve Stored XSS için manuel olarak test yapılması normalde uygulamanın her giriş noktasına bazı basit girdilerin (kısa bir değer gibi) gönderilmesini içerir; HTTP yanıtlarında gönderilen girdinin döndürüldüğü her yeri tanımlama; ve rastgele JavaScript çalıştırmak için uygun şekilde hazırlanmış girdinin kullanılıp kullanılamayacağını belirlemek için her bir konumu ayrı ayrı test edilmesi gerekir.
URL parametrelerinden kaynaklanan DOM-Based XSS’i manuel olarak test etmek benzer bir işlemi içerir: parametreye basit bir benzersiz giriş yerleştirmek, bu giriş için DOM‘da arama yapmak için tarayıcının geliştirici araçlarını kullanmak ve bu konumun sömürülebilir olup olmadığını belirlemek için her konumu test etmek gerekir. Ancak, diğer DOM XSS türlerinin algılanması daha zordur. URL tabanlı olmayan girişlerde (document. cookie gibi) veya HTML tabanlı olmayan sink’lerde (setTimeout gibi) DOM-based güvenlik açıklarını bulmak için JavaScript kodunu incelemek için çok zaman harcayamaya gerek yoktur. Burp Suite‘in web güvenlik açığı tarayıcısı, DOM-based güvenlik açıklarının algılanmasını güvenilir bir şekilde otomatikleştirmek için statik ve dinamik JavaScript analizini birleştirir.
İçerik Güvenliği Politikası (Content Security Policy)
İçerik güvenliği politikası (CSP), cross-site scripting ve diğer bazı güvenlik açıklarının etkisini azaltmayı amaçlayan bir tarayıcı mekanizmasıdır. CSP kullanan bir uygulama XSS benzeri davranış içeriyorsa, CSP bu güvenlik açığından yararlanılmasını engelleyebilir veya önleyebilir. Genellikle, CSP, altta yatan güvenlik açığından yararlanılmasını sağlamak için atlatılabilir. (Yazının devamında, detaylıca anlatacağım.)
Dangling Markup Injection
Dangling markup injection, giriş filtreleri veya diğer savunmalar nedeniyle tam bir cross-site scripting’in mümkün olmadığı durumlarda cross-domain dataları yakalamak için kullanılabilecek bir tekniktir. Kullanıcı adına yetkisiz eylemler gerçekleştirmek için kullanılabilen CSRF belirteçleri de dahil olmak üzere diğer kullanıcılar tarafından görülebilen hassas bilgileri yakalamak için sıklıkla kullanılabilir.(Yazının devamında, detaylıca anlatacağım.)
XSS Saldırıları Nasıl Önlenir
Cross-site scripting’i önlemek bazı durumlarda önemsizdir, ancak uygulamanın karmaşıklığına ve kullanıcı tarafından denetlenebilir verileri işleme yöntemlerine bağlı olarak çok daha zor olabilir.
Genel olarak, XSS güvenlik açıklarının etkili bir şekilde önlenmesi için, aşağıdaki önlemlerin bir kombinasyonu uygulanır:
Varışta filtre girişi. Kullanıcı girişinin alındığı noktada, beklenen veya geçerli girdiye göre olabildiğince kesin bir şekilde filtreleyin.
Çıktıdaki verileri kodlayın. Kullanıcı tarafından kontrol edilebilen verilerin HTTP yanıtlarında çıktığı noktada, çıkışı aktif bağlam olarak yorumlanmasını önlemek için kodlayın. Çıktı içeriğine bağlı olarak, HTML, URL, JavaScript ve CSS kodlama kombinasyonlarının uygulanmasını gerektirebilir.
Uygun yanıt başlıklarını kullanın. HTML veya JavaScript içermesi amaçlanmayan HTTP yanıtlarında XSS‘i önlemek için, tarayıcıların yanıtları istediğiniz şekilde yorumladığından emin olmak için “İçerik Türü Seçenekler” başlıklarını kullanabilirsiniz.
İçerik Güvenliği Politikası. Son savunma hattı olarak, hala meydana gelen XSS güvenlik açıklarının önem derecesini azaltmak için İçerik Güvenliği İlkesi‘ni (CSP) kullanabilirsiniz. (Yazının devamında, detaylıca anlatacağım.
Cross-Site Scripting Hakkında Sık Sorulan Sorular
XSS güvenlik açıkları ne kadar yaygındır? XSS güvenlik açıkları çok yaygındır ve XSS muhtemelen en sık karşılaşılan web güvenlik açığıdır.
XSS saldırıları ne kadar yaygındır? Gerçek dünyadaki XSS saldırıları hakkında güvenilir veri elde etmek zordur, ancak muhtemelen diğer güvenlik açıklarından daha az kullanılır.
XSS ve CSRF arasındaki fark nedir? XSS, bir web sitesinin kötü amaçlı JavaScript döndürmesine neden olurken, CSRF kurbanı bir kullanıcının yapmak istemedikleri eylemleri gerçekleştirmeye teşvik etmesini içerir.
XSS ve SQL injection arasındaki fark nedir? XSS, diğer uygulama kullanıcılarını hedef alan bir istemci taraflı güvenlik açığı iken SQL injection, uygulamanın veri tabanını hedefleyen bir sunucu taraflı güvenlik açığıdır.
PHP‘de XSS‘i nasıl önleyebilirim? Girişlerinizi izin verilen karakterlerin beyaz listesiyle filtreleyin ve yazımla ilgili ipuçları yazın . HTML bağlamları için “htmlentities” ve “ENT_QUOTES” veya JavaScript için JavaScript Unicode çıkışlarını kullanın.
Java‘da XSS‘i nasıl önleyebilirim? Girdilerinizi izin verilen karakterlerin beyaz listesiyle filtreleyin ve çıktınızı HTML bağlamları için HTML kodlamak üzere Google Guava gibi bir kitaplık kullanın veya JavaScript bağlamları için JavaScript Unicode çıkışlarını kullanın.
Açılı parantezleri kodlayan, ancak yine de öznitelikleri (attribute) inject etmenize izin veren web siteleriyle karşılaşabilirsiniz. Bazen, bu injection’lar, kanonik bir etiket gibi, etkinlikleri otomatik olarak tetiklemeyen etiketler içinde bile mümkündür. Chrome‘daki erişim anahtarlarını ve kullanıcı etkileşimini kullanarak bu davranıştan yararlanabilirsiniz. Erişim tuşları, belirli bir öğeye başvuran klavye kısayollarını sağlamanıza olanak tanır. “accesskey” attribute, diğer tuşlarla birlikte basıldığında (bunlar farklı platformlarda farklılık gösterir) olayların tetiklenmesine neden olacak bir harf tanımlamanızı sağlar.
XSS içeriği bir JavaScript template literal’e girdiğinde, değişmez değeri sonlandırmaya gerek yoktur. Bunun yerine, hazır bilgi işlendiğinde çalıştırılacak bir JavaScript ifadesini gömmek için “$ {...}” sözdizimini kullanmanız yeterlidir. Örneğin, XSS içeriği aşağıdaki gibi ise:
Bu durumda template hazır bilgisini sonlandırmadan JavaScript‘i çalıştırmak için aşağıdaki payloadı kullanabilirsiniz:
Content Security Policy (İçerik Güvenliği Politikası)
Bu kısımda, İçerik Güvenliği Politikasının (Content Security Policy) ne olduğunu ve bazı yaygın saldırılara karşı CSP‘nin nasıl kullanılabileceğini açıklayacağım.
CSP (içerik Güvenliği Politikası) Nedir?
CSP, XSS ve diğer bazı saldırıları azaltmayı amaçlayan bir tarayıcı güvenlik mekanizmasıdır. Bir sayfanın yükleyebileceği kaynakları (script ve resimler gibi) ve bir sayfanın diğer sayfalar tarafından framelenip framelenmeyeciğini kısıtlayarak çalışır.
CSP‘yi etkinleştirmek için bir yanıtın, bu politikayı içeren bir değere sahip “Content-Security-Policy” adlı bir HTTP yanıt headeri içermesi gerekir. Politikanın kendisi, noktalı virgülle ayrılmış bir veya daha fazla yönergeden oluşur.
CSP Kullanarak XSS Saldırılarını Azaltma
Aşağıdaki yönerge, script’lerin yalnızca sayfanın kendisiyle aynı kaynaktan yüklenmesine izin verecektir:
Aşağıdaki yönerge yalnızca belirli bir domain’den script’lerin yüklenmesine izin verecektir:
Harici alanlardan script’lere izin verilirken dikkatli olunmalıdır. Bir saldırganın dış domainden sunulan içeriği denetlemesi için herhangi bir yol varsa, bir saldırı gerçekleştirebilir. Örneğin, “ajax.googleapis.com” gibi müşteri başına URL kullanmayan içerik dağıtım ağlarına (CDN‘ler) güvenilmemelidir, çünkü üçüncü taraflar alanlarına içerik alabilir.
Belirli alan adlarını beyaz listeye eklemenin yanı sıra, içerik güvenliği politikası da güvenilir kaynakları belirlemenin iki yolunu daha sağlar, “nonce” ve “hashe”:
CSP yönergesi bir nonce (rastgele değer) belirtebilir ve script yükleyen etikette aynı değer kullanılmalıdır. Değerler eşleşmezse, script çalıştırılamaz. Kontrol olarak etkili olabilmesi için, nonce her sayfa yüklemesinde güvenli bir şekilde oluşturulmalı ve saldırgan tarafından tahmin edilememelidir.
CSP yönergesi, güvenilir script’in içeriğinin bir karmasını belirtebilir. Gerçek script’in karması yönergede belirtilen değerle eşleşmezse, script çalıştırılmaz. Script’in içeriği değişirse, elbette yönergede belirtilen karma değerini güncellemeniz gerekir.
Bir CSP‘nin script gibi kaynakları engellemesi oldukça yaygındır. Ancak, birçok CSP görüntü isteğine izin verir. Bu, Örneğin CSRF belirteçlerini açıklamak amacıyla harici sunuculara istekte bulunmak için genellikle img öğelerini kullanabileceğiniz anlamına gelir.
Bazı politikalar daha kısıtlayıcıdır ve tüm dış talep biçimlerini önler. Bununla birlikte, bazı kullanıcı etkileşimlerini sağlayarak bu kısıtlamaları aşmak hala mümkündür. Bu ilke biçimini atlamak için, tıklatıldığında, inject edilen öğenin içerdiği her şeyi harici bir sunucuya depolayacak ve gönderecek bir HTML öğesi inject etmeniz gerekir.
CSP Kullanarak Dangling Markup Injection Azaltma
Aşağıdaki yönerge, görüntülerin yalnızca sayfanın kendisiyle aynı kaynaktan yüklenmesine izin verir:
Aşağıdaki yönerge yalnızca belirli bir domainden görüntülerin yüklenmesine izin verecektir:
Kullanıcı etkileşimi olmadan veri yakalamanın kolay bir yolu bir img etiketi kullandığından, bu politikaların dangling injection istismarlarını önleyeceğini unutmayın. Bununla birlikte, dangling href özelliğine sahip bir “anchor” etiketi inject edenler gibi diğer istismarlar önlenmez.
Politika Injection ile CSP‘yi Atlamak
Büyük olasılıkla bir rapor yönergesinde, gerçek politikaya girişi yansıtan bir web sitesiyle karşılaşabilirsiniz. Site kontrol edebileceğiniz bir parametreyi yansıtıyorsa, kendi CSP yönergelerinizi eklemek için noktalı virgül inject edebilirsiniz. Genellikle, bu “report-uri” yönergesi listede sonuncudur. Bu, bu güvenlik açığından yararlanmak ve ilkeyi atlamak için mevcut yönergelerin üzerine yazmanız gerektiği anlamına gelir.
Normalde, varolan bir “script-src” yönergesinin üzerine yazmak mümkün değildir. Bununla birlikte, Chrome yakın zamanda script öğelerini kontrol etmenize izin veren ancak etkinlikleri kontrol etmenize izin vermeyen “script-src-elem” yönergesini tanıttı. Önemli olan, bu yeni yönerge mevcut “script-src” yönergelerinin üzerine yazmanıza izin verir.
CSP Kullanarak Clickjacking’e Karşı Koruma
Aşağıdaki yönergede, sayfanın yalnızca aynı kaynaktan gelen diğer sayfalar tarafından framelenmesine izin verilecektir:
Aşağıdaki yönerge framelenmeyi tamamen engelleyecektir:
Birden çok alan belirtebileceğiniz ve joker karakterler kullanabildiğiniz için, tıklamayı önlemek için içerik güvenliği ilkesini kullanmak “X-Frame-Options” üstbilgisini kullanmaktan daha esnektir. Örneğin:
CSP ayrıca üst frame hiyerarşisindeki her bir frame’i doğrularken, “X-Frame-Options” ise yalnızca üst düzey frame’i doğrular.
Clickjacking’e karşı koruma sağlamak için CSP kullanılması önerilir. Internet Explorer gibi CSP‘yi desteklemeyen eski tarayıcılarda koruma sağlamak için bunu “X-Frame-Options” header ile de birleştirebilirsiniz.
Dangling Markup Injection
Bu kısımda, Dangling Markup Injection’ı, tipik bir exploitin nasıl çalıştığını ve dangling markup injection saldırılarının nasıl önleneceğini açıklayacağım.
Dangling Markup Injection Nedir?
Dangling markup injection, cross-site scripting saldırısının mümkün olmadığı durumlarda domainler arası veri yakalama tekniğidir.
Bir uygulamanın saldırgan tarafından denetlenebilir verileri yanıtlarına güvensiz bir şekilde cevap veridiğini varsayalım:
Uygulamanın veya karakterleri filtrelemediğini veya karakterlerden kaçmadığını da varsayalım. Saldırgan, belirtilen öznitelik (attribute) değerinden ve ek etiketinden çıkmak ve bir HTML içeriğine geri dönmek için aşağıdaki kodları kullanabilir:
Bu durumda, bir saldırgan doğal olarak XSS gerçekleştirmeye çalışır. Ancak, giriş filtreleri, içerik güvenliği politikası veya diğer engeller nedeniyle düzenli bir XSS saldırısının mümkün olmadığını varsayalım. Burada, aşağıdaki gibi bir payload kullanarak dangling markup injection saldırısı yapmak hala mümkün olabilir:
Bu payload bir “img” etiketi oluşturur ve saldırganın sunucusunda bir URL içeren bir “src” özelliğinin başlangıcını tanımlar. Bir tarayıcı yanıtı ayrıştırdığında, özelliği sonlandırmak için tek bir tırnak işareti ile karşılaşana kadar ileriye bakacaktır. Bu karaktere kadar olan her şey URL‘nin bir parçası olarak değerlendirilir ve URL sorgu dizesi içindeki saldırganın sunucusuna gönderilir. Yeni satırlar da dahil olmak üzere alfasayısal olmayan karakterler URL kodlamalı olacaktır.
Saldırının sonucu, saldırganın, hassas verileri içerebilecek injection noktasından sonra uygulamanın yanıtının bir kısmını yakalayabilmesidir. Uygulamanın işlevselliğine bağlı olarak, bu CSRF belirteçlerini, e-posta iletilerini veya finansal verileri içerebilir.
Dangling Markup Injection Saldırılarını Önleme
Cross-site scripting’i önlemek için aynı genel savunmaları kullanarak, çıkıştaki verileri kodlayarak ve varışta, girişi doğrulayarak, dangling markup injection’ı önleyebilirsiniz.
Content Security Policy (CSP) kullanarak da bu saldıırları azaltabilirsiniz. Örneğin, img gibi etiketlerin harici kaynakları yüklemesini engelleyen bir ilke kullanarak bazı saldırıları önleyebilirsiniz.
Not: Chrome, img gibi etiketlerin açılı ayraçlar ve yeni satırlar gibi ham karakterler içeren URL‘leri tanımlamasını engelleyerek dangling markup injection başa çıkmaya karar verdi. Aksi takdirde yakalanacak veriler genellikle bu ham karakterleri içereceğinden bu saldırıları önler, böylece saldırı engellenir.
XSS Nasıl Önlenir
Kodlama, muhtemelen XSS savunmasının en önemli hattıdır, ancak her bağlamda XSS güvenlik açıklarını önlemek yeterli değildir. Ayrıca, girdiyi bir kullanıcıdan ilk alındığı anda mümkün olduğunca kesin bir şekilde doğrulamanız gerekir.
Giriş doğrulama örnekleri:
Bir kullanıcı yanıtlarda döndürülecek bir URL gönderirse, HTTP ve HTTPS gibi güvenli bir protokolle başladığını doğrular. Aksi takdirde, birisi sitenizi JavaScript veya veri gibi zararlı bir protokolle kullanabilir.
Bir kullanıcı sayısal olmasını beklediği bir değer sağlarsa, değerin gerçekte bir tamsayı içerdiğini doğrular.
Bu girişin doğrulanmasında yalnızca beklenen karakter kümesini içerir.
Giriş doğrulama ideal olarak geçersiz girişi engelleyerek çalışmalıdır. Geçersiz girişi geçerli kılmak için temizlemeye çalışmanın alternatif bir yaklaşımı hataya daha yatkındır ve mümkün olduğunca kaçınılmalıdır.
Beyaz Listeye Karşı Kara Listeye Ekleme
Girdi doğrulamasında genellikle kara listelerden ziyade beyaz listeler kullanılmalıdır. Örneğin, tüm zararlı protokollerin (javascript, veri vb.) Bir listesini yapmaya çalışmak yerine, güvenli protokollerin (HTTP, HTTPS) bir listesini yapın ve listede olmayan herhangi bir şeye izin vermeyin. Bu, yeni zararlı protokoller ortaya çıktığında savunmanızın bozulmamasını ve bir kara listeden kaçmak için geçersiz değerleri gizlemeye çalışan saldırılara karşı daha az hassas olmasını sağlayacaktır.
"Güvenli" HTML‘e izin verme
Kullanıcıların HTML kodları göndermesine izin verilmesinden mümkün olduğunca kaçınılmalıdır, ancak bazen bu iş gereklidir. Örneğin, bir blog sitesi bazı sınırlı HTML biçimlendirmeleri içeren yorumların yayınlanmasına izin verebilir.
Klasik yaklaşım, zararlı olabilecek etiketleri ve JavaScript‘i filtrelemeye çalışmaktır. Bunu güvenli etiketlerin ve özelliklerin bir beyaz listesini kullanarak uygulamayı deneyebilirsiniz, ancak tarayıcı ayrıştırma motorlarındaki ve mutasyon XSS gibi tuhaflıklardaki tutarsızlıklar sayesinde, bu yaklaşımın güvenli bir şekilde uygulanması son derece zordur.
En kötü seçenek, kullanıcının tarayıcısında DOMPurify gibi filtreleme ve kodlama yapan bir JavaScript kütüphanesi kullanmaktır. Diğer kütüphaneler, kullanıcıların işaretleme biçiminde içerik sağlamasına ve kodları HTML‘ye dönüştürmesine olanak tanır. Ne yazık ki, tüm bu kütüphaneler zaman zaman XSS güvenlik açıklarına sahiptir, bu yüzden bu mükemmel bir çözüm değildir. Bunlardan birini kullanıyorsanız, güvenlik güncellemelerini yakından takip etmelisiniz.
Template Engine Kullanarak XSS Nasıl Önlenir
Birçok modern web sitesi, dinamik içeriği HTML‘ye gömmek için “Twig” ve “Freemarker” gibi sunucu taraflı template engine’ler kullanır. Bunlar tipik olarak kendi kaçış sistemlerini tanımlar. Örneğin, Twig‘de, bağlamı tanımlayan bir argümanla “e ()” filtresini kullanabilirsiniz:
Jinja ve React gibi diğer bazı template engine’ler, varsayılan olarak XSS‘nin çoğunu etkili bir şekilde önleyen dinamik içerikten kaçar.
PHP XSS Nasıl Önlenir
PHP‘de “htmlentities” adı verilen verileri kodlamak için yerleşik bir fonksiyon vardır. HTML bağlamındayken girdinizden çıkmak için bu fonksiyonu çağırmalısınız. Fonksiyon, üç argümanla çağrılmalıdır:
Giriş dizeniz.
Tüm tırnak işaretlerini belirten bir flag olan “ENT_QUOTES” kodlanmalıdır.
Çoğu durumda UTF-8 olması gereken karakter kümesi.
Örneğin:
Bir JavaScript string bağlamındayken, daha önce açıklandığı gibi “Unicode-escape” girişini kullanmanız gerekir. Ne yazık ki, PHP bir dizeden “Unicode-escape” için bir API sağlamaz. PHP’de bunu yapabilmek için kod şu şekilde olabilir:
JQuery‘de XSS Nasıl Önlenir
JQuery‘deki en yaygın XSS biçimi, kullanıcı girdisini bir jQuery seçicisine geçirdiğiniz zamandır. Web geliştiricileri genellikle “location.hash” kullanır ve jQuery HTML‘yi oluşturacağından XSS‘e neden olacak seçiciye iletir. jQuery bu sorunu fark etti ve girdilerin bir karma bir veri ile başlayıp başlamadığını kontrol etmek için seçici mantığını düzeltti. Şimdi jQuery sadece ilk karakter “küçüktür” ise HTML oluşturur. Güvenilmeyen verileri jQuery seçicisine iletirseniz, yukarıdaki jsEscape fonksiyonunu kullanarak değerden doğru şekilde kaçtığınızdan emin olun.
Content Security Policy (CSP) Kullanarak XSS‘i Azaltma
İçerik güvenliği politikası (CSP) cross-site scripting’e karşı son savunma hattıdır. XSS engellemeniz başarısız olursa, bir saldırganın yapabileceklerini kısıtlayarak XSS‘i azaltmak için CSP‘yi kullanabilirsiniz.
CSP, harici script’lerin yüklenip yüklenemeyeceği ve satır içi scriptlerin çalıştırılıp çalıştırılmayacağı gibi çeşitli şeyleri kontrol etmenizi sağlar. CSP‘yi dağıtmak için, politikanızı içeren bir değere sahip “Content-Security-Policy” adlı bir HTTP yanıt başlığı eklemeniz gerekir.
Örnek bir CSP aşağıdaki gibidir:
Bu politika, resimler ve script gibi kaynakların yalnızca ana sayfa ile aynı kaynaktan yüklenebileceğini belirtir. Bu nedenle, bir saldırgan bir XSS payloadını başarıyla inject edebilse bile, yalnızca geçerli kaynaktan kaynakları yükleyebilir. Bu, bir saldırganın XSS güvenlik açığından yararlanma olasılığını büyük ölçüde azaltır.
Harici kaynakların yüklenmesi gerekiyorsa, yalnızca bir saldırganın sitenizi kullanmasına yardımcı olmayan script’lere izin verdiğinizden emin olun. Örneğin, belirli etki alanlarını beyaz listeye eklerseniz, saldırgan bu etki alanlarından herhangi bir script yükleyebilir. Mümkünse kaynakları kendi alan adınızda barındırmaya çalışın.
Bu mümkün değilse, farklı alanlardaki script’lere izin vermek için “hash” veya “nonce” tabanlı ilkeyi kullanabilirsiniz. Bir nonce, bir script veya kaynağın özniteliği olarak eklenen ve yalnızca sunucu tarafından oluşturulan kodla eşleştiğinde çalıştırılacak olan rastgele bir dizedir. Saldırgan, rastgele dizeyi tahmin edemez ve bu nedenle geçerli bir nonce ile bir script’i veya kaynağı çağıramaz ve bu nedenle kaynak çalıştırılmaz.
Konumuz burada bitiyor. Sizin için mümkün olduğunca geniş ve detaylı anlatmaya çalıştım. Bir eksiğim veya hatam olduysa affola. Bu arada XSS pratiği yapmak için bir tane oyun var. Bu oyundaki yönergeleri takip ederek pratik yapabilirsiniz: https://xss-game.appspot.com/
--
---
Akblog.NET
