Chrome Uzantıları Güvenli Bir Şekilde Yazma ve Denetleme Kılavuzu
Chrome Uzantısı Güvenlik Öncesi Sanatının İnce Bir Katmanı
İzole Ama Konuşmacı Dünyalar
Hızlı Bir Feragatname
Ev manifest.json Olduğu yer - Temel Uzantı Düzeni
Uzantı Mimarisi, Ad Alanı Yalıtımı ve DOM
Chrome Uzantısı Dünyasındaki Aynı Kaynak Politikası (SOP)
Enjeksiyon ve Mesaj Geçişi ile Engelleri Geçiş
Web Erişilebilir Kaynakları ve Gezinme Engelleme
Arka Plan Sayfaları ve İçerik Güvenliği Politikası
Uzantı Dünyasındaki Paslanmaz, Güvenlik Anti-Patterns'ten Çalmak
İçerik Scripts No Man ... veya CSP
Web Sayfası DOM Güvenilir Olmuyor
JavaScript DOM Etkinlikleri Doğrulanmış Olmalıdır
Web Sayfalarından Gönderilen Mesajlar Güvenilirleştirilemez
Kral Kale Surlarının Dışında Yaşamalı
URL'lerin Genel Olarak Ayrıştırılması
Tıklama ve web_accessible_resources Dikkatli Kullanımı
Denetim Sürecini otomatikleştirmek
Chrome Uzantısı Güvenlik Öncesi Sanatının İnce Bir Katmanı
Chrome uzantıları güvenliği ve güvenlik açıkları için Chrome uzantılarının denetlenmesine yönelik metodolojiler, şaşırtıcı derecede az önceki teknikle ilgili bir konu gibi görünüyor. Özellikle de konuyla ilgili geniş çaplı araştırmalar yapmış olan Electron gibi diğer platformlarlakarşılaştırıldığında . Denetleme kılavuzları ve araçları için internette arama yapmak, Chrome uzantılarını ve Chrome'un uzantı güvenlik açığı olan bir uzantıda XSS örneğindeki bir 2013 blog gönderisini açıklamak için yazılmış bir akademik çalışmadır . Diğer sonuçlar dışı tarihinden gibi görünen böyle bu uzantının parmak izi rehber olarak , artık yeni Chrome uzantıları için çalışır .
Elbette, Chrome uzantılarında güvenlik sorunları bulunamamış veya nadir görülüyor. Büyük bir örnek, Reddit Enhancement Suite (RES) uzantısında, işlenebilir sömürü için izin verilen bir Çapraz Site Komut Dosyası (XSS) güvenlik açığıydı. Bu güvenlik açığının iyi bir özeti için, bunun üzerine birbakın ; Uzantının o anda 1,5 milyon kullanıcısı vardı .
Bu örnek, XSS'in bir Arkaplan Sayfasında olmayan bir İçerik Komut Dosyası içerdiği gerçeğinden dolayı (bu kılavuz farklılıklara dalacaktır) en kötü durum senaryosu bile değildir . Kısaca: Arka Plan Sayfalarındaki güvenlik açıkları, tüm ayrıcalıklı uzantı API'lerine erişimi olan sayfalar, normal XSS'den çok daha kötüdür. Bu , tüm sitelere kurban olarak erişme, tarayıcı yer imlerini, geçmişini ve daha fazlasını düzenleme / düzenleme yeteneği gibi uzantının bildirilen API'lerinin herhangi birini kötüye kullanma yeteneği ile sonuçlanır . Örneğin, Steam Inventory Helper uzantısı , Arka Plan Sayfası bağlamında rasgele JavaScript yürütmesiyle sonuçlanan bir güvenlik açığından etkilenir.mağdurun tüm hesaplarını, kimliklendirildikleri her sitede kaçırma yeteneği ile sonuçlanır.
Chrome tarayıcısının ve uzantılarının inanılmaz popülerliği göz önünde bulundurulduğunda, bu platformun meydana gelebilecek güvenlik tuzaklarına daha yakından bakılması kesinlikle hak ediyor. Bu kılavuz, eklenti güvenliği anti-kalıplarının yanı sıra, geliştiricilere ve güvenlik araştırmacılarına Chrome uzantılarını denetleme konusunda kullanışlı bir hizmet ( kararsızlık ) sunmaya çalışmaktadır .
Chrome uzantılarında güvenlikle ilgili anti-kalıplara geçmeden önce, bu uzantıların tam olarak nasıl yapılandırıldığının anlaşılması önemlidir. Öne çıkmak ve açık olmak gerekirse: Chrome'un arkasındaki geliştiriciler , uzantı güvenliği ve güvensiz anti-kalıplara çok fazla düşünce kattılar. Mimarileri, aşağıda tartışacağım şekilde bunu çok net bir şekilde ortaya koyuyor ve bunların birçoğu, geliştiricilerin kolayca kendilerini ayaklarına vuramayacağı bir ortam yaratma fikriyle tasarlanıyor. Electron ve NW.js gibi platformlarımız olduğu bir çağdaSiteler arası Komut Dosyası Komut Dosyası (XSS) sistemik meselesini masaüstüne alma ve bunları hiçbir önlem almadan Uzaktan Kod Yürütme'ye (RCE) dönüştürme niyetinde; Chrome'un uzatma ortamı, aksi halde titrek bir manzara üzerinde sağlam bir temeldir. Chrome uzantıları, isteğe bağlı sistem komutlarını yürütme yeteneğine sahip değildir, ancak yine de bir geliştiricinin yanlış şeyi yapmakta zorlandığından emin olmak için hala çok dikkatli davranırlar.
İzole Ama Konuşmacı Dünyalar
Hızlı Bir Feragatname
Bu bölüm, Chrome uzantılarının nasıl işlediğine ilişkin olarak yabani otların içine girer. Bunu zaten biliyorsanız, doğrudan “ Uzantı Dünyasındaki Paslanmaz, Güvenlik Anti-Desenlerini Çalma ” bölümüne atlayabilirsiniz . Halihazırda Chrome uzantılarını geliştirmiş olsanız bile, bu bölümü hala tazeleme olarak kullanışlıdır.
Ev manifest.json Olduğu yer - Temel Uzantı Düzeni
Bir Chrome uzantısının dosya yapısı aslında çok basittir. Bir Chrome uzantısı aslında .crx dosya uzantısına sahip bir zip klasörüdür . Uzantının çekirdeği, dizinin kökü, izinleri ve diğer yapılandırma seçeneklerini belirten bir manifest.json dosyasıdır. Künt olmak için , manifest.json formatını anlamak, güvenlik açıkları için uzantıları denetlemek için çok önemlidir. Uzantının tüm yolları, manifest.json'un bulunduğu taban konumuna göre bulunur. Yani , example.jpg adlı kökte bir resminiz varsa , chrome-extension: // [EXTENSION_ID] /example.jpg dosyasında bulunur (uzantı kimliği birChrome uzantısı özel anahtarının base32 kodlu SHA256 karması ).
Uzantı Mimarisi, Ad Alanı Yalıtımı ve DOM
Chrome uzantılarının çalışma şeklinin tasarımı, nasıl kullanılabileceği konusunda büyük bir fark yaratır. Bunun birçoğu, daha önce bağlandığım akademik makalede özetlenmişti , fakat kağıdın biraz tarihli olması nedeniyle, burada da buna katılacağım.
Chrome uzantısı düzeni, görüntülendiğinde en iyi şekilde gösterilebilir :
Yukarıdaki diyagram bir Chrome uzantısının farklı bölümlerini göstermektedir. Her bir renkli kutu ayrı bir JavaScript değişken ad alanıdır . Ayrı ayrı ad alanları, JavaScript'te aşağıdaki gibi bir değişken bildirdiyseniz :
var testi = 2;test = 2 ;
Bu değişken sadece kendi bağlamından erişilebilir olacak (farklı renkli kutular birbirinin değişkenlerine doğrudan erişemez). Bu örnek için Arkaplan Page değişken olsaydı, olurdu değil İçerik Script veya web sayfasından erişilebilir olması. Aynı İçerik Komut Dosyası tarafından bildirilen değişkenler için de geçerlidir, Arka Plan Sayfası veya web sayfasının kendisi tarafından erişilemez . Bu sanal alan, herhangi bir değişkenine veya işlevine erişemediği veya değiştiremediği için sahtekar bir web sayfasının çalışan İçerik Komut Dosyası (lar) ına veya uzantının Arka Plan Sayfasına müdahale etmesini engeller.
Chrome Uzantısı Dünyasındaki Aynı Kaynak Politikası (SOP)
Aynı ayrıştırma politikasının Chrome uzantıları için nasıl uygulandığını da anladığınızda, bu ayırma çok anlamlıdır . Her bir Chrome uzantısının, aşağıdaki biçimdeki kendi kaynağı vardır:
chrome-extension: // - uzantı : //[32_CHAR_EXTENSION_ID]
Bu, bu uzantının altına düşen kaynaklara Chrome uzantı API'sı tarafından erişilebileceği anlamına gelir. Bu kaynak yapısı, bir Chrome uzantısının tüm kaynaklarının chrome-extension: // [ 32_CHAR_EXTENSION_ID ] / dizininin içinde olacağından anlamlıdır . Bu, Arka Plan Sayfaları ve Tarayıcı Eylem sayfaları hakkında konuşurken , bunların tümü chrome-extension: // [ 32_CHAR_EXTENSION_ID ] kaynağında yürütülürken geçerlidir . Aşağıdaki örneğe geçin:
chrome-extension: // [ - uzantı : // [32_CHAR_EXTENSION_ID ] / index.html
chrome-extension: // [ - uzantı : // [32_CHAR_EXTENSION_ID ] /example.html
Bu sayfaların her ikisi de aynı kaynağa sahip oldukları için DOM ve JavaScript ad alanlarına erişebilir . Bunun iframe contentWindow veya window.opener üzerinden erişim durumunda olduğunu unutmayın . Her bir Arka Plan Sayfasının değişken ad alanı, herhangi bir genel sıralama türünde birbiriyle paylaşılmaz ( çalışma zamanında tek bir Arka Plan Sayfasında yalnızca bir araya getirilen çok sayıda Arka Plan Sayfası Komut Dosyası örneğinde olduğu durumlar hariç ). Chrome'da Geliştirici Modu'nu etkinleştirerek bir Arka Plan Sayfası görüntüleyebilir ve hata ayıklayabilirsiniz .
İçerik Komut Dosyaları biraz farklı çalışırlar, kapsamlandıkları web sayfasının kaynağında çalışırlar . Dolayısıyla, https://example.com adresinde çalışan bir İçerik Komut dosyanız varsa , etkin köken https://example.com . Bu, https: //example.com'un DOM ile etkileşimde bulunma , etkinlik dinleyicileri ekleme ve bu kaynak için web sayfalarını almak için XMLHTTPRequest'lerigerçekleştirme gibi şeyler yapabileceği anlamına gelir . Bununla birlikte, ilgili uzantının Arka Plan Sayfası'ndaki DOM'yi değiştiremez, çünkü bunlar farklı kökenlerdir. Bununla birlikte, İçerik Komut Dosyası, Arka Plan Sayfasına mesaj gönderme ve bazı sınırlı Chrome uzantısı API'lerini arama becerisiyle biraz daha fazla ayrıcalığa sahip.. Bu biraz garip bir ayardır, çünkü İçerik Kodunuz gibi hissediyor ve web sayfanız hala DOM paylaşıyor olsalar bile ad alanı yalıtımı nedeniyle ayrı "sayfalar" içinde çalışıyorlar. Chrome'da İçerik Komut Dosyasını görüntülemek ve hata ayıklamak için Seçenekler> Diğer Araçlar> Geliştirici Araçları'nı kullanarak Chrome Geliştirici Araçları menüsünü açabilirsiniz. Geliştirici araçları gösterildikten sonra, "Kaynaklar" sekmesini tıklayın ve "İçerik Komut Dosyaları" alt sekmesini tıklayın. Burada çeşitli uzantılarınız için çalışan İçerik Komut Dosyalarını görebilir ve yürütme akışını izlemek için kesme noktaları belirtebilirsiniz:
Bir Chrome uzantısını denetleme zamanımın çoğu, yukarıda görülen Chrome geliştirici panelinde, kesme noktalarını belirleyerek ve yürütmeyi izleyerek geçirilir.
Enjeksiyon ve Mesaj Geçişi ile Engelleri Geçiş
Bununla birlikte, ad alanlarının ayrılmasına rağmen Chrome uzantısının çalışmalarını yapması için hala çok yer var. Örneğin, İçerik Komut Dosyası'nın web sayfasının ad alanında tanımlanan bir değişkenin değerini alması gerektiğini varsayalım. Web sayfasının ad alanına doğrudan erişemese de web sayfasının DOM'sine erişebilir ve buna yeni bir komut dosyası etiketi ( <script> ) ekleyebilir . Bu enjekte edilen komut dosyası etiketi daha sonra web sayfasının ad alanında yürütülür ve değişkenlerine erişebilir. Değişkeni aldıktan sonra, enjekte edilen komut daha sonra değeri PostMessage () aracılığıyla İçerik Komut dosyasına iletebilir . Bu, İçerik Komut Dosyası ve ana “Web sayfası DOM” kutusunun içindeki web sayfasına sahip olmanın gösterdiği şeydir, her ikisi de web sayfasının DOM'sine erişebilir ancakdeğil eachothers ad erişebilir. Aşağıdaki şekil, web sayfasından bir değişken yakalama ve onu İçerik Komut dosyasına geçirme akışını göstermektedir:
Chrome uzantısı denetim sürecindeki anlaşılması gereken en önemli şeylerden biri, bu yalıtılmış dünyaların birlikte nasıl çalıştığıdır. Cevap, mesaj iletimi yoluyla (esas olarak) . Chrome uzantıları olduğu gibi etrafında iletileri aktarmak için birkaç farklı yolu vardır chrome.runtime.sendMessage () İçerik komut dosyası (ler) ya da gelen Arkaplan Sayfaları mesajlaşma için window.addEventListener () script içerik için web sayfalarından mesajların geçmesi için (ler). Güvenlik açısından bakıldığında, daha düşük bir ayrıcalıklı içerikten daha yüksek bir iletiye geçtiğinde Ayrıcalıklı içerik (örneğin, bir İçerik Komut Dosyasından Arka Plan sayfasına bir mesaj), beklenmedik girişler yoluyla sömürü için olası bir yol var. Ayrıca, istenmeyen verilerin kötüye kullanılmasını sağlamak için mesajlaşmanın düzgün bir şekilde yapıldığından emin olmak önemlidir. PostMessage () durumunda , bu mesaj göndermek için “ * ” joker karakteri kullanmamak demektir , çünkü pencereye referans veren herhangi bir web sayfası kendileri için potansiyel olarak dinleyebilir.
Web Erişilebilir Kaynakları ve Gezinme Engelleme
Ad alanı yalıtımı yeterli olmamış gibi, Chrome uzantı kaynakları çevresinde başka bir koruma katmanı vardır . Chrome uzantısındaki dosyalar, varsayılan olarak, İnternet'teki normal web sayfalarına iframe, kaynak sağlama veya başka şekilde dahil edilemez. Yani https://example.com olabilir değil iframe krom uzantısı: //pflahkdjlekaeehbenhpkpipgkbbdbbo/test.html örneğin. Ancak, Chrome'un uzantı API'sı , bu kaynakları web_accessible_resources aracılığıyla bildirerek bu kısıtlamayı gevşetmenize izin verir. Uzantının tezahüründe direktif. Bu, normal bir web sayfasının uzantılarınızdan JavaScript, resim veya diğer kaynakları içermesine izin vermek istediğiniz durumlarda kullanışlıdır. Bunun bir güvenlik perspektifinden olumsuz tarafı, bu bayrağa ayarlanmış herhangi bir HTML sayfasının artık tıklama ile saldırıya uğraması , kötü amaçlı girdinin location.hashiçine aktarılması , postMessage () aracılığıyla beklenmedik mesajlaşmanın veya arka planda sayfaların iframe ve çalıştırılmasıdır. Beklenmeyen sipariş. Bu nedenle, geliştiricilerin bu yönergeyle çok sayıda kaynağını joker olarak kullanmaları genellikle tehlikelidir. Ayrıca, bir Chrome uzantısı herhangi bir Bu yönerge aracılığıyla kaynaklar, İnternet'teki keyfi bir web sayfası, bir kullanıcının belirli bir uzantıyı çalıştırdığının parmak izini vermek için bu kaynak kaynaklarını kullanabilir. Bu, hem istismar hem de genel web takibinde çok sayıda kullanıma sahiptir.
Arka Plan Sayfaları ve İçerik Güvenliği Politikası
Arka plan sayfası, uzantıların manifestosunda bildirilen tüm Chrome uzantısı API'lerini arama yeteneğine sahip olduğundan, çeşitli dünyanın en ayrıcalıklı alanıdır . Bu API'ler, çerezleri, yer imlerini, geçmişleri, indirmeleri, proxy ayarlarını vb . Yönetme gibi şeyleri yapabilme yeteneğiyleuzantıları güçlü kılan şeyin temelini oluşturur . Bu sayfaların güçlü doğası göz önüne alındığında, Chrome, geliştiricilerin belirli minimum gereksinimlerle bildirilen bir İçerik Güvenliği Politikasına(CSP) sahip olmasını gerektirir . Chrome uzantısı dokümanı, politikanın varsayılan olarak aşağıdaki olduğunu belirtir:
script-src 'kendini'; object-src 'kendini'- src 'kendini' ; nesne - src 'kendini'
Bu etkili bir şekilde geçerli olmakla birlikte, varsayılan politikanın aslında aşağıdakilerden bahsedilmesine değerdir (Chrome'un geliştirici araçlarının Ağ panelini kullanarak bunu kendiniz doğrulayabilirsiniz):
script-src 'self' blob: dosya sistemi: chrome-extension-resource :; object-src 'self' blob: dosya sistemi :;- src 'self' blob : dosya sistemi : chrome - extension - resource :; object - src 'self' blob : dosya sistemi :;
Yukarıdaki ilke, blob: URI'leri oluşturma ve dosya sistemiyle etkileşim kurma gibi bazı genel JavaScript işlemlerine izin vermek için biraz daha fazladır . Elbette, geliştiriciler genellikle bu varsayılan politikayı görüyor ve ne kadar sıkı olduğundan rahatsız oluyorlar. Bu sıkıntı genellikle, geliştiricilerin CSP'yi olabildiğince "gevşetmek" için mümkün olduğu kadar gevşetmeye çalışmasıyla sonuçlanır. Chrome ekibi bu tehlikeyi önceden gördü ve geliştiricilerin CSP'lerini çok gevşek yapmasını önlemek için ek gereksinimler ekledi . Bu nedenle , bir Chrome uzantısı CSP'de 'güvensiz satır içi' kaynağa izin verilmesinin hiçbir yolu yoktur ( <script> in non ile kullanılmasını sağlar ). Bu, bir geliştiricinin asla yapamayacağı anlamına gelir Aşağıdaki gibi satır içi JavaScript yürütme kullanın:
İsim: <input onfocus = ”example ()” name = ”test” />: < giriş onfocus = ” example ()” name = ” test ” />
......
<a href=”javascript:example()”> Başlamak için tıklayın </a>< A href =” javascript : örnek ()”> tıklayın başlatmak için </ a >
......
<Script> alert ( “Hoşgeldiniz!”) </ Script><script> uyarısı (" Hoş geldiniz !") </ script >
Bu web geliştirme tarzına alışkın birçok geliştirici için acı verici olsa da, güvenlik avantajları anlaşılamıyor. Bunu yaparken Chrome, geliştiricilerin Arka Plan Sayfalarında Çapraz Site Komut Dosyası (XSS) güvenlik açıkları yazmasını çok daha zorlaştırdı. Oldukça az sayıda Chrome uzantısını denetleme deneyimimden bu, tamamen istismar edilebilir bir güvenlik açığında bulunan tek hafifletici faktör olmuştur. Ek olarak, bu gereksinimin, geliştiricilerin uzantılarını daha temiz bir şekilde yazmaları için sık sık zorladıkları ve görüşlerini ve temel mantığını ayırmak zorunda olduklarından bahsetmeye değer.
Bununla birlikte, CSP ile gördüğünüz diğer yaygın hataların çoğunu hala yapabilirsiniz. Geliştiriciler CSP'lerine 'güvensiz-değerlendirme' ekleyebilir ve çoğu zaman CDN'leri joker karakterleri ve herkesin gönderebileceği ve kaynak kodları gönderebileceği diğer kaynakları ekleyebilir. Bu şeyler genellikle saldırganların CSP'nin tüm korumalarını atlamasına izin verir.
Uzantı Dünyasındaki Paslanmaz, Güvenlik Anti-Patterns'ten Çalmak
İçerik Scripts No Man ... veya CSP
Arka Plan Sayfaları için İçerik Güvenliği Politikası (CSP) gereksinimleriyle ilgili tüm konuşmalarda, Chrome Uzantıları'nda Siteler Arası Komut Dosyası (XSS) öğesinin ölü olduğu fikri olabilir. Bu her durumda değil, sadece uzantının İçerik Komut Dosyası tarafına ağırlıklandırıldı. İçerik komut dosyaları yok onlar da, CSP uzantısı için ilan uymak zorunda değilsiniz (onlar enjekte sürece altında yürütme web sayfasının CSP uymak zorunda <script> web sayfasının DOM içine). Dolayısıyla, https ://example.com'un aşağıdakilerden bir CSP'si varsa :
script-src 'kendini'; object-src 'kendini'- src 'kendini' ; nesne - src 'kendini'
Bu, İçerik Komut Dosyası bağlamında yürütülen JavaScript ile tamamen ilgisizdir. Örneğin, eval () 'ın istediği herşeyi kullanmasına izin verebilir, buna rağmen web sayfasının menşei tarafından yasaklanmış olmasına rağmen. Bu, çoğu zaman popüler web sitelerine yeni güvenlik açıkları getiren İçerik Komutları ile Chrome uzantıları oluşturan geliştiricilere dönüştürülür. RES XSS açığı olduğunu Daha önce bahsedildiği gibi bunun gerçekleşmesi için harika bir örnek. Reddit'in bir Siteler Arası Komut Dosyası (XSS) güvenlik açığı bulunmamasına rağmen, RES, uzantı yüklü olanlar için siteye bir tanesini tanıttı. Bunu, kullanıcı tarafından kontrol edilebilen bir resim başlığı alarak ve Reddit'in web sayfası DOM'sine gereksiz yere HTML olarak enjekte ederek yaptı. Sonuç Reddit, RES uzantısının tüm kullanıcıları için sıfır tıklama XSS'e karşı savunmasız kaldı.
Bu gerçekliği incelerken, bir anti-desen ortaya çıkmaya başlar. Content Scripts yazmakta olan geliştiriciler, kullanıcı tarafından kontrol edilen girişi kullanarak güvensiz DOM işlemleri gerçekleştirdikleri takdirde kendilerini (ve kullanıcılarını) çekebilecekleri güçlü bir şansa sahiptir. Uzantı geliştiricileri, birkaç örnek vermek için innerHTML , html () veya href ( javascript: URI'ler) gibi çağrıları kullanarak güvenli olmayan DOM işlemlerini gerçekleştirmediklerinden emin olmak için çok dikkatli olmalıdır .
Web Sayfası DOM Can Güvenilir olun
Chrome uzantısı geliştiricilerinin katılacağı bir diğer yaygın anti-desen, harici bir web sayfasından sağlanan içeriğe güvenecekleridir . Bu, DOM'daki verilere güven, olay dinleyicilerinden çıkan olaylar veya web sayfasından bir İçerik Komut Dosyası'na gönderilen iletiler gibi birden çok biçimde ortaya çıkar .
DOM durumunda, bir saldırgan, İçerik Komut Dosyasının kullanımını kullanabilmek için düzeni istediği herhangi bir biçime göre değiştirebilir. Aynı zamanda hassas verilerin konur her durumda olduğunu belirtmek gerekir içine DOM kötü niyetli bir web sayfası üzerinden saldırganlar tarafından erişilebilir veya güvenilir bir web sayfasında bir XSS açığı yoluyla. Örneğin, Grammarly Chrome uzantısı, tüm web sayfalarının DOM'ında hassas kimlik doğrulama belirteçleri belirlediğinde bu hatayı yaptı ve kötü amaçlı bir web sayfasının DOM'dan çıkarmasını ve API'larının kimliğini doğrulamak için kullanmasını sağladı . Bu, bir uzantının, kullanıcının görüntülemesi için bir web sayfasına bir çeşit kullanıcı arayüzü yerleştirmesiyle daha yaygındır. Bu kullanıcı arayüzündeki çoğu zaman geliştiriciler, Chrome uzantısının dışında bırakılmaması gereken hassas bilgileri koyacaktır. Daha da kötüsü, genellikle bu öğeler daha sonra İçerik Komut Dosyası tarafından sorgulanır ve güvenilir işlemleri gerçekleştirmek için kullanılır. Bu desenler, bir saldırganın bu eylemlerin ortasında dolaşmasına ve beklenmeyen girdiler içerecek şekilde DOM öğelerini değiştirmesine izin verir.
JavaScript DOM Etkinlikleri Doğrulanmış Olmalıdır
Content Scripts ile web sayfası DOM arasındaki birincil kanallardan biri olan olay dinleyicileri de saldırganların kullanımına açıktır. Bunlar özellikle aldatıcıdır çünkü geliştiriciler, olayların salt kullanıcı eylemlerinden üretilmesini ve bir saldırgan tarafından sentetik olarak yaratılmamasını bekler. Aşağıdaki gibi bir komut dosyası alın:
// Enjekte edilecek bir öğe oluştur
var injected_last_key_element = document.createElement ("div");var injected_last_key_element = belge . createElement ( "div" );
injected_last_key_element.innerHTML = 'Son yazılan karakter: <div id = "last_keypress_div"> </ div>';. innerHTML = 'Son yazılan karakter: <div id = "last_keypress_div"> </ div>' ;
// Bu kutuyu sayfaya enjekte et// Bu kutuyu sayfaya enjekte et
document.body.appendChild (. Vücut . appendChild (
injected_last_key_element
););
// Keydown etkinliğini dinleyin ve önceden enjekte edilmiş div'da değerini gösterin.// Keydown etkinliğini dinleyin ve önceden enjekte edilmiş div'da değerini gösterin.
document.body.addEventListener ("keydown", işlev (keyevent) {. Vücut . addEventListener ( "keydown" , işlev ( keyevent ) {
document.getElementById ("last_keypress_div") .innerHTML = keyevent.code;. getElementById ( "last_keypress_div" ). innerHTML = keyevent . kod ;
});});
Yukarıdaki kod, keydown olaylarını dinleyecek ve belgenin gövdesine enjekte edilen <div> içindeki son tuş kod değerini gösterecektir . Bu nedenle, klavyenizdeki “a” tuşuna basarsanız, “KeyA” dizesi bu < insert > enjekte içinde görünür . Aşağıda, KeyboardEvent üzerindeki MDN belgelerinden bir ekran görüntüsü verilmiştir :
Sayfa üzerindeki KeyboardEvent.code kendisi şöyle demektedir:
“ KeyboardEvent.code özelliği, klavyedeki bir fiziksel anahtarı temsil eder (tuşa basılarak oluşturulan karakterin aksine). Başka bir deyişle, bu özellik klavye düzeni veya değiştirici tuşlarının durumu ile değiştirilmeyen bir değer döndürür. ”
Bu belgeleri okuyarak, bir geliştirici olarak XSS'in burada mümkün olmadığını düşünebilirsiniz. Sonuçta, bu sadece kullanıcının klavyesi tarafından basılan son tuş kodunu gösterecektir ve belgelerin mülkün “Salt Okunur” olduğunu söyler! Nasıl olabilir bu XSS neden kullanılmalıdır? Eğer bile olabilir sentetik etkinlikleri göndermek, sadece önceden tanımlanmış anahtar kodları olurdu ve <div> her olay tamamen yeniden tasarlanan olacağını, değil mi?
Ancak, tamamen yanlış olursunuz, bu aslında kolayca kullanılabilir . Aşağıdaki kod bir XSS ile sonuçlanacak kodu gösterir:
// Bir sentetik anahtar etkinliği oluştur
function generate_fake_key_event (target_element, key_event_type, custom_properties) {function generate_fake_key_event ( target_element , key_event_type , custom_properties ) {
var new_event = document.createEvent (var new_event = belge . createEvent (
"KeyboardEvent","KeyboardEvent" ,
););
for (custom_properties içinde var property_keyname) for ( custom_properties içinde var property_keyname )
if (custom_properties.hasOwnProperty (property_keyname)) {if ( custom_properties . hasOwnProperty ( property_keyname )) {
// Chromium Hack// Chromium Hack
Object.defineProperty (new_event, property_keyname, {Nesne . defineProperty ( new_event , property_keyname , {
get: function () {get : function () {
custom_properties [property_keyname] döndürün;geri custom_properties [ property_keyname ];
}}
});});
new_event.initKeyboardEvent (. initKeyboardEvent (
key_event_type,,
doğru,gerçek ,
doğru,gerçek ,
document.defaultView,. defaultView ,
yanlış,sahte ,
yanlış,sahte ,
yanlış,sahte ,
yanlış,sahte ,
0,0 ,
00
););
new_event [property_keyname] = custom_properties [property_keyname];[ property_keyname ] = custom_properties [ property_keyname ];
}}
}}
target_element.dispatchEvent (. dispatchEvent (
yeni etkinlik
););
}}
// <img src = x onerror = alert ('XSS') /> kodlu bir anahtar gönderme// <img src = x onerror = alert ('XSS') /> kodlu bir anahtar gönderme
generate_fake_key_event ((
document.body,. vücut ,
"Keydown","anahtar" ,
{{
"code": "<img src = x onerror = uyarı ('XSS') />","code" : "<img src = x onerror = uyarı ('XSS') />" ,
}}
))
Yukarıdaki kod, XSS uygulamasına neden olur ve görüntülenecek "XSS" metniyle bir uyarı:
Yukarıdaki örnek, keyfi olaylara güvenmenin birkaç önemli tuzağını göstermektedir:
// Keydown olayı için dinleyin ve daha önce enjekte edilen div içindeki değerini gösterin
document.body.addEventListener ("keydown", işlev (keyevent) {. Vücut . addEventListener ( "keydown" , işlev ( keyevent ) {
eğer (keyevent.isTrusted) {eğer ( keyevent . isTrusted ) {
document.getElementById ("last_keypress_div") .innerHTML = keyevent.code;. getElementById ( "last_keypress_div" ). innerHTML = keyevent . kod ;
}}
});});
Artık bir saldırgan tamamen karışık sentetik olayları bize gönderemez. İşlediğimiz tüm olaylar aslen son kullanıcı tarafından tetiklenmelidir. Iken IsTrusted özelliği yaygın olarak kullanılan edilmez, web sayfası olayları işleme İçerik Script durumunda esastır.
Bu örnek oldukça çekicidir çünkü bir saldırganın sayfanızda rasgele olaylar oluşturması muhtemelse, web sayfası düzeyinde zaten sahip olduğunuzdan, web sayfasındaki bir XSS bunun neden olduğu döngüseldir. Bunun gerçek bir dünya örneği, bir İçerik Komut Dosyası tarafından çekilen etkinlik verileriyle güvensiz bir şey yapan Arka Plan Sayfası olur. Ancak, basitlik açısından, onu yalnızca normal bir web sayfasında sahtecilik yapan bir JavaScript olayı gösterisine sakladık.
Web Sayfaları Gönderilen mesajlar Can not Güvenilir olun
Chrome uzantılarında yine başka bir ortak model , Arka Plan Sayfası'nda ayrıcalıklı Chrome uzantısı API'lerini çağırmak için iletinin iletilmesi için JavaScript'in postMessage () yöntemininkullanılmasıdır . Çoğu zaman bir web sayfasından bir mesaj gönderilir, bir İçerik dinleyicisi tarafından bir olay dinleyicisi aracılığıyla alınır ve daha sonra bazı ayrıcalıklı Chrome API'lerini çağırmak için Arka Plan Sayfasına aktarılır. Bu, herhangi bir web sayfasının ayrıcalıklı Chrome uzantısı API'lerini kullanabileceği doğrudan bir köprü oluşturur ve geliştirici mesajın kaynağını kontrol etmiyorsa bazı kötü durumlarla sonuçlanır .
Çoğu zaman, bir geliştirici alınan mesajların kaynağını kontrol etse bile, aşağıdakine benzer bir kontrol uygularlar:
window.addEventListener ("message", işlev (received_message) {. addEventListener ( "message" , işlev ( received_message ) {
// Sitemizin bu bir alt alanından emin olmak için kontrol edin// Sitemizin bu bir alt alanından emin olmak için kontrol edin
if (received_message.origin.indexOf (".trusteddomain.com")! == -1) {eğer ( received_message . origin . indexOf ( ".trusteddomain.com" ) ! == - 1 ) {
process_message (alınan_ölüm);( received_message );
}}
}, yanlış);}, yanlış );
Ya da, bir regex hayranı iseler, aşağıdaki örneklere benzer bir şey yapacaklardır:
received_message.match (/ HTTPS: \ / \ / www \ .trusteddomain \ com / ı). eşleşme ( /https:\/\/www\.trusteddomain\.com/ i )
......
received_message.match (/ https: \ / \ / www.trusteddomain.com $ / i). eşleşme ( /https?:\/\/www.trusteddomain.com$/ i )
......
Ne yazık ki tüm bu kontroller atlanamaz, aşağıdakiler her biri için baypasları gösterir:
// https://a.trusteddomain.com.attacker.com ile baypas edildi
received_message.origin.indexOf (".trusteddomain.com")! == -1. kökeni . indexOf ( ".trusteddomain.com" ) ! == - 1
// Ayrıca https://a.trusteddomain.com.attacker.com ile atlandı// Ayrıca https://a.trusteddomain.com.attacker.com ile atlandı
received_message.match (/ https: \ / \ / www \ .trusteddomain \ .com / ı). eşleşme ( /https?:\/\/www\.trusteddomain\.com/ i )
// https://wwwatrusteddomain.com ile baypas edildi// https://wwwatrusteddomain.com ile baypas edildi
received_message.match (/ https: \ / \ / www.trusteddomain.com $ / i). eşleşme ( /https?:\/\/www.trusteddomain.com$/ i )
Bu neredeyse şüphesiz , alınan mesajın menşe mülkiyeti , sitenin orijininin bir dizgesidir ve ayrıştırılmış menşe parçaları olan bir nesne değildir . Genel olarak URL'leri ayrıştırma, tuzağa eğilimli bir sorun olarak bilinir, dolayısıyla herkese bir ip atmak ve kendilerine sormalarını istemek doğal olarak bu sorunlara kendini gösterecektir. Belki de gelecekteki web standartlarında, geliştiricilere bu davranışı doğrulamak için daha güvenilir bir yol sağlamak amacıyla bir yerel kaynak doğrulama işlevi eklenebilir.
Mesajların kökenini güvenli bir şekilde doğrulamak için , güvenilir HTTPS kaynaklarının statik birlistesinin olması önerilir . HTTPS'nin sağlanması önemlidir, çünkü onsuz bir uzantı , orta saldırılarda insanlara karşı savunmasız olabilir . Aşağıdaki, bunu yapmak için güvenli kod örneğidir:
güvenilir_origins = [trusted_origins = [
"Https://trusteddomain.com","https://trusteddomain.com" ,
"Https://www.trusteddomain.com","https://www.trusteddomain.com" ,
"Https://extension.trusteddomain.com""Https://extension.trusteddomain.com"
];];
if (trusted_origins.includes (received_message.origin)) {if ( trusted_origins . içerir ( received_message . origin ) ) {
// Bu mesajın doğru yerden geldiğine güvenebiliriz// Bu mesajın doğru yerden geldiğine güvenebiliriz
process_message (alınan_ölüm);( received_message );
}}
Bu, yüzey alanını küçük tutar ve bir kaynağın güvenilir olup olmadığını kontrol ederken hataya çok az yer bırakır.
Tabii ki, birçok geliştirici ana alanlarının tüm alt alanlarını beyaz listeye dahil etmeyi tercih eder, böylece yeni ana makine adları eklemek için kaynak kodunu değiştirmek zorunda kalmazlar. Bunu yapmamanızı tavsiye etmeme rağmen (aşağıda tartışılan nedenlerden dolayı), bunun için güvenli kod aşağıda görülebilir:
// Mesajın kökeni çıkar
var message_origin = received_message.origin;var message_origin = received_message . kökeni ;
// Güvenilir alanınızı belirtin// Güvenilir alanınızı belirtin
var base_domain = "trusteddomain.com";var base_domain = "trusteddomain.com" ;
if (message_origin.startsWith ("https: //") && (message_origin.edsWith ("." [b] + base_domain) || message_origin === "https: //" + base_domain)) {if ( message_origin . beginWith ( "https: //" ) && ( message_origin . edsWith ( "." [ b ] + base_domain ) || message_origin === "https: //" + base_domain ) ) {
// Mesaj, HTTPS ve bir alt alan adı olup güvenir.// Mesaj, HTTPS ve bir alt alan adı olup güvenir.
process_message (alınan_ölüm);( received_message );
}}
Yukarıdaki kod basitçe bir kökeni HTTPS hem olmasını sağlamak için denetler basittir ve güvenilir bir baz etki alanının alt alan veya her iki sadece baz alan kendisi.
Bir son, ama aynı zamanda kontrol etmeyi hatırlamanız gereken önemli şey mesaj olay kaynağıdır . Gelen mesajlar, onu gönderen pencereye referans olan bir kaynak özelliğine sahiptir. Çoğu zaman bir İçerik Komut Dosyası, iletinin göndericisinin İçerik Komut Dosyasının çalıştığı pencereyle aynı olduğunu varsaymaktadır. Bu nedenle aşağıdaki basit kontrolün de eklenmesi önemlidir:
// Gönderenin beklediğimiz pencere olduğundan emin olmak için kontrol edin.
// Değilse hemen geri dönün.// Değilse hemen geri dönün.
eğer (received_message.source! == window) {eğer ( received_message . source ! == window ) {
dönüş;dönüş ;
}}
Yukarıdaki kontrol, iletiyi gönderen pencerenin İçerik Komut Dosyası'nın çalıştığı ile aynı olmasını sağlar. Değilse, komut iletiyi işlemek yerine anında döner. Geliştiricilerin yapacakları ortak bir hata, mesajın kaynağını kontrol etmemek ve alınan mesajın içeriğine göre DOM manipülasyonlarını gerçekleştirmektir. Bu, başka bir sayfanın, XSS ile sonuçlanan İçerik Komut Dosyası aracılığıyla güvenli olmayan bir DOM işlemini zorlamak için potansiyel olarak bir hedef siteye kötü amaçlı mesaj gönderebileceği anlamına gelir. İçerik Komut Dosyası ile aynı kaynak penceresini istemeyeceğiniz kenar durumları varken, büyük çoğunluk bu basit kontrolü uygulamalıdır.
Kral Kale Surlarının Dışında Yaşamalı
Artık bir şeyin güvenilir alanınızın bir alt alanının olduğundan emin olmanız için güvenli bir kod gösterdiğim için, bir an için yüzey alanını tartışmak istiyorum .
Çoğu zaman, ayrıcalıklı Chrome uzantısı API çağrılarına yalnızca Chrome uzantısı sahibi tarafından sahip olunan bir alanın alt alan adlarına izin veren uzantıları göreceksiniz . Bu model genellikle geliştiriciler için yararlıdır. Çünkü, uzantıyı kendisi güncellemek yerine Chrome uzantısının API'lerini farklı aramalar yapmak için web sitelerinin kodunu daha kolay değiştirebilirler. Bu fikir üzerinde çalıştıktan sonra, bir diğeri, güvenilir temel alanınızın herhangi bir alt alanından ayrıcalıklı API çağrılarına izin vermektir .
Bu davranış, externally_connectable direktifini kullanırken içine düşmek de kolaydır . Bu yönerge, hangi kaynağın uzantının Arka Plan Sayfasına mesaj gönderebileceğini belirtir. Hatta resmi belgelerinde örnek verilen tüm alt etki alanları için izin veren şudur üzerinden bir baz etki alanının HTTP veya HTTPS mesaj göndermek için:
"externally_connectable": {: {
"eşleşir": ["*: //*.example.com/*"]"eşleşir" : [ "*: //*.example.com/*" ]
}}
Bütün bunlar gelişme açısından çok makul görünüyor . Ancak, geliştiricinin etkili bir şekilde yaptığı şey, güvenlik bariyerini güçlü bir şekilde kilitlenmiş Arka Plan Sayfasından, alanlarının herhangi bir alt alanına taşır . Bu, bir saldırganın , güvenilen etki alanının herhangi bir alt etki alanında isteğe bağlı JavaScript yürütme özelliği varsa, bu ayrıcalıklı çağrıları tamamen ele geçirebileceği anlamına gelir . Bunun gerçekleşebileceği çeşitli yollar vardır:
Bu sorunun iyi bir örneği, ZenMate VPN Chrome uzantısında bulduğum kritik bir güvenlik açığında görülebilir (bu yazı yazıldığı sırada ~ 3.5 milyon kullanıcıya sahiptir). Aşağıdaki (önceden) savunmasız manifest.json'dan bir alıntıdır :
... kısalık için kesilmiş ...kısalık için kesilmiş ...
{{
"js": ["js" : [
"Komut / page_api.js""Komut / page_api.js"
],],
"maçlar": ["eşleşir" : [
"*: //*.zenmate.com/*","*: //*.zenmate.com/*" ,
"*: //*.zenmate.ae/*","*: //*.zenmate.ae/*" ,
"*: //*.zenmate.ma/*","*: //*.zenmate.ma/*" ,
"*: //*.zenmate.dk/*","*: //*.zenmate.dk/*" ,
"*: //*.zenmate.at/*","*: //*.zenmate.at/*" ,
"*: //*.zenmate.ch/*","*: //*.zenmate.ch/*" ,
"*: //*.zenmate.de/*","*: //*.zenmate.de/*" ,
"*: //*.zenmate.li/*","*: //*.zenmate.li/*" ,
"*: //*.zenmate.ca/*","*: //*.zenmate.ca/*" ,
"*: //*.zenmate.co.uk/*","*: //*.zenmate.co.uk/*" ,
"*: //*.zenmate.ie/*","*: //*.zenmate.ie/*" ,
"*: //*.zenmate.co.nz/*","*: //*.zenmate.co.nz/*" ,
"*: //*.zenmate.com.ar/*","*: //*.zenmate.com.ar/*" ,
"*: //*.zenmate.cl/*","*: //*.zenmate.cl/*" ,
"*: //*.zenmate.co/*","*: //*.zenmate.co/*" ,
"*: //*.zenmate.es/*","*: //*.zenmate.es/*" ,
"*: //*.zenmate.mx/*","*: //*.zenmate.mx/*" ,
"*: //*.zenmate.com.pa/*","*: //*.zenmate.com.pa/*" ,
"*: //*.zenmate.com.pe/*","*: //*.zenmate.com.pe/*" ,
"*: //*.zenmate.com.ve/*","*: //*.zenmate.com.ve/*" ,
"*: //*.zenmate.fi/*","*: //*.zenmate.fi/*" ,
"*: //*.zenmate.fr/*","*: //*.zenmate.fr/*" ,
"*: //*.zenmate.co.il/*","*: //*.zenmate.co.il/*" ,
"*: //*.zenmate.in/*","*: //*.zenmate.in/*" ,
"*: //*.zenmate.hu/*","*: //*.zenmate.hu/*" ,
"*: //*.zenmate.co.id/*","*: //*.zenmate.co.id/*" ,
"*: //*.zenmate.is/*","*: //*.zenmate.is/*" ,
"*: //*.zenmate.it/*","*: //*.zenmate.it/*" ,
"*: //*.zenmate.jp/*","*: //*.zenmate.jp/*" ,
"*: //*.zenmate.kr/*","*: //*.zenmate.kr/*" ,
"*: //*.zenmate.lu/*","*: //*.zenmate.lu/*" ,
"*: //*.zenmate.lt/*","*: //*.zenmate.lt/*" ,
"*: //*.zenmate.lv/*","*: //*.zenmate.lv/*" ,
"*: //*.zenmate.my/*","*: //*.zenmate.my/*" ,
"*: //*.zenmate.be/*","*: //*.zenmate.be/*" ,
"*: //*.zenmate.nl/*","*: //*.zenmate.nl/*" ,
"*: //*.zenmate.pl/*","*: //*.zenmate.pl/*" ,
"*: //*.zenmate.com.br/*","*: //*.zenmate.com.br/*" ,
"*: //*.zenmate.pt/*","*: //*.zenmate.pt/*" ,
"*: //*.zenmate.ro/*","*: //*.zenmate.ro/*" ,
"*: //*.zenmate.com.ru/*","*: //*.zenmate.com.ru/*" ,
"*: //*.zenmate.se/*","*: //*.zenmate.se/*" ,
"*: //*.zenmate.sg/*","*: //*.zenmate.sg/*" ,
"*: //*.zenmate.com.ph/*","*: //*.zenmate.com.ph/*" ,
"*: //*.zenmate.com.tr/*","*: //*.zenmate.com.tr/*" ,
"*: //*.zenmate.pk/*","*: //*.zenmate.pk/*" ,
"*: //*.zenmate.vn/*","*: //*.zenmate.vn/*" ,
"*: //*.zenmate.hk/*""*: //*.zenmate.hk/*"
],],
"run_at": "document_start""run_at" : "document_start"
}}
... kısalık için kesilmiş ...... kısalık için kesilmiş ...
İçerik Komut Dosyası page_api.js , kullanıcı bilgisini almak, beyaz liste sitelerini proxy içermemek ve kullanıcının VPN'ye bağlı olup olmadığını değiştirmek gibi şeyleri yapmak için uzantıya ayrıcalıklı API çağrıları yapılmasına izin verir. Yukarıda belirtilen düzinelerce alan listesi verildiğinde, potansiyel olarak istismar edilecek çok fazla yüzey alanı vardır. Bu uzantıyı ele geçirebilmek için, herhangi bir alt alanda, bu düzinelerce alanın herhangi birinde bir XSS'ye ihtiyacımız var .
Ancak, buna bile ihtiyacımız olmadı. Alanlardan biri olan zenmate.li'nin süresi doldu ve kayıt için açık. Bunu satın aldıktan ve bunun için bir web sitesi hazırladıktan sonra, kullanıcı bilgilerini ayıklamak için gerekli olan her şey, bu beyaz listeye eklenmiş alanda şu yükü çalıştırmak oldu:
// Tüm kullanıcı verilerini almak için İçerik Komut Dosyası'na çağrı yapın
__zm.getData (işlev (sonuç) {. getData ( işlev ( sonuç ) {
console.log (. log (
Sonuçlar
););
});});
// VPN'yi kapat// VPN'yi kapat
(Yanlış) __zm.toggle;. geçiş ( yanlış );
Bu yük ile, tüm kullanıcı bilgilerini (kimlik doğrulama belirteçleri, e-posta adresleri, vb.) Alabilir ve uzantının tüm korumalarını etkin bir şekilde tamamen geçersiz kılabiliriz. Satıcının yanıtı hemen ortaya çıktı ve bu sorun düzeltildi , ancak uzantının kontrolünü birden çok web sitesine taşıdığınızda ve yüzey alanını genişlettiğinizde ortaya çıkabilecek kritik sorunların türünü tam olarak gösterir . Tam bir kayıt için lütfen detayları daha ayrıntılı bir şekilde ele alan bu gönderiye bakın .
URL'lerin Genel Olarak Ayrıştırılması
Geliştiricinin, güvenilir bir kaynaktan olup olmadığını görmek için belirli bir URL'yi ayrıştırabileceği başka durumlar da vardır. Bu , sorgulanan sekmede meta verilerle dolu bir Sekme nesnesini döndüren chrome.tabs.get () gibi API'lerin kullanımı yoluyla gerçekleşebilir . Geliştiriciler genellikle güvendikleri bir site olup olmadığını görmek için bu nesnenin url özelliğini normal bir ifade ile ayrıştırmaya çalışır . Daha önce de gördüğümüz gibi, URL'leri ayrıştırmak zor bir iştir ve doğru olması çok zordur. Bu sorunun temeli, bir URL'nin kaynağını çıkarmak için yazdığınız kodun , Chrome'un dahili olarak nasıl yapıldığından farklı olabileceği ve bir baypasla sonuçlanabileceğidir.
Bir URL'yi belirli bir URL'den güvenli bir şekilde çekmek için temiz bir yol, URL () yapıcısını kullanmaktır:
// Giriş URL'si
var input_url = "https://trusted-domain.com/example-url/?red=blue#yellow";var input_url = "https://trusted-domain.com/example-url/?red=blue#yellow" ;
// Bir URL'nin hedef kaynaklı olup olmadığını kontrol edin.// Bir URL'nin hedef kaynaklı olup olmadığını kontrol edin.
işlev check_origin_match (input_url, target_origin) {işlev check_origin_match ( input_url , target_origin ) {
var parsed_url = yeni URL (var parsed_url = yeni URL (
input_url
););
dönüş (parsed_url.origin === target_origin);dönüş ( parsed_url . origin === target_origin );
}}
eğer (check_origin_match (input_url, "https://trusted-domain.com")) {eğer ( check_origin_match ( input_url , "https://trusted-domain.com" ) ) {
// URL güvenilir bir kaynaktan geliyor!// URL güvenilir bir kaynaktan geliyor!
} Başka {} else {
// Güvenilir bir kaynaktan değil.// Güvenilir bir kaynaktan değil.
}}
Yukarıdaki kod özeldir çünkü çalışma, belirli bir URL’den menşei almak için Chrome’un URL ayrıştırıcısına kaydırır. Bu, kodunuzun ve Chrome’un kodunun belirli bir URL’nin gerçek kökenini kabul etmesini sağlar. Yukarıdaki check_origin_match () işlevini kullanmak yerine , URL yapıcısına kendiniz bir URL iletebilir ve yukarıdaki kodun bir kısmını kullanarak origin özelliğini kontrol edebilirsiniz. Bu, sizin için önceden ayrıştırılmamış olması nedeniyle bir URL'nin kaynağını güvenli bir şekilde kontrol etmeniz gereken durumlarda ele alınmalıdır. Son URL nesnesinde ayrıca hash, ana bilgisayar adı, URL yolu, parametreler ve daha fazlası için yararlı ayrıştırılmış alanlar bulunur.
Ait Clickjacking & Dikkatli kullanın web_accessible_resources
Web_accessible_resources yönergesi böyle uzatma sayfaları, resim gibi hangi kaynaklara belirtir ve JavaScript keyfi web siteleri tarafından gömülebilir. Daha önce, varsayılan olarak belirtildiği gibi, keyfi web sayfaları olamaz iframe'lerinde uzatma sayfaları gömmek veya komut dosyası veya stil etiketleri aracılığıyla onları kaynak. Bu direktifin örnek kullanımı aşağıda görülebilir:
{
... kısalık için kesilmiş ...... kısalık için kesilmiş ...
"web_accessible_resources": ["web_accessible_resources" : [
"Images / *. Png","images / *. png" ,
"Stil / çift rainbow.css","style / double-rainbow.css" ,
"Komut / çift rainbow.js","script / double-rainbow.js" ,
"Komut dosyası / main.js","komut dosyası / main.js" ,
"Şablonları / *""Şablonları / *"
],],
... kısalık için kesilmiş ...... kısalık için kesilmiş ...
}}
Yukarıdaki örnekte görüldüğü gibi, yalnızca belirli kaynakları belirtebilmeniz değil, aynı zamanda bir kaynak klasörünü de joker olarak kullanabilirsiniz. Ancak, zaman zaman geliştiriciler, Chrome'un uzantı kaynaklarını gömme yeteneklerini engelleyen bir sorunla karşılaşacak ve aşağıdaki gibi bir şey yapacaktır:
{
... kısalık için kesilmiş ...... kısalık için kesilmiş ...
"web_accessible_resources": ["web_accessible_resources" : [
"*""*" ,
],],
... kısalık için kesilmiş ...... kısalık için kesilmiş ...
}}
Bu tamamen geçerli bir politikadır ve temel olarak tüm Chrome uzantısı kaynaklarının artık üçüncü taraf web sitelerine yerleştirilebileceği anlamına gelir. Sorun, uzantınızın, ayrıcalıklı eylemler gerçekleştiren sayfalar içerdiği ve web_accessible_resources politikanızın kapsamına girdiği durumlarda bu durumun tıkırtılamayan bir güvenlik açığına dönüşmesidir . Tıklatma işleminin neden olduğu bir uzantı güvenlik açığı örneğini görmek için , Steam Envanter Yardımcısında bir UXSS ile ilgili bu gönderiyi inceleyin .
Denetim Sürecini otomatikleştirmek
Chrome uzantılarının benzersiz yapısı nedeniyle, geliştiricilerin ve güvenlik araştırmacılarının güvenlik açıkları için Chrome uzantılarını denetlemelerine yardımcı olacak bir hizmet yazmaya karar verdim. Tarnish adını verdiğim bu araç aşağıdaki özelliklere sahiptir:
Alıntı.. çeviri.
İzole Ama Konuşmacı Dünyalar
Hızlı Bir Feragatname
Ev manifest.json Olduğu yer - Temel Uzantı Düzeni
Uzantı Mimarisi, Ad Alanı Yalıtımı ve DOM
Chrome Uzantısı Dünyasındaki Aynı Kaynak Politikası (SOP)
Enjeksiyon ve Mesaj Geçişi ile Engelleri Geçiş
Web Erişilebilir Kaynakları ve Gezinme Engelleme
Arka Plan Sayfaları ve İçerik Güvenliği Politikası
Uzantı Dünyasındaki Paslanmaz, Güvenlik Anti-Patterns'ten Çalmak
İçerik Scripts No Man ... veya CSP
Web Sayfası DOM Güvenilir Olmuyor
JavaScript DOM Etkinlikleri Doğrulanmış Olmalıdır
Web Sayfalarından Gönderilen Mesajlar Güvenilirleştirilemez
Kral Kale Surlarının Dışında Yaşamalı
URL'lerin Genel Olarak Ayrıştırılması
Tıklama ve web_accessible_resources Dikkatli Kullanımı
Denetim Sürecini otomatikleştirmek
Chrome Uzantısı Güvenlik Öncesi Sanatının İnce Bir Katmanı
Chrome uzantıları güvenliği ve güvenlik açıkları için Chrome uzantılarının denetlenmesine yönelik metodolojiler, şaşırtıcı derecede az önceki teknikle ilgili bir konu gibi görünüyor. Özellikle de konuyla ilgili geniş çaplı araştırmalar yapmış olan Electron gibi diğer platformlarlakarşılaştırıldığında . Denetleme kılavuzları ve araçları için internette arama yapmak, Chrome uzantılarını ve Chrome'un uzantı güvenlik açığı olan bir uzantıda XSS örneğindeki bir 2013 blog gönderisini açıklamak için yazılmış bir akademik çalışmadır . Diğer sonuçlar dışı tarihinden gibi görünen böyle bu uzantının parmak izi rehber olarak , artık yeni Chrome uzantıları için çalışır .
Elbette, Chrome uzantılarında güvenlik sorunları bulunamamış veya nadir görülüyor. Büyük bir örnek, Reddit Enhancement Suite (RES) uzantısında, işlenebilir sömürü için izin verilen bir Çapraz Site Komut Dosyası (XSS) güvenlik açığıydı. Bu güvenlik açığının iyi bir özeti için, bunun üzerine birbakın ; Uzantının o anda 1,5 milyon kullanıcısı vardı .
Bu örnek, XSS'in bir Arkaplan Sayfasında olmayan bir İçerik Komut Dosyası içerdiği gerçeğinden dolayı (bu kılavuz farklılıklara dalacaktır) en kötü durum senaryosu bile değildir . Kısaca: Arka Plan Sayfalarındaki güvenlik açıkları, tüm ayrıcalıklı uzantı API'lerine erişimi olan sayfalar, normal XSS'den çok daha kötüdür. Bu , tüm sitelere kurban olarak erişme, tarayıcı yer imlerini, geçmişini ve daha fazlasını düzenleme / düzenleme yeteneği gibi uzantının bildirilen API'lerinin herhangi birini kötüye kullanma yeteneği ile sonuçlanır . Örneğin, Steam Inventory Helper uzantısı , Arka Plan Sayfası bağlamında rasgele JavaScript yürütmesiyle sonuçlanan bir güvenlik açığından etkilenir.mağdurun tüm hesaplarını, kimliklendirildikleri her sitede kaçırma yeteneği ile sonuçlanır.
Chrome tarayıcısının ve uzantılarının inanılmaz popülerliği göz önünde bulundurulduğunda, bu platformun meydana gelebilecek güvenlik tuzaklarına daha yakından bakılması kesinlikle hak ediyor. Bu kılavuz, eklenti güvenliği anti-kalıplarının yanı sıra, geliştiricilere ve güvenlik araştırmacılarına Chrome uzantılarını denetleme konusunda kullanışlı bir hizmet ( kararsızlık ) sunmaya çalışmaktadır .
Chrome uzantılarında güvenlikle ilgili anti-kalıplara geçmeden önce, bu uzantıların tam olarak nasıl yapılandırıldığının anlaşılması önemlidir. Öne çıkmak ve açık olmak gerekirse: Chrome'un arkasındaki geliştiriciler , uzantı güvenliği ve güvensiz anti-kalıplara çok fazla düşünce kattılar. Mimarileri, aşağıda tartışacağım şekilde bunu çok net bir şekilde ortaya koyuyor ve bunların birçoğu, geliştiricilerin kolayca kendilerini ayaklarına vuramayacağı bir ortam yaratma fikriyle tasarlanıyor. Electron ve NW.js gibi platformlarımız olduğu bir çağdaSiteler arası Komut Dosyası Komut Dosyası (XSS) sistemik meselesini masaüstüne alma ve bunları hiçbir önlem almadan Uzaktan Kod Yürütme'ye (RCE) dönüştürme niyetinde; Chrome'un uzatma ortamı, aksi halde titrek bir manzara üzerinde sağlam bir temeldir. Chrome uzantıları, isteğe bağlı sistem komutlarını yürütme yeteneğine sahip değildir, ancak yine de bir geliştiricinin yanlış şeyi yapmakta zorlandığından emin olmak için hala çok dikkatli davranırlar.
İzole Ama Konuşmacı Dünyalar
Hızlı Bir Feragatname
Bu bölüm, Chrome uzantılarının nasıl işlediğine ilişkin olarak yabani otların içine girer. Bunu zaten biliyorsanız, doğrudan “ Uzantı Dünyasındaki Paslanmaz, Güvenlik Anti-Desenlerini Çalma ” bölümüne atlayabilirsiniz . Halihazırda Chrome uzantılarını geliştirmiş olsanız bile, bu bölümü hala tazeleme olarak kullanışlıdır.
Ev manifest.json Olduğu yer - Temel Uzantı Düzeni
Bir Chrome uzantısının dosya yapısı aslında çok basittir. Bir Chrome uzantısı aslında .crx dosya uzantısına sahip bir zip klasörüdür . Uzantının çekirdeği, dizinin kökü, izinleri ve diğer yapılandırma seçeneklerini belirten bir manifest.json dosyasıdır. Künt olmak için , manifest.json formatını anlamak, güvenlik açıkları için uzantıları denetlemek için çok önemlidir. Uzantının tüm yolları, manifest.json'un bulunduğu taban konumuna göre bulunur. Yani , example.jpg adlı kökte bir resminiz varsa , chrome-extension: // [EXTENSION_ID] /example.jpg dosyasında bulunur (uzantı kimliği birChrome uzantısı özel anahtarının base32 kodlu SHA256 karması ).
Uzantı Mimarisi, Ad Alanı Yalıtımı ve DOM
Chrome uzantılarının çalışma şeklinin tasarımı, nasıl kullanılabileceği konusunda büyük bir fark yaratır. Bunun birçoğu, daha önce bağlandığım akademik makalede özetlenmişti , fakat kağıdın biraz tarihli olması nedeniyle, burada da buna katılacağım.
Chrome uzantısı düzeni, görüntülendiğinde en iyi şekilde gösterilebilir :
Yukarıdaki diyagram bir Chrome uzantısının farklı bölümlerini göstermektedir. Her bir renkli kutu ayrı bir JavaScript değişken ad alanıdır . Ayrı ayrı ad alanları, JavaScript'te aşağıdaki gibi bir değişken bildirdiyseniz :
var testi = 2;test = 2 ;
Bu değişken sadece kendi bağlamından erişilebilir olacak (farklı renkli kutular birbirinin değişkenlerine doğrudan erişemez). Bu örnek için Arkaplan Page değişken olsaydı, olurdu değil İçerik Script veya web sayfasından erişilebilir olması. Aynı İçerik Komut Dosyası tarafından bildirilen değişkenler için de geçerlidir, Arka Plan Sayfası veya web sayfasının kendisi tarafından erişilemez . Bu sanal alan, herhangi bir değişkenine veya işlevine erişemediği veya değiştiremediği için sahtekar bir web sayfasının çalışan İçerik Komut Dosyası (lar) ına veya uzantının Arka Plan Sayfasına müdahale etmesini engeller.
Chrome Uzantısı Dünyasındaki Aynı Kaynak Politikası (SOP)
Aynı ayrıştırma politikasının Chrome uzantıları için nasıl uygulandığını da anladığınızda, bu ayırma çok anlamlıdır . Her bir Chrome uzantısının, aşağıdaki biçimdeki kendi kaynağı vardır:
chrome-extension: // - uzantı : //[32_CHAR_EXTENSION_ID]
Bu, bu uzantının altına düşen kaynaklara Chrome uzantı API'sı tarafından erişilebileceği anlamına gelir. Bu kaynak yapısı, bir Chrome uzantısının tüm kaynaklarının chrome-extension: // [ 32_CHAR_EXTENSION_ID ] / dizininin içinde olacağından anlamlıdır . Bu, Arka Plan Sayfaları ve Tarayıcı Eylem sayfaları hakkında konuşurken , bunların tümü chrome-extension: // [ 32_CHAR_EXTENSION_ID ] kaynağında yürütülürken geçerlidir . Aşağıdaki örneğe geçin:
chrome-extension: // [ - uzantı : // [32_CHAR_EXTENSION_ID ] / index.html
chrome-extension: // [ - uzantı : // [32_CHAR_EXTENSION_ID ] /example.html
Bu sayfaların her ikisi de aynı kaynağa sahip oldukları için DOM ve JavaScript ad alanlarına erişebilir . Bunun iframe contentWindow veya window.opener üzerinden erişim durumunda olduğunu unutmayın . Her bir Arka Plan Sayfasının değişken ad alanı, herhangi bir genel sıralama türünde birbiriyle paylaşılmaz ( çalışma zamanında tek bir Arka Plan Sayfasında yalnızca bir araya getirilen çok sayıda Arka Plan Sayfası Komut Dosyası örneğinde olduğu durumlar hariç ). Chrome'da Geliştirici Modu'nu etkinleştirerek bir Arka Plan Sayfası görüntüleyebilir ve hata ayıklayabilirsiniz .
İçerik Komut Dosyaları biraz farklı çalışırlar, kapsamlandıkları web sayfasının kaynağında çalışırlar . Dolayısıyla, https://example.com adresinde çalışan bir İçerik Komut dosyanız varsa , etkin köken https://example.com . Bu, https: //example.com'un DOM ile etkileşimde bulunma , etkinlik dinleyicileri ekleme ve bu kaynak için web sayfalarını almak için XMLHTTPRequest'lerigerçekleştirme gibi şeyler yapabileceği anlamına gelir . Bununla birlikte, ilgili uzantının Arka Plan Sayfası'ndaki DOM'yi değiştiremez, çünkü bunlar farklı kökenlerdir. Bununla birlikte, İçerik Komut Dosyası, Arka Plan Sayfasına mesaj gönderme ve bazı sınırlı Chrome uzantısı API'lerini arama becerisiyle biraz daha fazla ayrıcalığa sahip.. Bu biraz garip bir ayardır, çünkü İçerik Kodunuz gibi hissediyor ve web sayfanız hala DOM paylaşıyor olsalar bile ad alanı yalıtımı nedeniyle ayrı "sayfalar" içinde çalışıyorlar. Chrome'da İçerik Komut Dosyasını görüntülemek ve hata ayıklamak için Seçenekler> Diğer Araçlar> Geliştirici Araçları'nı kullanarak Chrome Geliştirici Araçları menüsünü açabilirsiniz. Geliştirici araçları gösterildikten sonra, "Kaynaklar" sekmesini tıklayın ve "İçerik Komut Dosyaları" alt sekmesini tıklayın. Burada çeşitli uzantılarınız için çalışan İçerik Komut Dosyalarını görebilir ve yürütme akışını izlemek için kesme noktaları belirtebilirsiniz:
Bir Chrome uzantısını denetleme zamanımın çoğu, yukarıda görülen Chrome geliştirici panelinde, kesme noktalarını belirleyerek ve yürütmeyi izleyerek geçirilir.
Enjeksiyon ve Mesaj Geçişi ile Engelleri Geçiş
Bununla birlikte, ad alanlarının ayrılmasına rağmen Chrome uzantısının çalışmalarını yapması için hala çok yer var. Örneğin, İçerik Komut Dosyası'nın web sayfasının ad alanında tanımlanan bir değişkenin değerini alması gerektiğini varsayalım. Web sayfasının ad alanına doğrudan erişemese de web sayfasının DOM'sine erişebilir ve buna yeni bir komut dosyası etiketi ( <script> ) ekleyebilir . Bu enjekte edilen komut dosyası etiketi daha sonra web sayfasının ad alanında yürütülür ve değişkenlerine erişebilir. Değişkeni aldıktan sonra, enjekte edilen komut daha sonra değeri PostMessage () aracılığıyla İçerik Komut dosyasına iletebilir . Bu, İçerik Komut Dosyası ve ana “Web sayfası DOM” kutusunun içindeki web sayfasına sahip olmanın gösterdiği şeydir, her ikisi de web sayfasının DOM'sine erişebilir ancakdeğil eachothers ad erişebilir. Aşağıdaki şekil, web sayfasından bir değişken yakalama ve onu İçerik Komut dosyasına geçirme akışını göstermektedir:
Chrome uzantısı denetim sürecindeki anlaşılması gereken en önemli şeylerden biri, bu yalıtılmış dünyaların birlikte nasıl çalıştığıdır. Cevap, mesaj iletimi yoluyla (esas olarak) . Chrome uzantıları olduğu gibi etrafında iletileri aktarmak için birkaç farklı yolu vardır chrome.runtime.sendMessage () İçerik komut dosyası (ler) ya da gelen Arkaplan Sayfaları mesajlaşma için window.addEventListener () script içerik için web sayfalarından mesajların geçmesi için (ler). Güvenlik açısından bakıldığında, daha düşük bir ayrıcalıklı içerikten daha yüksek bir iletiye geçtiğinde Ayrıcalıklı içerik (örneğin, bir İçerik Komut Dosyasından Arka Plan sayfasına bir mesaj), beklenmedik girişler yoluyla sömürü için olası bir yol var. Ayrıca, istenmeyen verilerin kötüye kullanılmasını sağlamak için mesajlaşmanın düzgün bir şekilde yapıldığından emin olmak önemlidir. PostMessage () durumunda , bu mesaj göndermek için “ * ” joker karakteri kullanmamak demektir , çünkü pencereye referans veren herhangi bir web sayfası kendileri için potansiyel olarak dinleyebilir.
Web Erişilebilir Kaynakları ve Gezinme Engelleme
Ad alanı yalıtımı yeterli olmamış gibi, Chrome uzantı kaynakları çevresinde başka bir koruma katmanı vardır . Chrome uzantısındaki dosyalar, varsayılan olarak, İnternet'teki normal web sayfalarına iframe, kaynak sağlama veya başka şekilde dahil edilemez. Yani https://example.com olabilir değil iframe krom uzantısı: //pflahkdjlekaeehbenhpkpipgkbbdbbo/test.html örneğin. Ancak, Chrome'un uzantı API'sı , bu kaynakları web_accessible_resources aracılığıyla bildirerek bu kısıtlamayı gevşetmenize izin verir. Uzantının tezahüründe direktif. Bu, normal bir web sayfasının uzantılarınızdan JavaScript, resim veya diğer kaynakları içermesine izin vermek istediğiniz durumlarda kullanışlıdır. Bunun bir güvenlik perspektifinden olumsuz tarafı, bu bayrağa ayarlanmış herhangi bir HTML sayfasının artık tıklama ile saldırıya uğraması , kötü amaçlı girdinin location.hashiçine aktarılması , postMessage () aracılığıyla beklenmedik mesajlaşmanın veya arka planda sayfaların iframe ve çalıştırılmasıdır. Beklenmeyen sipariş. Bu nedenle, geliştiricilerin bu yönergeyle çok sayıda kaynağını joker olarak kullanmaları genellikle tehlikelidir. Ayrıca, bir Chrome uzantısı herhangi bir Bu yönerge aracılığıyla kaynaklar, İnternet'teki keyfi bir web sayfası, bir kullanıcının belirli bir uzantıyı çalıştırdığının parmak izini vermek için bu kaynak kaynaklarını kullanabilir. Bu, hem istismar hem de genel web takibinde çok sayıda kullanıma sahiptir.
Arka Plan Sayfaları ve İçerik Güvenliği Politikası
Arka plan sayfası, uzantıların manifestosunda bildirilen tüm Chrome uzantısı API'lerini arama yeteneğine sahip olduğundan, çeşitli dünyanın en ayrıcalıklı alanıdır . Bu API'ler, çerezleri, yer imlerini, geçmişleri, indirmeleri, proxy ayarlarını vb . Yönetme gibi şeyleri yapabilme yeteneğiyleuzantıları güçlü kılan şeyin temelini oluşturur . Bu sayfaların güçlü doğası göz önüne alındığında, Chrome, geliştiricilerin belirli minimum gereksinimlerle bildirilen bir İçerik Güvenliği Politikasına(CSP) sahip olmasını gerektirir . Chrome uzantısı dokümanı, politikanın varsayılan olarak aşağıdaki olduğunu belirtir:
script-src 'kendini'; object-src 'kendini'- src 'kendini' ; nesne - src 'kendini'
Bu etkili bir şekilde geçerli olmakla birlikte, varsayılan politikanın aslında aşağıdakilerden bahsedilmesine değerdir (Chrome'un geliştirici araçlarının Ağ panelini kullanarak bunu kendiniz doğrulayabilirsiniz):
script-src 'self' blob: dosya sistemi: chrome-extension-resource :; object-src 'self' blob: dosya sistemi :;- src 'self' blob : dosya sistemi : chrome - extension - resource :; object - src 'self' blob : dosya sistemi :;
Yukarıdaki ilke, blob: URI'leri oluşturma ve dosya sistemiyle etkileşim kurma gibi bazı genel JavaScript işlemlerine izin vermek için biraz daha fazladır . Elbette, geliştiriciler genellikle bu varsayılan politikayı görüyor ve ne kadar sıkı olduğundan rahatsız oluyorlar. Bu sıkıntı genellikle, geliştiricilerin CSP'yi olabildiğince "gevşetmek" için mümkün olduğu kadar gevşetmeye çalışmasıyla sonuçlanır. Chrome ekibi bu tehlikeyi önceden gördü ve geliştiricilerin CSP'lerini çok gevşek yapmasını önlemek için ek gereksinimler ekledi . Bu nedenle , bir Chrome uzantısı CSP'de 'güvensiz satır içi' kaynağa izin verilmesinin hiçbir yolu yoktur ( <script> in non ile kullanılmasını sağlar ). Bu, bir geliştiricinin asla yapamayacağı anlamına gelir Aşağıdaki gibi satır içi JavaScript yürütme kullanın:
İsim: <input onfocus = ”example ()” name = ”test” />: < giriş onfocus = ” example ()” name = ” test ” />
......
<a href=”javascript:example()”> Başlamak için tıklayın </a>< A href =” javascript : örnek ()”> tıklayın başlatmak için </ a >
......
<Script> alert ( “Hoşgeldiniz!”) </ Script><script> uyarısı (" Hoş geldiniz !") </ script >
Bu web geliştirme tarzına alışkın birçok geliştirici için acı verici olsa da, güvenlik avantajları anlaşılamıyor. Bunu yaparken Chrome, geliştiricilerin Arka Plan Sayfalarında Çapraz Site Komut Dosyası (XSS) güvenlik açıkları yazmasını çok daha zorlaştırdı. Oldukça az sayıda Chrome uzantısını denetleme deneyimimden bu, tamamen istismar edilebilir bir güvenlik açığında bulunan tek hafifletici faktör olmuştur. Ek olarak, bu gereksinimin, geliştiricilerin uzantılarını daha temiz bir şekilde yazmaları için sık sık zorladıkları ve görüşlerini ve temel mantığını ayırmak zorunda olduklarından bahsetmeye değer.
Bununla birlikte, CSP ile gördüğünüz diğer yaygın hataların çoğunu hala yapabilirsiniz. Geliştiriciler CSP'lerine 'güvensiz-değerlendirme' ekleyebilir ve çoğu zaman CDN'leri joker karakterleri ve herkesin gönderebileceği ve kaynak kodları gönderebileceği diğer kaynakları ekleyebilir. Bu şeyler genellikle saldırganların CSP'nin tüm korumalarını atlamasına izin verir.
Uzantı Dünyasındaki Paslanmaz, Güvenlik Anti-Patterns'ten Çalmak
İçerik Scripts No Man ... veya CSP
Arka Plan Sayfaları için İçerik Güvenliği Politikası (CSP) gereksinimleriyle ilgili tüm konuşmalarda, Chrome Uzantıları'nda Siteler Arası Komut Dosyası (XSS) öğesinin ölü olduğu fikri olabilir. Bu her durumda değil, sadece uzantının İçerik Komut Dosyası tarafına ağırlıklandırıldı. İçerik komut dosyaları yok onlar da, CSP uzantısı için ilan uymak zorunda değilsiniz (onlar enjekte sürece altında yürütme web sayfasının CSP uymak zorunda <script> web sayfasının DOM içine). Dolayısıyla, https ://example.com'un aşağıdakilerden bir CSP'si varsa :
script-src 'kendini'; object-src 'kendini'- src 'kendini' ; nesne - src 'kendini'
Bu, İçerik Komut Dosyası bağlamında yürütülen JavaScript ile tamamen ilgisizdir. Örneğin, eval () 'ın istediği herşeyi kullanmasına izin verebilir, buna rağmen web sayfasının menşei tarafından yasaklanmış olmasına rağmen. Bu, çoğu zaman popüler web sitelerine yeni güvenlik açıkları getiren İçerik Komutları ile Chrome uzantıları oluşturan geliştiricilere dönüştürülür. RES XSS açığı olduğunu Daha önce bahsedildiği gibi bunun gerçekleşmesi için harika bir örnek. Reddit'in bir Siteler Arası Komut Dosyası (XSS) güvenlik açığı bulunmamasına rağmen, RES, uzantı yüklü olanlar için siteye bir tanesini tanıttı. Bunu, kullanıcı tarafından kontrol edilebilen bir resim başlığı alarak ve Reddit'in web sayfası DOM'sine gereksiz yere HTML olarak enjekte ederek yaptı. Sonuç Reddit, RES uzantısının tüm kullanıcıları için sıfır tıklama XSS'e karşı savunmasız kaldı.
Bu gerçekliği incelerken, bir anti-desen ortaya çıkmaya başlar. Content Scripts yazmakta olan geliştiriciler, kullanıcı tarafından kontrol edilen girişi kullanarak güvensiz DOM işlemleri gerçekleştirdikleri takdirde kendilerini (ve kullanıcılarını) çekebilecekleri güçlü bir şansa sahiptir. Uzantı geliştiricileri, birkaç örnek vermek için innerHTML , html () veya href ( javascript: URI'ler) gibi çağrıları kullanarak güvenli olmayan DOM işlemlerini gerçekleştirmediklerinden emin olmak için çok dikkatli olmalıdır .
Web Sayfası DOM Can Güvenilir olun
Chrome uzantısı geliştiricilerinin katılacağı bir diğer yaygın anti-desen, harici bir web sayfasından sağlanan içeriğe güvenecekleridir . Bu, DOM'daki verilere güven, olay dinleyicilerinden çıkan olaylar veya web sayfasından bir İçerik Komut Dosyası'na gönderilen iletiler gibi birden çok biçimde ortaya çıkar .
DOM durumunda, bir saldırgan, İçerik Komut Dosyasının kullanımını kullanabilmek için düzeni istediği herhangi bir biçime göre değiştirebilir. Aynı zamanda hassas verilerin konur her durumda olduğunu belirtmek gerekir içine DOM kötü niyetli bir web sayfası üzerinden saldırganlar tarafından erişilebilir veya güvenilir bir web sayfasında bir XSS açığı yoluyla. Örneğin, Grammarly Chrome uzantısı, tüm web sayfalarının DOM'ında hassas kimlik doğrulama belirteçleri belirlediğinde bu hatayı yaptı ve kötü amaçlı bir web sayfasının DOM'dan çıkarmasını ve API'larının kimliğini doğrulamak için kullanmasını sağladı . Bu, bir uzantının, kullanıcının görüntülemesi için bir web sayfasına bir çeşit kullanıcı arayüzü yerleştirmesiyle daha yaygındır. Bu kullanıcı arayüzündeki çoğu zaman geliştiriciler, Chrome uzantısının dışında bırakılmaması gereken hassas bilgileri koyacaktır. Daha da kötüsü, genellikle bu öğeler daha sonra İçerik Komut Dosyası tarafından sorgulanır ve güvenilir işlemleri gerçekleştirmek için kullanılır. Bu desenler, bir saldırganın bu eylemlerin ortasında dolaşmasına ve beklenmeyen girdiler içerecek şekilde DOM öğelerini değiştirmesine izin verir.
JavaScript DOM Etkinlikleri Doğrulanmış Olmalıdır
Content Scripts ile web sayfası DOM arasındaki birincil kanallardan biri olan olay dinleyicileri de saldırganların kullanımına açıktır. Bunlar özellikle aldatıcıdır çünkü geliştiriciler, olayların salt kullanıcı eylemlerinden üretilmesini ve bir saldırgan tarafından sentetik olarak yaratılmamasını bekler. Aşağıdaki gibi bir komut dosyası alın:
// Enjekte edilecek bir öğe oluştur
var injected_last_key_element = document.createElement ("div");var injected_last_key_element = belge . createElement ( "div" );
injected_last_key_element.innerHTML = 'Son yazılan karakter: <div id = "last_keypress_div"> </ div>';. innerHTML = 'Son yazılan karakter: <div id = "last_keypress_div"> </ div>' ;
// Bu kutuyu sayfaya enjekte et// Bu kutuyu sayfaya enjekte et
document.body.appendChild (. Vücut . appendChild (
injected_last_key_element
););
// Keydown etkinliğini dinleyin ve önceden enjekte edilmiş div'da değerini gösterin.// Keydown etkinliğini dinleyin ve önceden enjekte edilmiş div'da değerini gösterin.
document.body.addEventListener ("keydown", işlev (keyevent) {. Vücut . addEventListener ( "keydown" , işlev ( keyevent ) {
document.getElementById ("last_keypress_div") .innerHTML = keyevent.code;. getElementById ( "last_keypress_div" ). innerHTML = keyevent . kod ;
});});
Yukarıdaki kod, keydown olaylarını dinleyecek ve belgenin gövdesine enjekte edilen <div> içindeki son tuş kod değerini gösterecektir . Bu nedenle, klavyenizdeki “a” tuşuna basarsanız, “KeyA” dizesi bu < insert > enjekte içinde görünür . Aşağıda, KeyboardEvent üzerindeki MDN belgelerinden bir ekran görüntüsü verilmiştir :
Sayfa üzerindeki KeyboardEvent.code kendisi şöyle demektedir:
“ KeyboardEvent.code özelliği, klavyedeki bir fiziksel anahtarı temsil eder (tuşa basılarak oluşturulan karakterin aksine). Başka bir deyişle, bu özellik klavye düzeni veya değiştirici tuşlarının durumu ile değiştirilmeyen bir değer döndürür. ”
Bu belgeleri okuyarak, bir geliştirici olarak XSS'in burada mümkün olmadığını düşünebilirsiniz. Sonuçta, bu sadece kullanıcının klavyesi tarafından basılan son tuş kodunu gösterecektir ve belgelerin mülkün “Salt Okunur” olduğunu söyler! Nasıl olabilir bu XSS neden kullanılmalıdır? Eğer bile olabilir sentetik etkinlikleri göndermek, sadece önceden tanımlanmış anahtar kodları olurdu ve <div> her olay tamamen yeniden tasarlanan olacağını, değil mi?
Ancak, tamamen yanlış olursunuz, bu aslında kolayca kullanılabilir . Aşağıdaki kod bir XSS ile sonuçlanacak kodu gösterir:
// Bir sentetik anahtar etkinliği oluştur
function generate_fake_key_event (target_element, key_event_type, custom_properties) {function generate_fake_key_event ( target_element , key_event_type , custom_properties ) {
var new_event = document.createEvent (var new_event = belge . createEvent (
"KeyboardEvent","KeyboardEvent" ,
););
for (custom_properties içinde var property_keyname) for ( custom_properties içinde var property_keyname )
if (custom_properties.hasOwnProperty (property_keyname)) {if ( custom_properties . hasOwnProperty ( property_keyname )) {
// Chromium Hack// Chromium Hack
Object.defineProperty (new_event, property_keyname, {Nesne . defineProperty ( new_event , property_keyname , {
get: function () {get : function () {
custom_properties [property_keyname] döndürün;geri custom_properties [ property_keyname ];
}}
});});
new_event.initKeyboardEvent (. initKeyboardEvent (
key_event_type,,
doğru,gerçek ,
doğru,gerçek ,
document.defaultView,. defaultView ,
yanlış,sahte ,
yanlış,sahte ,
yanlış,sahte ,
yanlış,sahte ,
0,0 ,
00
););
new_event [property_keyname] = custom_properties [property_keyname];[ property_keyname ] = custom_properties [ property_keyname ];
}}
}}
target_element.dispatchEvent (. dispatchEvent (
yeni etkinlik
););
}}
// <img src = x onerror = alert ('XSS') /> kodlu bir anahtar gönderme// <img src = x onerror = alert ('XSS') /> kodlu bir anahtar gönderme
generate_fake_key_event ((
document.body,. vücut ,
"Keydown","anahtar" ,
{{
"code": "<img src = x onerror = uyarı ('XSS') />","code" : "<img src = x onerror = uyarı ('XSS') />" ,
}}
))
Yukarıdaki kod, XSS uygulamasına neden olur ve görüntülenecek "XSS" metniyle bir uyarı:
Yukarıdaki örnek, keyfi olaylara güvenmenin birkaç önemli tuzağını göstermektedir:
- Olaylar herhangi bir kullanıcı etkileşimi olmadan oluşturulabilir .
- Bir olay, dokümantasyonda “Salt Okunur” seçeneğine benzer bir şey ifade etse bile, bu tamamen oluşturulmuş bir olayın, oluşturulduktan sonra bu özelliğin değiştirilemeyeceğini belirtir . Bu, sentetik olarak oluşturulmuş olaylara hiç uygulanmaz .
- Sentetik olarak oluşturulmuş olaylar, etkinlik özellik değerleri için beklenen formatı bile takip etmek zorunda değildir. Belgelerin “kodlar” önceden tanımlanmış bir formatta olduğunu söylemesine rağmen, bu, sentetik olarak oluşturulmuş olaylar durumunda uygulanmaz. Bu yüzden bir saldırgan, KeyA gibi bir şey yerine <img src = x onerror = alert ('XSS') /> komutunu belirtebilir .
// Keydown olayı için dinleyin ve daha önce enjekte edilen div içindeki değerini gösterin
document.body.addEventListener ("keydown", işlev (keyevent) {. Vücut . addEventListener ( "keydown" , işlev ( keyevent ) {
eğer (keyevent.isTrusted) {eğer ( keyevent . isTrusted ) {
document.getElementById ("last_keypress_div") .innerHTML = keyevent.code;. getElementById ( "last_keypress_div" ). innerHTML = keyevent . kod ;
}}
});});
Artık bir saldırgan tamamen karışık sentetik olayları bize gönderemez. İşlediğimiz tüm olaylar aslen son kullanıcı tarafından tetiklenmelidir. Iken IsTrusted özelliği yaygın olarak kullanılan edilmez, web sayfası olayları işleme İçerik Script durumunda esastır.
Bu örnek oldukça çekicidir çünkü bir saldırganın sayfanızda rasgele olaylar oluşturması muhtemelse, web sayfası düzeyinde zaten sahip olduğunuzdan, web sayfasındaki bir XSS bunun neden olduğu döngüseldir. Bunun gerçek bir dünya örneği, bir İçerik Komut Dosyası tarafından çekilen etkinlik verileriyle güvensiz bir şey yapan Arka Plan Sayfası olur. Ancak, basitlik açısından, onu yalnızca normal bir web sayfasında sahtecilik yapan bir JavaScript olayı gösterisine sakladık.
Web Sayfaları Gönderilen mesajlar Can not Güvenilir olun
Chrome uzantılarında yine başka bir ortak model , Arka Plan Sayfası'nda ayrıcalıklı Chrome uzantısı API'lerini çağırmak için iletinin iletilmesi için JavaScript'in postMessage () yöntemininkullanılmasıdır . Çoğu zaman bir web sayfasından bir mesaj gönderilir, bir İçerik dinleyicisi tarafından bir olay dinleyicisi aracılığıyla alınır ve daha sonra bazı ayrıcalıklı Chrome API'lerini çağırmak için Arka Plan Sayfasına aktarılır. Bu, herhangi bir web sayfasının ayrıcalıklı Chrome uzantısı API'lerini kullanabileceği doğrudan bir köprü oluşturur ve geliştirici mesajın kaynağını kontrol etmiyorsa bazı kötü durumlarla sonuçlanır .
Çoğu zaman, bir geliştirici alınan mesajların kaynağını kontrol etse bile, aşağıdakine benzer bir kontrol uygularlar:
window.addEventListener ("message", işlev (received_message) {. addEventListener ( "message" , işlev ( received_message ) {
// Sitemizin bu bir alt alanından emin olmak için kontrol edin// Sitemizin bu bir alt alanından emin olmak için kontrol edin
if (received_message.origin.indexOf (".trusteddomain.com")! == -1) {eğer ( received_message . origin . indexOf ( ".trusteddomain.com" ) ! == - 1 ) {
process_message (alınan_ölüm);( received_message );
}}
}, yanlış);}, yanlış );
Ya da, bir regex hayranı iseler, aşağıdaki örneklere benzer bir şey yapacaklardır:
received_message.match (/ HTTPS: \ / \ / www \ .trusteddomain \ com / ı). eşleşme ( /https:\/\/www\.trusteddomain\.com/ i )
......
received_message.match (/ https: \ / \ / www.trusteddomain.com $ / i). eşleşme ( /https?:\/\/www.trusteddomain.com$/ i )
......
Ne yazık ki tüm bu kontroller atlanamaz, aşağıdakiler her biri için baypasları gösterir:
// https://a.trusteddomain.com.attacker.com ile baypas edildi
received_message.origin.indexOf (".trusteddomain.com")! == -1. kökeni . indexOf ( ".trusteddomain.com" ) ! == - 1
// Ayrıca https://a.trusteddomain.com.attacker.com ile atlandı// Ayrıca https://a.trusteddomain.com.attacker.com ile atlandı
received_message.match (/ https: \ / \ / www \ .trusteddomain \ .com / ı). eşleşme ( /https?:\/\/www\.trusteddomain\.com/ i )
// https://wwwatrusteddomain.com ile baypas edildi// https://wwwatrusteddomain.com ile baypas edildi
received_message.match (/ https: \ / \ / www.trusteddomain.com $ / i). eşleşme ( /https?:\/\/www.trusteddomain.com$/ i )
Bu neredeyse şüphesiz , alınan mesajın menşe mülkiyeti , sitenin orijininin bir dizgesidir ve ayrıştırılmış menşe parçaları olan bir nesne değildir . Genel olarak URL'leri ayrıştırma, tuzağa eğilimli bir sorun olarak bilinir, dolayısıyla herkese bir ip atmak ve kendilerine sormalarını istemek doğal olarak bu sorunlara kendini gösterecektir. Belki de gelecekteki web standartlarında, geliştiricilere bu davranışı doğrulamak için daha güvenilir bir yol sağlamak amacıyla bir yerel kaynak doğrulama işlevi eklenebilir.
Mesajların kökenini güvenli bir şekilde doğrulamak için , güvenilir HTTPS kaynaklarının statik birlistesinin olması önerilir . HTTPS'nin sağlanması önemlidir, çünkü onsuz bir uzantı , orta saldırılarda insanlara karşı savunmasız olabilir . Aşağıdaki, bunu yapmak için güvenli kod örneğidir:
güvenilir_origins = [trusted_origins = [
"Https://trusteddomain.com","https://trusteddomain.com" ,
"Https://www.trusteddomain.com","https://www.trusteddomain.com" ,
"Https://extension.trusteddomain.com""Https://extension.trusteddomain.com"
];];
if (trusted_origins.includes (received_message.origin)) {if ( trusted_origins . içerir ( received_message . origin ) ) {
// Bu mesajın doğru yerden geldiğine güvenebiliriz// Bu mesajın doğru yerden geldiğine güvenebiliriz
process_message (alınan_ölüm);( received_message );
}}
Bu, yüzey alanını küçük tutar ve bir kaynağın güvenilir olup olmadığını kontrol ederken hataya çok az yer bırakır.
Tabii ki, birçok geliştirici ana alanlarının tüm alt alanlarını beyaz listeye dahil etmeyi tercih eder, böylece yeni ana makine adları eklemek için kaynak kodunu değiştirmek zorunda kalmazlar. Bunu yapmamanızı tavsiye etmeme rağmen (aşağıda tartışılan nedenlerden dolayı), bunun için güvenli kod aşağıda görülebilir:
// Mesajın kökeni çıkar
var message_origin = received_message.origin;var message_origin = received_message . kökeni ;
// Güvenilir alanınızı belirtin// Güvenilir alanınızı belirtin
var base_domain = "trusteddomain.com";var base_domain = "trusteddomain.com" ;
if (message_origin.startsWith ("https: //") && (message_origin.edsWith ("." [b] + base_domain) || message_origin === "https: //" + base_domain)) {if ( message_origin . beginWith ( "https: //" ) && ( message_origin . edsWith ( "." [ b ] + base_domain ) || message_origin === "https: //" + base_domain ) ) {
// Mesaj, HTTPS ve bir alt alan adı olup güvenir.// Mesaj, HTTPS ve bir alt alan adı olup güvenir.
process_message (alınan_ölüm);( received_message );
}}
Yukarıdaki kod basitçe bir kökeni HTTPS hem olmasını sağlamak için denetler basittir ve güvenilir bir baz etki alanının alt alan veya her iki sadece baz alan kendisi.
Bir son, ama aynı zamanda kontrol etmeyi hatırlamanız gereken önemli şey mesaj olay kaynağıdır . Gelen mesajlar, onu gönderen pencereye referans olan bir kaynak özelliğine sahiptir. Çoğu zaman bir İçerik Komut Dosyası, iletinin göndericisinin İçerik Komut Dosyasının çalıştığı pencereyle aynı olduğunu varsaymaktadır. Bu nedenle aşağıdaki basit kontrolün de eklenmesi önemlidir:
// Gönderenin beklediğimiz pencere olduğundan emin olmak için kontrol edin.
// Değilse hemen geri dönün.// Değilse hemen geri dönün.
eğer (received_message.source! == window) {eğer ( received_message . source ! == window ) {
dönüş;dönüş ;
}}
Yukarıdaki kontrol, iletiyi gönderen pencerenin İçerik Komut Dosyası'nın çalıştığı ile aynı olmasını sağlar. Değilse, komut iletiyi işlemek yerine anında döner. Geliştiricilerin yapacakları ortak bir hata, mesajın kaynağını kontrol etmemek ve alınan mesajın içeriğine göre DOM manipülasyonlarını gerçekleştirmektir. Bu, başka bir sayfanın, XSS ile sonuçlanan İçerik Komut Dosyası aracılığıyla güvenli olmayan bir DOM işlemini zorlamak için potansiyel olarak bir hedef siteye kötü amaçlı mesaj gönderebileceği anlamına gelir. İçerik Komut Dosyası ile aynı kaynak penceresini istemeyeceğiniz kenar durumları varken, büyük çoğunluk bu basit kontrolü uygulamalıdır.
Kral Kale Surlarının Dışında Yaşamalı
Artık bir şeyin güvenilir alanınızın bir alt alanının olduğundan emin olmanız için güvenli bir kod gösterdiğim için, bir an için yüzey alanını tartışmak istiyorum .
Çoğu zaman, ayrıcalıklı Chrome uzantısı API çağrılarına yalnızca Chrome uzantısı sahibi tarafından sahip olunan bir alanın alt alan adlarına izin veren uzantıları göreceksiniz . Bu model genellikle geliştiriciler için yararlıdır. Çünkü, uzantıyı kendisi güncellemek yerine Chrome uzantısının API'lerini farklı aramalar yapmak için web sitelerinin kodunu daha kolay değiştirebilirler. Bu fikir üzerinde çalıştıktan sonra, bir diğeri, güvenilir temel alanınızın herhangi bir alt alanından ayrıcalıklı API çağrılarına izin vermektir .
Bu davranış, externally_connectable direktifini kullanırken içine düşmek de kolaydır . Bu yönerge, hangi kaynağın uzantının Arka Plan Sayfasına mesaj gönderebileceğini belirtir. Hatta resmi belgelerinde örnek verilen tüm alt etki alanları için izin veren şudur üzerinden bir baz etki alanının HTTP veya HTTPS mesaj göndermek için:
"externally_connectable": {: {
"eşleşir": ["*: //*.example.com/*"]"eşleşir" : [ "*: //*.example.com/*" ]
}}
Bütün bunlar gelişme açısından çok makul görünüyor . Ancak, geliştiricinin etkili bir şekilde yaptığı şey, güvenlik bariyerini güçlü bir şekilde kilitlenmiş Arka Plan Sayfasından, alanlarının herhangi bir alt alanına taşır . Bu, bir saldırganın , güvenilen etki alanının herhangi bir alt etki alanında isteğe bağlı JavaScript yürütme özelliği varsa, bu ayrıcalıklı çağrıları tamamen ele geçirebileceği anlamına gelir . Bunun gerçekleşebileceği çeşitli yollar vardır:
- Herhangi bir alt alandaki bir web sayfası, Çapraz Site Komut Dosyası (XSS) güvenlik açığına açıktır.
- Bir saldırgan, zararlı kod içeren herhangi bir alt alana yüklenen bir HTML dosyasını edinebilir .
- Herhangi bir alt alan, eski bir IP adresine , ayrılmamış bulut kaynaklarına , bir CNAME'nin süresi dolmuş bir alan adına , vb. İşaret ettiği için bir devralma güvenlik açığına açıktır .
Bu sorunun iyi bir örneği, ZenMate VPN Chrome uzantısında bulduğum kritik bir güvenlik açığında görülebilir (bu yazı yazıldığı sırada ~ 3.5 milyon kullanıcıya sahiptir). Aşağıdaki (önceden) savunmasız manifest.json'dan bir alıntıdır :
... kısalık için kesilmiş ...kısalık için kesilmiş ...
{{
"js": ["js" : [
"Komut / page_api.js""Komut / page_api.js"
],],
"maçlar": ["eşleşir" : [
"*: //*.zenmate.com/*","*: //*.zenmate.com/*" ,
"*: //*.zenmate.ae/*","*: //*.zenmate.ae/*" ,
"*: //*.zenmate.ma/*","*: //*.zenmate.ma/*" ,
"*: //*.zenmate.dk/*","*: //*.zenmate.dk/*" ,
"*: //*.zenmate.at/*","*: //*.zenmate.at/*" ,
"*: //*.zenmate.ch/*","*: //*.zenmate.ch/*" ,
"*: //*.zenmate.de/*","*: //*.zenmate.de/*" ,
"*: //*.zenmate.li/*","*: //*.zenmate.li/*" ,
"*: //*.zenmate.ca/*","*: //*.zenmate.ca/*" ,
"*: //*.zenmate.co.uk/*","*: //*.zenmate.co.uk/*" ,
"*: //*.zenmate.ie/*","*: //*.zenmate.ie/*" ,
"*: //*.zenmate.co.nz/*","*: //*.zenmate.co.nz/*" ,
"*: //*.zenmate.com.ar/*","*: //*.zenmate.com.ar/*" ,
"*: //*.zenmate.cl/*","*: //*.zenmate.cl/*" ,
"*: //*.zenmate.co/*","*: //*.zenmate.co/*" ,
"*: //*.zenmate.es/*","*: //*.zenmate.es/*" ,
"*: //*.zenmate.mx/*","*: //*.zenmate.mx/*" ,
"*: //*.zenmate.com.pa/*","*: //*.zenmate.com.pa/*" ,
"*: //*.zenmate.com.pe/*","*: //*.zenmate.com.pe/*" ,
"*: //*.zenmate.com.ve/*","*: //*.zenmate.com.ve/*" ,
"*: //*.zenmate.fi/*","*: //*.zenmate.fi/*" ,
"*: //*.zenmate.fr/*","*: //*.zenmate.fr/*" ,
"*: //*.zenmate.co.il/*","*: //*.zenmate.co.il/*" ,
"*: //*.zenmate.in/*","*: //*.zenmate.in/*" ,
"*: //*.zenmate.hu/*","*: //*.zenmate.hu/*" ,
"*: //*.zenmate.co.id/*","*: //*.zenmate.co.id/*" ,
"*: //*.zenmate.is/*","*: //*.zenmate.is/*" ,
"*: //*.zenmate.it/*","*: //*.zenmate.it/*" ,
"*: //*.zenmate.jp/*","*: //*.zenmate.jp/*" ,
"*: //*.zenmate.kr/*","*: //*.zenmate.kr/*" ,
"*: //*.zenmate.lu/*","*: //*.zenmate.lu/*" ,
"*: //*.zenmate.lt/*","*: //*.zenmate.lt/*" ,
"*: //*.zenmate.lv/*","*: //*.zenmate.lv/*" ,
"*: //*.zenmate.my/*","*: //*.zenmate.my/*" ,
"*: //*.zenmate.be/*","*: //*.zenmate.be/*" ,
"*: //*.zenmate.nl/*","*: //*.zenmate.nl/*" ,
"*: //*.zenmate.pl/*","*: //*.zenmate.pl/*" ,
"*: //*.zenmate.com.br/*","*: //*.zenmate.com.br/*" ,
"*: //*.zenmate.pt/*","*: //*.zenmate.pt/*" ,
"*: //*.zenmate.ro/*","*: //*.zenmate.ro/*" ,
"*: //*.zenmate.com.ru/*","*: //*.zenmate.com.ru/*" ,
"*: //*.zenmate.se/*","*: //*.zenmate.se/*" ,
"*: //*.zenmate.sg/*","*: //*.zenmate.sg/*" ,
"*: //*.zenmate.com.ph/*","*: //*.zenmate.com.ph/*" ,
"*: //*.zenmate.com.tr/*","*: //*.zenmate.com.tr/*" ,
"*: //*.zenmate.pk/*","*: //*.zenmate.pk/*" ,
"*: //*.zenmate.vn/*","*: //*.zenmate.vn/*" ,
"*: //*.zenmate.hk/*""*: //*.zenmate.hk/*"
],],
"run_at": "document_start""run_at" : "document_start"
}}
... kısalık için kesilmiş ...... kısalık için kesilmiş ...
İçerik Komut Dosyası page_api.js , kullanıcı bilgisini almak, beyaz liste sitelerini proxy içermemek ve kullanıcının VPN'ye bağlı olup olmadığını değiştirmek gibi şeyleri yapmak için uzantıya ayrıcalıklı API çağrıları yapılmasına izin verir. Yukarıda belirtilen düzinelerce alan listesi verildiğinde, potansiyel olarak istismar edilecek çok fazla yüzey alanı vardır. Bu uzantıyı ele geçirebilmek için, herhangi bir alt alanda, bu düzinelerce alanın herhangi birinde bir XSS'ye ihtiyacımız var .
Ancak, buna bile ihtiyacımız olmadı. Alanlardan biri olan zenmate.li'nin süresi doldu ve kayıt için açık. Bunu satın aldıktan ve bunun için bir web sitesi hazırladıktan sonra, kullanıcı bilgilerini ayıklamak için gerekli olan her şey, bu beyaz listeye eklenmiş alanda şu yükü çalıştırmak oldu:
// Tüm kullanıcı verilerini almak için İçerik Komut Dosyası'na çağrı yapın
__zm.getData (işlev (sonuç) {. getData ( işlev ( sonuç ) {
console.log (. log (
Sonuçlar
););
});});
// VPN'yi kapat// VPN'yi kapat
(Yanlış) __zm.toggle;. geçiş ( yanlış );
Bu yük ile, tüm kullanıcı bilgilerini (kimlik doğrulama belirteçleri, e-posta adresleri, vb.) Alabilir ve uzantının tüm korumalarını etkin bir şekilde tamamen geçersiz kılabiliriz. Satıcının yanıtı hemen ortaya çıktı ve bu sorun düzeltildi , ancak uzantının kontrolünü birden çok web sitesine taşıdığınızda ve yüzey alanını genişlettiğinizde ortaya çıkabilecek kritik sorunların türünü tam olarak gösterir . Tam bir kayıt için lütfen detayları daha ayrıntılı bir şekilde ele alan bu gönderiye bakın .
URL'lerin Genel Olarak Ayrıştırılması
Geliştiricinin, güvenilir bir kaynaktan olup olmadığını görmek için belirli bir URL'yi ayrıştırabileceği başka durumlar da vardır. Bu , sorgulanan sekmede meta verilerle dolu bir Sekme nesnesini döndüren chrome.tabs.get () gibi API'lerin kullanımı yoluyla gerçekleşebilir . Geliştiriciler genellikle güvendikleri bir site olup olmadığını görmek için bu nesnenin url özelliğini normal bir ifade ile ayrıştırmaya çalışır . Daha önce de gördüğümüz gibi, URL'leri ayrıştırmak zor bir iştir ve doğru olması çok zordur. Bu sorunun temeli, bir URL'nin kaynağını çıkarmak için yazdığınız kodun , Chrome'un dahili olarak nasıl yapıldığından farklı olabileceği ve bir baypasla sonuçlanabileceğidir.
Bir URL'yi belirli bir URL'den güvenli bir şekilde çekmek için temiz bir yol, URL () yapıcısını kullanmaktır:
// Giriş URL'si
var input_url = "https://trusted-domain.com/example-url/?red=blue#yellow";var input_url = "https://trusted-domain.com/example-url/?red=blue#yellow" ;
// Bir URL'nin hedef kaynaklı olup olmadığını kontrol edin.// Bir URL'nin hedef kaynaklı olup olmadığını kontrol edin.
işlev check_origin_match (input_url, target_origin) {işlev check_origin_match ( input_url , target_origin ) {
var parsed_url = yeni URL (var parsed_url = yeni URL (
input_url
););
dönüş (parsed_url.origin === target_origin);dönüş ( parsed_url . origin === target_origin );
}}
eğer (check_origin_match (input_url, "https://trusted-domain.com")) {eğer ( check_origin_match ( input_url , "https://trusted-domain.com" ) ) {
// URL güvenilir bir kaynaktan geliyor!// URL güvenilir bir kaynaktan geliyor!
} Başka {} else {
// Güvenilir bir kaynaktan değil.// Güvenilir bir kaynaktan değil.
}}
Yukarıdaki kod özeldir çünkü çalışma, belirli bir URL’den menşei almak için Chrome’un URL ayrıştırıcısına kaydırır. Bu, kodunuzun ve Chrome’un kodunun belirli bir URL’nin gerçek kökenini kabul etmesini sağlar. Yukarıdaki check_origin_match () işlevini kullanmak yerine , URL yapıcısına kendiniz bir URL iletebilir ve yukarıdaki kodun bir kısmını kullanarak origin özelliğini kontrol edebilirsiniz. Bu, sizin için önceden ayrıştırılmamış olması nedeniyle bir URL'nin kaynağını güvenli bir şekilde kontrol etmeniz gereken durumlarda ele alınmalıdır. Son URL nesnesinde ayrıca hash, ana bilgisayar adı, URL yolu, parametreler ve daha fazlası için yararlı ayrıştırılmış alanlar bulunur.
Ait Clickjacking & Dikkatli kullanın web_accessible_resources
Web_accessible_resources yönergesi böyle uzatma sayfaları, resim gibi hangi kaynaklara belirtir ve JavaScript keyfi web siteleri tarafından gömülebilir. Daha önce, varsayılan olarak belirtildiği gibi, keyfi web sayfaları olamaz iframe'lerinde uzatma sayfaları gömmek veya komut dosyası veya stil etiketleri aracılığıyla onları kaynak. Bu direktifin örnek kullanımı aşağıda görülebilir:
{
... kısalık için kesilmiş ...... kısalık için kesilmiş ...
"web_accessible_resources": ["web_accessible_resources" : [
"Images / *. Png","images / *. png" ,
"Stil / çift rainbow.css","style / double-rainbow.css" ,
"Komut / çift rainbow.js","script / double-rainbow.js" ,
"Komut dosyası / main.js","komut dosyası / main.js" ,
"Şablonları / *""Şablonları / *"
],],
... kısalık için kesilmiş ...... kısalık için kesilmiş ...
}}
Yukarıdaki örnekte görüldüğü gibi, yalnızca belirli kaynakları belirtebilmeniz değil, aynı zamanda bir kaynak klasörünü de joker olarak kullanabilirsiniz. Ancak, zaman zaman geliştiriciler, Chrome'un uzantı kaynaklarını gömme yeteneklerini engelleyen bir sorunla karşılaşacak ve aşağıdaki gibi bir şey yapacaktır:
{
... kısalık için kesilmiş ...... kısalık için kesilmiş ...
"web_accessible_resources": ["web_accessible_resources" : [
"*""*" ,
],],
... kısalık için kesilmiş ...... kısalık için kesilmiş ...
}}
Bu tamamen geçerli bir politikadır ve temel olarak tüm Chrome uzantısı kaynaklarının artık üçüncü taraf web sitelerine yerleştirilebileceği anlamına gelir. Sorun, uzantınızın, ayrıcalıklı eylemler gerçekleştiren sayfalar içerdiği ve web_accessible_resources politikanızın kapsamına girdiği durumlarda bu durumun tıkırtılamayan bir güvenlik açığına dönüşmesidir . Tıklatma işleminin neden olduğu bir uzantı güvenlik açığı örneğini görmek için , Steam Envanter Yardımcısında bir UXSS ile ilgili bu gönderiyi inceleyin .
Denetim Sürecini otomatikleştirmek
Chrome uzantılarının benzersiz yapısı nedeniyle, geliştiricilerin ve güvenlik araştırmacılarının güvenlik açıkları için Chrome uzantılarını denetlemelerine yardımcı olacak bir hizmet yazmaya karar verdim. Tarnish adını verdiğim bu araç aşağıdaki özelliklere sahiptir:
- Sağlanan bir Chrome web mağazası bağlantısından herhangi bir Chrome uzantısını çeker.
- manifest.json viewer : sadece uzantının manifestinin JSON-prettified versiyonunu görüntüler.
- Parmak İzi Analizi : web_accessible_resources'ın algılanması ve Chrome uzantısı parmak izi oluşturmanın otomatik oluşturulması.
- Potansiyel Tıklama Analizi : web_accessible_resources yönergesiyle uzantı HTML sayfalarının algılanması . Bunlar, sayfaların amacına bağlı olarak tıklamaya karşı potansiyel olarak savunmasızdır.
- İzin Uyarı (lar) görüntüleyici : uzantıyı yüklemeye çalışan bir kullanıcı tarafından görüntülenecek tüm Chrome izin istemi uyarılarının bir listesini gösterir.
- Tehlikeli işlev (ler) : potansiyel olarak saldırgan tarafından (örneğin, örneğin fonksiyonları yararlanılabilir tehlikeli fonksiyonları konumunu gösterir innerHTML ,chrome.tabs.executeScript ).
- Giriş Noktası (ları) : Uzantının kullanıcı / harici girişte nereye gittiğini gösterir. Bu, bir uzantının yüzey alanını anlamak ve kötü amaçlı hazırlanmış verileri uzantıya göndermek için potansiyel noktaları aramak için kullanışlıdır.
- Hem Tehlikeli İşlev (ler) hem de Giriş Noktası (ları) tarayıcıları, oluşturulan uyarıları için aşağıdakilere sahiptir:
- İlgili kod snippet'i ve uyarının neden olduğu satır.
- Sorunun açıklaması.
- Kodu içeren tam kaynak dosyasını görüntülemek için “Dosya Görüntüle” düğmesi.
- Uyarılan dosyanın yolu.
- Uyarılan dosyanın tam Chrome uzantısı URI'sı.
- Arka Plan Sayfası komut dosyası, İçerik Komut Dosyası, Tarayıcı Eylemi vb. Gibi dosya türü.
- Savunmasız çizgi bir JavaScript dosyasındaysa, dahil olduğu tüm sayfaların yollarının yanı sıra bu sayfanın türü ve web_accessible_resource durumu.
- İçerik Güvenliği Politikası (CSP) analizörü ve bypass denetleyicisi : Bu, uzantınızın CSP'sindeki zayıflıklara işaret edecek ve ayrıca beyaz listeye eklenmiş CDN'ler vb. Nedeniyle CSP'nizi atlamanın olası yollarını da aydınlatacaktır.
- Bilinen Hassas Olan Kütüphaneler : Bu , bilinen savunmasız JavaScript kitaplıklarının kullanımını denetlemek için Retire.js'yi kullanır .
- Uzantıyı ve biçimlendirilmiş sürümleri indirin .
- Orijinal uzantıyı indirin.
- Uzantının güzelleştirilmiş bir sürümünü indirin (otomatik olarak hazırlanmış HTML ve JavaScript).
- Tarama sonuçlarının otomatik olarak önbelleğe alınması , bir uzatma taraması çalıştırmanız, ilk kez çalıştırdığınızda iyi bir zaman alacaktır. Ancak, uzantının güncellenmediği varsayılarak ikinci kez, önbelleğe alınan sonuçlar nedeniyle neredeyse anında olacaktır.
- Linkable Report URL'leri , bir başkasını kolayca kararsızlıkla oluşturulan bir uzantı raporuna bağlar.
Alıntı.. çeviri.
Yorumlar
Yorum Gönder