Geleneksel siteler arası komut dosyası çalıştırma (XSS) güvenlik açıkları, sunucu tarafı oluşturma (PHP, JSP ve ASP gibi dillerle) norm haline geldiğinde yaygındı. Ancak uygulamalar daha karmaşık hale geldikçe ve geliştiriciler uygulama mantığını istemci tarafına kaydırmaya devam ettikçe, daha karmaşık istemci tarafı güvenlik açıklarının ortaya çıkması bekleniyor.
Bu makalede, DOM tabanlı siteler arası komut dosyası çalıştırma (XSS) güvenlik açıklarının neler olduğunu, bunların potansiyel etkilerini ve bunların modern uygulamalarda etkili bir şekilde nasıl tanımlanıp yararlanılacağını ele alacağız.
Hadi dalalım!
Geleneksel siteler arası komut dosyası çalıştırma (XSS) güvenlik açıklarında, kötü amaçlı girdiler sunucu tarafına gönderilir ve herhangi bir ek girdi temizliği gerekmeden HTTP yanıtında işlenir. DOM tabanlı siteler arası komut dosyası çalıştırma (XSS) ile, kötü amaçlı girdiler bir DOM kaynağından türetilir ve bir DOM havuzu aracılığıyla tamamen tarayıcıda değerlendirilir; bu, çıktının HTTP yanıt gövdesinde hiçbir zaman görünmediği anlamına gelir.
Temizlenmemiş verilerin (yükler gibi) bir DOM kaynağından bir DOM havuzuna aktarılması, rastgele JavaScript kodunun yürütülmesine olanak tanır. Yansıtıcı XSS’ye benzer şekilde, bir saldırgan, istemci tarafı kodunu yürütmek ve kurbanın oturumunun kontrolünü ele geçirmek için savunmasız sayfanın özel hazırlanmış bir bağlantısını kurbana gönderebilir.
Test aşamasına geçmeden önce tüm DOM kaynaklarına ve havuzlarına kısaca göz atalım.
DOM kaynakları
DOM kaynakları, saldırganların (genellikle URL aracılığıyla) manipüle edebileceği, kullanıcı tarafından kontrol edilebilen verileri içeren JavaScript özellikleridir. Aşağıda DOM tabanlı XSS saldırıları için olası tüm giriş noktalarının kapsamlı bir listesi bulunmaktadır:
DOM tabanlı XSS: DOM kaynakları açıklandı
DOM havuzları
DOM havuzları, kullanıcı tarafından kontrol edilebilen verileri yürütebilen veya oluşturabilen JavaScript işlevleridir. Bunlar, güvenilmeyen veriler bir kaynaktan havuza aktığında DOM tabanlı XSS güvenlik açıklarının gerçekte tetiklendiği yerlerdir.
Aşağıdaki çizimde birkaç DOM havuzu örneği bulabilirsiniz:
DOM tabanlı XSS: DOM havuzlarının açıklaması
Artık DOM havuzu ile kaynak arasındaki farkları anladığımıza göre, bu güvenlik açığı türlerini nasıl tanımlayacağınızı öğreneceğiniz test aşamasına geçebiliriz.
Anahtar kelimenizi enjekte ettiğiniz ve yansıma ve enjeksiyon noktaları aradığınız geleneksel XSS’den farklı olarak, DOM tabanlı XSS farklı bir yaklaşım gerektirir; bu yaklaşımla yükünüzü bir DOM kaynağına enjekte edersiniz ve girişinizin nerede ve işlenip işlenmediğini bulmak için çalışma zamanı DOM olay işleyicilerine müdahale edersiniz. DOM tabanlı XSS güvenlik açıklarına karşı, JavaScript kodunun kapsamlı bir şekilde incelenmesini içeren alternatif bir yöntem de bulunmaktadır.
Her iki yaklaşıma da daha yakından bakalım.
Statik kod analizi yoluyla DOM tabanlı XSS’yi bulma
Bu yaklaşım temel bir JavaScript temeli gerektirir. JS kodunu manuel olarak incelemeniz, DOM kaynaklarını aramanız ve bir DOM kaynağına herhangi bir referans bulana kadar ilerlemeniz gerekir.
Ek olarak, gizlenmiş ve küçültülmüş olanlar da dahil olmak üzere her JavaScript dosyasını ve kod pasajını ayrı ayrı incelemeniz gerekecektir.
DOM çalışma zamanı müdahalesi yoluyla DOM tabanlı XSS’yi bulma
Bu ikinci yaklaşım, çalışma zamanında olay işleyicilerinden yayılan DOM olaylarının aktif olarak ele geçirilmesini ve girişinizin işlenmiş olabileceği yerleri aramayı içerir. DOM havuzlarını aramak ve girişinizin işlenebileceği kesme noktaları ayarlamak için tarayıcınızın geliştirici konsolunu kullanmanız gerekecektir.
Bu yöntem, bir kaynaktan havuza doğru hareket eden verileri yakalamanıza ve analiz etmenize olanak sağlar:
Tarayıcı geliştirici konsolu aracılığıyla DOM tabanlı olayları ele geçirme
Her iki yaklaşım da sıkıcıdır ve geniş ölçekte test yaparken zorluklara neden olabilir. Şanslıyız ki, DOM tabanlı siteler arası komut dosyası oluşturma (XSS) dahil olmak üzere DOM tabanlı güvenlik açıklarını kolayca tespit etmenize yardımcı olabilecek Güvenilmeyen Türler ve DOM Invador gibi otomatik araçlar mevcuttur.
Artık DOM tabanlı XSS güvenlik açıklarının temellerini oluşturduğumuza göre, bunları vahşi ortamda nasıl kullanabileceğinizi keşfedelim.
DOM tabanlı XSS’yi innerHTML havuzu aracılığıyla kullanma
Bu makalenin DOM havuzları bölümünde daha önce gördüğümüz gibi, innerHTML havuzu, kötü amaçlı veriler de dahil olmak üzere HTML etiketlerini ayrıştırmak ve işlemek için kullanılır.
Bazen sunucu verilerini istemciden gelen dinamik girdiyle (bir URL sorgu parametresinin değeri gibi) birleştirirken innerHTML’nin tercih edildiğini fark edeceksiniz. Durum böyle olduğunda ve başka bir doğrulama yapılmadığında, herhangi bir HTML etiketini, rastgele JavaScript kodumuzu çalıştıracak bir olay işleyiciyle pratik olarak enjekte edebiliriz.
Aşağıdaki kod parçacığını dikkate alın:
innerHTML DOM havuzu aracılığıyla DOM tabanlı XSS
Açık 10. satırsavunmasız uygulamanın veriyi okuduğunu görebiliriz. firstName sorgu parametresini alır ve bunu özellikle DOM havuzuna iletir innerHTML. Tamamen kontrol ettiğimiz için firstName sorgu parametresini kullanarak, esasen aşağıdaki veriyi değer olarak iletebilir ve XSS verisi de dahil olmak üzere herhangi bir HTML etiketini oluşturabiliriz:
Yukarıda bahsedilen durum temel bir örneği temsil etmektedir. Gerçek dünya senaryolarında bir çeşit doğrulamayla karşılaşacaksınız. Bu, kötü amaçlı etiketleri filtreleyen temel bir normal ifade modeli, girişi temizlemek için kullanılan bir üçüncü taraf paketi (DOMPurify gibi) veya HTML’nin tüm verileri kodladığı sunucu tarafı önlemleri olabilir. Her iki durumda da, yine de tedbirlerin herhangi birinden kaçma fırsatı mevcut olabilir.
Bazı geliştiriciler, istemci tarafı verilerini doğru şekilde biçimlendirmek ve görüntülemek için base64 veya başka bir kodlama kullanır. Olası DOM tabanlı XSS durumlarını kaçırmamak için kaynak ile havuz arasında atob(), btoa() veya diğer kod çözme işlevlerinin kullanılıp kullanılmadığını belirlemek için her zaman JavaScript kodunu inceleyin.
Dinamik değerlendirme işlevleri aracılığıyla DOM tabanlı XSS’den yararlanma
Bu daha az yaygın olmasına rağmen, çoğunlukla kullanıcı tarafından kontrol edilebilen bir kaynaktan (bir sorgu parametresi gibi) gelen, dinamik verilere dayalı olarak istemci tarafı işlevleri yürüten hedeflerle zaman zaman karşılaşabilirsiniz. Bu gibi durumlarda, rastgele JavaScript kodu çalıştırmaktan neredeyse her zaman bir adım uzaktayız.
Bir örneğe bakalım:
İşlev DOM havuzu aracılığıyla DOM tabanlı XSS
Bu eski giriş formu şu işlemleri gerçekleştiriyor gibi görünüyor: locale parametresini seçin ve bunu argüman olarak ekleyin. Function() atmak. Rastgele kod çalıştırmak için şunu kullanmalıyız: locale bağlamdan çıkıp kendi kodumuzu enjekte etmek için parametre:
en']&&alert()//Bu veri, esas olarak, rastgele JavaScript kodunun çalıştırıldığını kanıtlayarak, alarm() işlevini çağırmamıza olanak tanır:
İşlev DOM havuzu aracılığıyla DOM tabanlı XSS
İstemci tarafı yönlendirmeleri yoluyla DOM tabanlı XSS’den yararlanma
Uygulama içi yönlendirmeler genellikle son kullanıcının uygulama deneyimini geliştirmek için kullanılır. Bir oturum belirteci yayınlandıktan sonra yeniden yönlendirildiğiniz oturum açma formlarını düşünün. Bununla birlikte, kullanıcı tarafından kontrol edilebilen veriler, giriş doğrulaması yapılmadan hemen bir DOM havuzuna aktarıldığında, bu, belirli koşullar altında, her geliştiricinin farkında olmadığı bir olasılık olan, rastgele JavaScript kodu yürütmemize izin verebilir.
Aşağıdaki örneği dikkate alın:
Konum DOM havuzu aracılığıyla DOM tabanlı XSS
Nasıl olduğuna dikkat et 33. satır değeri redirectURL parametre konum havuzuna iletilir. Önceki hile sayfamızı kullanarak, en azından hiçbir İçerik Güvenliği Politikası (CSP) zorunlu tutulmadığında, JavaScript protokolü aracılığıyla kod yürütmenin mümkün olduğunu belirleyebiliriz:
DOM tabanlı XSS: DOM havuzlarının açıklaması
Bu bilgilerle, bu DOM tabanlı siteler arası komut dosyası çalıştırma (XSS) güvenlik açığından yararlanmak için aşağıdaki kavram kanıtı URL’sini pratik olarak ziyaret edebiliriz:
http://example.com/login?redirectURL=javascript:alert(1)Konum DOM havuzu aracılığıyla DOM tabanlı XSS
Önceki örneğimize benzer şekilde, herhangi bir filtreden kaçınmak için veri yükünüz üzerinde denemeler yapmanız gerekebilir. Bu, filtreye bağlı olarak boş baytların, yeni satır beslemenin veya satırbaşı karakterlerinin (CR/LF) enjekte edilmesini içerebilir.
Sunucu tarafı mı yoksa istemci tarafı yönlendirmesi mi?
HTTP yanıtı bir 3XX durum kodu ve ‘Konum’ HTTP yanıt başlığını döndürürse, bu muhtemelen sunucu tarafı bir yönlendirmedir ve (DOM tabanlı) XSS, tarayıcılar Konum başlığını takip edeceğinden ve herhangi bir HTML oluşturmayacağından veya herhangi bir JavaScript kodunu çalıştırmayacağından mümkün olmayacaktır.
Aksi takdirde, bu bir istemci tarafı yönlendirmesidir ve bazı koşullar altında DOM tabanlı siteler arası komut dosyası çalıştırma mümkün olabilir.
İçe aktarılan üçüncü taraf paketler aracılığıyla DOM tabanlı XSS’den yararlanma
Modern web uygulamaları büyük ölçüde üçüncü taraf JavaScript kitaplıklarına ve paketlerine dayanır. Bu bağımlılıklar bazen en iyi uygulamalar izlenmeden kullanıldığında veya güncelliğini yitirdiğinde DOM tabanlı XSS güvenlik açıklarına neden olabilir ve sıklıkla gözden kaçan bir saldırı yüzeyi oluşturabilir.
Birkaç örneğe göz atalım.
jQuery aracılığıyla DOM tabanlı XSS
jQuery, en yaygın kullanılan JavaScript kütüphanelerinden biridir. DOM manipülasyonunu basitleştirirken aynı zamanda kullanıcı tarafından kontrol edilebilen girdileri işlerken DOM tabanlı XSS’ye yol açabilecek çeşitli yöntemler de sunar.
Birincil suçlu jQuery’dir. html() ile aynı şekilde davranan yöntem innerHTML yürütülebilir komut dosyası etiketleri ve olay işleyicileri de dahil olmak üzere HTML içeriğini ayrıştırıp görüntüleyerek.
Geliştiriciler, DOM kaynaklarından temizlenmemiş verileri (örnekler için önceki kopya sayfamıza bakın) aşağıdaki gibi yöntemlere aktardığında: html(), append()hatta jQuery seçicilerinin kendisi bile kurbanın tarayıcısında çalıştırılan kötü amaçlı yükleri enjekte etmek mümkün olabilir.
AngularJS/VueJS’de istemci tarafı şablon enjeksiyonu
AngularJS ve VueJS gibi JavaScript çerçevelerinde, istemci tarafı şablon enjeksiyonu (CSTI), bir JavaScript şablon oluşturma motoru, kullanıcı tarafından kontrol edilebilen girişi uygun şekilde temizlemeden işlediğinde meydana gelebilir. Her iki çerçeve de verileri dinamik olarak işlemek için ifade sözdizimini kullanır ve kullanıcı kontrollü giriş bu ifadelere ulaştığında isteğe bağlı JavaScript kodu yürütülebilir.
Örneğin AngularJS’de işlevleri çağırmak için yapıcının global özelliğini kullanabiliriz:
{{constructor.constructor('alert(1)')()}}Bu şablon enjeksiyon güvenlik açığı, DOM tabanlı XSS’ye yol açan bir tür DOM tabanlı güvenlik açığıdır. Aktif olarak AngularJS veya VueJS kullanan hedefleri test ederken şablon yerleştirme güvenlik açıklarına karşı dikkatli olduğunuzdan emin olun.
DOM XSS gibi DOM tabanlı güvenlik açıkları, geniş ölçekte tespit edilmesi ve test edilmesi zor olduğundan genellikle fark edilmez. Bu makalede, DOM tabanlı bu güvenlik açıklarını test edebileceğiniz ve bunlardan yararlanabileceğiniz çeşitli yolları araştırdık.
Demek DOM tabanlı XSS güvenlik açıklarından yararlanma konusunda yeni bir şey öğrendiniz… Şu anda becerilerinizi test etme zamanı! Savunmasız laboratuvarlar ve CTF’ler üzerinde pratik yaparak başlayabilir veya… Intigriti’deki 70’ten fazla genel hata ödül programımıza göz atabilirsiniz ve kim bilir, belki bir sonraki gönderiminizde bir ödül kazanabilirsiniz!