Recientemente bir güvenlik açığı keşfedildi bakımcıların filtre listelerini engellemesine izin verebilir Adblock Plus, AdBlock ve uBlocker tarayıcı uzantıları için Web sitelerine uzak komut dosyalarını enjekte eden filtreler oluşturmak için.
10 milyon sınırını aşan bir kullanıcı tabanıyla, reklam engelleyicilere kötü amaçlı komut dosyaları enjekte edilmiş olsaydı, bu önemli bir etkiye sahip olurdu Çünkü çerez hırsızlığı, bağlantı bilgileri, sayfa yönlendirmelerine neden olma veya diğer istenmeyen davranışlar gibi istenmeyen faaliyetler gerçekleştirebilirler.
Kimler için reklam engelleyicilere aşina değiller, temelde URL listeleri kullanıyorlar kötü niyetli reklamlar ve davranışlarla ilgili.
Genellikle, Küçük bir ekip veya hatta tek bir kişi tarafından yönetilirler.
Bu listeler Adblock Plus gibi bir reklam engelleme uzantısıyla yüklendiğinde, bu uzantı tarayıcının listeye konulan URL'lere bağlanmasını engelleyecek ve böylece kötü niyetli reklamlara veya komut dosyalarına bağlanmayı engelleyecektir.
Soruna $ yeniden yazma filtre seçeneği neden oluyor
Cuando Reklam Engelleyici Artı 3.2 2018'de piyasaya sürüldü, $ rewrite adlı yeni bir filtre listesi seçeneği ekledi.
Bu seçenek izin verildi bir liste bakıcısına normal bir ifadeyle eşleşen bir web isteğini değiştirin özellikle başka bir URL ile.
Hubert Figuiere, bu işlevi kim başlattı, bunu açıkladı:
"Chrome, Firefox ve Opera (ve 3.2 geliştirme sürümleri) için Adblock Plus 3.1.0.2053'den bu yana, yeni bir $ yeniden yazma filtresi seçeneği, bir kaynağın URL'sini engellemek yerine yeniden yazmanıza izin veriyor.
Adblock Plus, $ rewrite seçeneğiyle bir filtreye bir istek URL'si atadığında, URL'yi sağlanan kurala göre dönüştürür ve tarayıcıya kaynağı aynı anda yüklemesini söyler.
$ Kuralının sözdizimi yeniden yazma, yeni URL için şablon görevi gören bir dizeyi belirtir.
$ n, filtrenin n'inci alt eşleşmesi normal ifadesi ile değiştirilir. Bu, JavaScript String.prototype.replace () işleviyle aynı sözdizimidir.
Elde edilen URL göreli ise (yani bir ev sahibiniz yok), orijinal sorgunun kaynağı esas alınacaktır. Her iki durumda da, yeni URL kaynağı paylaşmıyorsa, yeniden yazma başarısız sayılacak ve ilk istek geçecektir.
Ayrıca, güvenlik nedeniyle SCRIPT, SUBDOCUMENT, OBJECT ve OBJECT_SUBREQUEST sorguları için $ yeniden yazma filtreleri göz ardı edilir. Bu seçenek, sorgu parametrelerini değiştirmek veya silmek için kullanışlıdır ».
Tek dezavantajı, değiştirilen dizenin göreceli bir URL olması gerektiğidir; bu, bir ana bilgisayar adı içermemesi ve yeniden yazıldığında, istekle aynı kaynak etki alanına ait olması gerektiği anlamına gelir.
Google haritalarında bile kod yürütme yapılır
Bir güvenlik araştırmacısı açıkladı o:
Belirli koşullar altında, yetkisiz bir kötü amaçlı filtre bakıcısının, belirli bir siteye uzak bir komut dosyasını enjekte eden bir kural oluşturması mümkündür.
Bunu yapmak için, sadece komut dosyaları yükleyen bir site arayın açık bir yönlendirme içeren herhangi bir etki alanından ve XMLHttpRequest veya Fetch kullanın çalıştırılacak komut dosyalarını indirmek için.
Bulması çok zor değildi çünkü bunu yalnız yapmak Google Haritalar'ı kavram kanıtı olarak kullanmanız yeterli.
Araştırmacı şunu açıkladı: aşağıdaki kriterler karşılanmalıdır böylece bir web hizmetinden bu yöntemle yararlanılabilir:
- Sayfa, XMLHttpRequest veya Fetch kullanarak bir JS dizesi yüklemeli ve dönüş kodunu çalıştırmalıdır.
- Sayfa, içerik güvenlik politikası yönergeleri kullanılarak alınabileceği kaynakları kısıtlamamalı veya indirilen kodu çalıştırmadan önce nihai istek URL'sini doğrulamamalıdır.
- Alınan kodun kaynağı, sunucu tarafında açık bir yönlendirmeye veya ana bilgisayardan rastgele kullanıcı içeriğine sahip olmalıdır.
Komut dosyalarını indirmek ve yönlendirmeyi açmak için XMLHttpRequest veya Fetch kullanmak, sorunun iki anahtarıdır.
Bu sorunu azaltmak için, web sitelerinin içerik güvenliği ilkesi başlığını ve connect-src seçeneğini kullanması önerilir komut dosyalarının yüklenebileceği sitelerin beyaz listesini belirtmek için.