Recientemente kerentanan telah ditemukan yang memungkinkan pengelola memblokir daftar filter untuk ekstensi browser Adblock Plus, AdBlock dan uBlocker untuk membuat filter yang memasukkan skrip jarak jauh ke dalam situs web.
Dengan basis pengguna yang telah melampaui angka 10 juta, jika skrip berbahaya disuntikkan ke pemblokir iklan, ini akan berdampak besar karena mereka dapat melakukan aktivitas yang tidak diinginkan, seperti pencurian cookie, informasi koneksi, menyebabkan pengalihan halaman atau perilaku yang tidak diinginkan lainnya.
Bagi mereka yang tidak terbiasa dengan pemblokir iklan, mereka pada dasarnya menggunakan daftar URL terkait dengan iklan dan perilaku berbahaya.
Umumnya Mereka dijalankan oleh sekelompok kecil orang atau bahkan satu orang.
Saat daftar ini dimuat dengan ekstensi pemblokiran iklan seperti Adblock Plus, ekstensi ini akan mencegah browser terhubung ke URL yang dimasukkan ke dalam daftar dan dengan demikian ini mencegah koneksi ke iklan atau skrip berbahaya.
Opsi filter $ rewrite menyebabkan masalah
Ketika Adblocker Plus 3.2 diluncurkan pada 2018, itu menambahkan opsi daftar filter baru, yang disebut $ rewrite.
Opsi ini diizinkan ke pengelola daftar mengganti permintaan web yang cocok dengan ekspresi reguler khususnya dengan URL lain.
Hubert Figuiere, yang memperkenalkan fungsi ini, menjelaskan bahwa:
“Sejak Adblock Plus 3.2 untuk Chrome, Firefox dan Opera (dan versi pengembangan 3.1.0.2053), opsi filter baru $ rewrite memungkinkan Anda menulis ulang URL sumber daya alih-alih memblokirnya.
Saat Adblock Plus memberikan URL permintaan ke filter dengan opsi $ rewrite, itu mengubah URL berdasarkan aturan yang disediakan dan memberi tahu browser untuk memuat sumber daya pada saat yang sama.
Sintaks dari $ rule rewrite menentukan string yang berfungsi sebagai template untuk URL baru.
$ n diganti dengan ekspresi reguler n-th sub-match filter. Ini adalah sintaks yang sama dengan fungsi JavaScript String.prototype.replace ().
Jika URL yang dihasilkan relatif (mis. Anda tidak memiliki host), asal dari kueri asli akan digunakan sebagai dasar. Dalam kedua kasus tersebut, jika URL baru tidak membagikan asal, penulisan ulang akan dianggap tidak berhasil dan permintaan awal akan lolos.
Selain itu, filter $ rewrite diabaikan untuk kueri SCRIPT, SUBDOCUMENT, OBJECT, dan OBJECT_SUBREQUEST karena alasan keamanan. Opsi ini nyaman untuk mengubah atau menghilangkan parameter kueri ».
Satu-satunya downside adalah bahwa string pengganti harus berupa URL relatif, yang berarti tidak mengandung nama host dan, ketika ditulis ulang, itu harus dimiliki oleh domain asal yang sama dengan yang diminta.
Eksekusi kode bahkan dilakukan di google maps
Seorang peneliti keamanan menjelaskan apa:
Dalam kondisi tertentu, ada kemungkinan untuk pengelola filter berbahaya yang tidak sah untuk membuat aturan yang memasukkan skrip jarak jauh ke situs tertentu.
Untuk melakukan ini, cari saja situs yang memuat skrip dari domain mana pun yang berisi pengalihan terbuka dan gunakan XMLHttpRequest atau Fetch untuk mengunduh skrip untuk dijalankan.
Tidak terlalu sulit untuk menemukannya karena melakukan ini sendirian cukup gunakan Google Maps sebagai bukti konsep.
Peneliti menjelaskan hal itu kriteria berikut harus dipenuhi sehingga layanan web dapat dimanfaatkan dengan metode ini:
- Halaman tersebut harus memuat string JS menggunakan XMLHttpRequest atau Fetch dan menjalankan kode yang dikembalikan.
- Halaman tidak boleh membatasi sumber yang dapat diambilnya menggunakan pedoman kebijakan keamanan konten, atau memvalidasi URL permintaan akhir sebelum menjalankan kode yang didownload.
- Sumber kode yang diambil harus memiliki pengalihan sisi server terbuka atau konten pengguna arbitrer dari host.
Menggunakan XMLHttpRequest atau Fetch untuk mengunduh skrip dan membuka pengalihan adalah dua kunci untuk masalah ini.
Untuk mengurangi masalah ini, disarankan agar situs web menggunakan header kebijakan keamanan konten dan opsi sambungkan-src untuk menentukan daftar putih situs tempat skrip dapat dimuat.