Nesen ir atklāta ievainojamība kas varētu ļaut uzturētājiem bloķēt filtru sarakstus pārlūka paplašinājumiem Adblock Plus, AdBlock un uBlocker lai izveidotu filtrus, kas vietnēs injicē attālos skriptus.
Ar lietotāju bāzi, kas ir pārsniegusi 10 miljonu robežu, ja reklāmu bloķētājos tiktu ievadīti ļaunprātīgi skripti, tam būtu ievērojama ietekme jo viņi varēja veikt nevēlamas darbības, piemēram, sīkdatņu zādzību, savienojuma informāciju, lapas novirzīšanas izraisīšanu vai citu nevēlamu darbību.
Tiem, kas nav pazīstami ar reklāmu bloķētājiem, viņi pamatā izmanto URL sarakstus kas saistītas ar ļaunprātīgām reklāmām un uzvedību.
Parasti Viņus vada neliela cilvēku komanda vai pat viena persona.
Kad šie saraksti ir ielādēti ar reklāmu bloķēšanas paplašinājumu, piemēram, Adblock Plus, šis paplašinājums neļaus pārlūkprogrammai izveidot savienojumu ar sarakstā iekļautajiem URL, tādējādi novēršot savienojumu ar ļaunprātīgām reklāmām vai skriptiem.
Filmas opcija $ pārrakstīt filtru rada problēmu
Kad Adblocker Plus 3.2 uzsākta 2018. gadā, tā pievienoja jaunu filtru saraksta opciju ar nosaukumu $ rewrite.
Šī opcija atļauts saraksta uzturētājam aizstāt tīmekļa pieprasījumu, kas atbilst regulārajai izteiksmei jo īpaši ar citu URL.
Huberts Figuière, kurš ieviesa šo funkciju, paskaidroja, ka:
“Kopš Adblock Plus 3.2 pārlūkiem Chrome, Firefox un Opera (un 3.1.0.2053 izstrādes versijām) jaunā opcija $ pārrakstīt filtru ļauj pārrakstīt resursa URL, nevis to bloķēt.
Kad Adblock Plus piešķir pieprasījuma URL filtram ar opciju $ pārrakstīt, tas pārveido URL, pamatojoties uz sniegto kārtulu, un liek pārlūkprogrammai vienlaikus ielādēt resursu.
$ Likuma sintakse pārrakstīšana norāda virkni, kas kalpo kā jaunā URL veidne.
$ n tiek aizstāts ar filtra regulārās izteiksmes n-to apakšspeli. Šī ir tā pati sintakse kā funkcijai String.prototype.replace ().
Ja iegūtais URL ir relatīvs (t.i., jums nav saimnieka), par pamatu tiks izmantota sākotnējā vaicājuma izcelsme. Jebkurā gadījumā, ja jaunais URL nedalās ar izcelsmi, pārrakstīšana tiks uzskatīta par neveiksmīgu un sākotnējais pieprasījums tiks izpildīts.
Drošības apsvērumu dēļ vaicājumiem SCRIPT, SUBDOCUMENT, OBJECT un OBJECT_SUBREQUEST tiek ignorēti $ pārrakstīšanas filtri. Šī opcija ir ērta, lai modificētu vai izslēgtu vaicājuma parametrus ».
Vienīgais mīnuss ir tas, ka aizstājošajai virknei jābūt relatīvam URL, kas nozīmē, ka tajā nav resursdatora nosaukuma un, pārrakstot, tai jāpieder pie tā paša domēna kā pieprasījums.
Koda izpilde tiek veikta pat Google Maps
Drošības pētnieks paskaidroja ka:
Noteiktos apstākļos neatļautam ļaunprātīgu filtru uzturētājam ir iespējams izveidot kārtulu, kas ievada attālo skriptu noteiktā vietnē.
Lai to izdarītu, vienkārši meklējiet vietni, kurā tiek ielādēti skripti no jebkura domēna, kurā ir atvērta novirzīšana un izmantojiet XMLHttpRequest vai Fetch lai palaistu skriptus.
Tas nebija pārāk grūti atrast, jo to izdarīt vienatnē vienkārši izmantojiet Google Maps kā koncepcijas pierādījumu.
Pētnieks to paskaidroja jāatbilst šādiem kritērijiem lai tīmekļa pakalpojumu varētu izmantot ar šo metodi:
- Lapai jāielādē JS virkne, izmantojot XMLHttpRequest vai Fetch, un jāizpilda atgriešanās kods.
- Lappuse nedrīkst ierobežot avotus, no kuriem to var iegūt, izmantojot satura drošības politikas vadlīnijas, vai apstiprināt gala pieprasījuma URL pirms lejupielādētā koda izpildes.
- Iegūtā koda avotam jābūt atvērtam servera puses novirzījumam vai patvaļīgam lietotāja saturam no resursdatora.
XMLHttpRequest vai Fetch izmantošana skriptu lejupielādei un novirzīšanas atvēršanai ir divi problēmas taustiņi.
Lai mazinātu šo problēmu, vietnēm ieteicams izmantot satura drošības politikas galveni un connect-src opciju lai norādītu vietņu balto sarakstu, no kurām var ielādēt skriptus.