Nyligen en sårbarhet har upptäckts vilket kan göra det möjligt för underhållare att blockera filterlistor för webbläsartillägg Adblock Plus, AdBlock och uBlocker för att skapa filter som injicerar fjärrskript till webbplatser.
Med en användarbas som har passerat 10 miljoner om skadliga skript injicerades i annonsblockerare skulle detta ha en betydande inverkan eftersom de kan utföra oönskade aktiviteter, såsom stöld av kakor, anslutningsinformation, orsakar sidomdirigeringar eller annat oönskat beteende.
För de som inte känner till annonsblockerare, de använder i princip URL-listor relaterade till skadliga annonser och beteenden.
vanligtvis De drivs av ett litet team av människor eller till och med en enda person.
När dessa listor laddas med ett tillägg för annonsblockering som Adblock Plus, förhindrar detta tillägg webbläsaren från att ansluta till webbadresserna i listan och detta förhindrar anslutning till skadliga annonser eller skript.
Alternativet $ omskrivningsfilter orsakar problemet
När AdblockerPlus 3.2 lanserades 2018, det lagt till ett nytt filterlistalternativ, kallat $ rewrite.
Detta alternativ tillåten till en listhållare ersätt en webbbegäran som matchar ett reguljärt uttryck särskilt med en annan URL.
Hubert Figuiere, som introducerade den här funktionen, förklarade att:
”Eftersom Adblock Plus 3.2 för Chrome, Firefox och Opera (och utvecklingsversionerna 3.1.0.2053) tillåter ett nytt alternativ för $ omskrivningsfilter dig att skriva om URL-adressen till en resurs istället för att blockera den.
När Adblock Plus tilldelar en begäran-URL till ett filter med alternativet $ omskrivning, omvandlar den webbadressen baserat på den angivna regeln och ber webbläsaren att ladda resursen samtidigt.
Syntaxen för $ -regeln omskrivning anger en sträng som fungerar som en mall för den nya webbadressen.
$ n ersätts av filterets reguljära uttryck n-th sub-match. Detta är samma syntax som funktionen JavaScript String.prototype.replace ().
Om den resulterande webbadressen är relativ (dvs du har ingen värd), ursprunget till den ursprungliga frågan kommer att användas som grund. I båda fallen, om den nya webbadressen inte delar ursprunget, kommer omskrivningen att anses vara misslyckad och den ursprungliga begäran kommer att passera.
Omskrivningsfilter för $ ignoreras också för SCRIPT-, SUBDOCUMENT-, OBJECT- och OBJECT_SUBREQUEST-frågor av säkerhetsskäl. Det här alternativet är praktiskt för att modifiera eller eliminera frågeparametrar ».
Den enda nackdelen är att ersättningssträngen måste vara en relativ webbadress, vilket innebär att den inte innehåller ett värdnamn, och när den skrivs om måste den tillhöra samma domän med ursprung som begäran.
Kodkörning görs även på google maps
En säkerhetsforskare förklarade att:
Under vissa förhållanden är det möjligt för en obehörig skadlig filterhållare att skapa en regel som injicerar ett fjärrskript till en viss webbplats.
För att göra detta, leta bara efter en webbplats som laddar skript från alla domäner som innehåller en öppen omdirigering och använd XMLHttpRequest eller Fetch för att ladda ner skript för att köra.
Det var inte så svårt att hitta för att göra det ensam använd bara Google Maps som ett bevis på konceptet.
Forskaren förklarade det följande kriterier måste vara uppfyllda så att en webbtjänst kan utnyttjas med den här metoden:
- Sidan måste ladda en JS-sträng med XMLHttpRequest eller Hämta och köra returkoden.
- Sidan bör inte begränsa källorna från vilken den kan hämtas med riktlinjer för innehållssäkerhetspolicy, eller validera den slutliga begäran URL innan den nedladdade koden körs.
- Källan till den hämtade koden måste ha en öppen omdirigering på serversidan eller godtyckligt användarinnehåll från värden.
Att använda XMLHttpRequest eller Fetch för att ladda ner skript och öppna omdirigeringen är de två nycklarna till problemet.
För att mildra detta problem, Det rekommenderas att webbplatser använder sidhuvudet för innehållssäkerhetspolicy och alternativet connect-src för att ange en vitlista över webbplatser från vilka skript kan laddas.