Nylig en sårbarhet er oppdaget som kan tillate vedlikeholdere å blokkere filterlister for Adblock Plus, AdBlock og uBlocker nettleserutvidelser for å lage filtre som injiserer eksterne skript på nettsteder.
Med en brukerbase som har krysset 10 millioner, hvis ondsinnede skript ble injisert i annonseblokkere, ville dette ha betydelig innvirkning Fordi de kan utføre uønskede aktiviteter, for eksempel tyveri av informasjonskapsler, tilkoblingsinformasjon, forårsaker viderekoblinger eller annen uønsket oppførsel.
For de som ikke er kjent med annonseblokkere, i utgangspunktet bruker de URL-lister relatert til ondsinnede annonser og atferd.
vanligvis De drives av et lite team av mennesker eller til og med en enkelt person.
Når disse listene er lastet med en annonse-blokkerende utvidelse som Adblock Plus, forhindrer denne utvidelsen nettleseren fra å koble seg til URL-ene som er satt i listen, og dermed forhindrer dette tilkobling til ondsinnede annonser eller skript.
Alternativet $ omskriv filter forårsaker problemet
Når AdblockerPlus 3.2 lansert i 2018, den lagt til et nytt filterlistealternativ, kalt $ rewrite.
Dette alternativet tillatt til en listeholder erstatt en nettforespørsel som samsvarer med et vanlig uttrykk spesielt med en annen URL.
Hubert Figuiere, som introduserte denne funksjonen, forklarte at:
“Siden Adblock Plus 3.2 for Chrome, Firefox og Opera (og utviklingsversjoner av 3.1.0.2053), lar et nytt filteralternativ $ rewrite deg omskrive URL-en til en ressurs i stedet for å blokkere den.
Når Adblock Plus tilordner en forespørsel-URL til et filter med alternativet $ omskriving, forvandler den URL-en basert på den angitte regelen og ber nettleseren om å laste inn ressursen samtidig.
Syntaksen til $ -regelen rewrite angir en streng som fungerer som mal for den nye URL-en.
$ n erstattes av filterets regulære uttrykk n-th sub-match. Dette er den samme syntaksen som JavaScript String.prototype.replace () -funksjonen.
Hvis den resulterende URL-en er relativ (dvs. at du ikke har en vert), opprinnelsen til den opprinnelige spørringen vil bli lagt til grunn. I begge tilfeller, hvis den nye URL-en ikke deler opprinnelsen, vil omskrivingen bli ansett som mislykket, og den første forespørselen vil bestå.
Også $ omskrivningsfiltre blir ignorert for SCRIPT, SUBDOCUMENT, OBJECT og OBJECT_SUBREQUEST-spørsmål av sikkerhetsgrunner. Dette alternativet er praktisk å endre eller slette søkeparametere ».
Den eneste ulempen er at erstatningsstrengen må være en relativ URL, noe som betyr at den ikke inneholder et vertsnavn, og når den skrives om, må den tilhøre samme opprinnelige domene som forespørselen.
Kodeutførelse gjøres til og med på google maps
En sikkerhetsforsker forklarte at:
Under visse forhold er det mulig for en uautorisert skadelig filtervedlikeholder å opprette en regel som injiserer et eksternt skript i et bestemt nettsted.
For å gjøre dette, bare se etter et nettsted som laster inn skript fra ethvert domene som inneholder en åpen omdirigering og bruk XMLHttpRequest eller Fetch for å laste ned skriptene for å kjøre.
Det var ikke så vanskelig å finne for å gjøre dette alene bare bruk Google Maps som bevis på konseptet.
Forskeren forklarte det følgende kriterier må være oppfylt slik at en nettjeneste kan utnyttes med denne metoden:
- Siden må laste inn en JS-streng ved hjelp av XMLHttpRequest eller Fetch og utføre returkoden.
- Siden skal ikke begrense kildene som den kan hentes fra ved hjelp av retningslinjene for innholdssikkerhet, eller validere den endelige forespørsels-URLen før den nedlastede koden kjøres.
- Kilden til den hentede koden må ha en åpen omdirigering på serversiden eller vilkårlig brukerinnhold fra verten.
Å bruke XMLHttpRequest eller Fetch for å laste ned skript og åpne omdirigering er de to nøklene til problemet.
For å redusere dette problemet, det anbefales at nettsteder bruker innholdssikkerhetspolicyoverskriften og alternativet connect-src for å spesifisere en hvitliste over nettsteder der manus kan lastes inn.