Onlangs er is een kwetsbaarheid ontdekt waardoor beheerders filterlijsten kunnen blokkeren voor Adblock Plus, AdBlock en uBlocker browserextensies om filters te maken die externe scripts in websites injecteren.
Met een gebruikersbestand dat de grens van 10 miljoen heeft overschreden, als er kwaadaardige scripts in adblockers zouden worden geïnjecteerd, zou dit een aanzienlijke impact hebben omdat ze ongewenste activiteiten kunnen uitvoeren, zoals diefstal van cookies, verbindingsinformatie, het veroorzaken van pagina-omleidingen of ander ongewenst gedrag.
Voor diegene die zijn niet bekend met adblockers, ze gebruiken in feite URL-lijsten gerelateerd aan kwaadaardige advertenties en gedrag.
meestal Ze worden gerund door een klein team van mensen of zelfs door één persoon.
Wanneer deze lijsten worden geladen met een extensie voor het blokkeren van advertenties, zoals Adblock Plus, zal deze extensie voorkomen dat de browser verbinding maakt met de URL's in de lijst en dus wordt de verbinding met kwaadaardige advertenties of scripts voorkomen.
De filteroptie $ rewrite veroorzaakt het probleem
Wanneer AdblockerPlus 3.2 gelanceerd in 2018, it een nieuwe filterlijstoptie toegevoegd, genaamd $ rewrite.
Deze optie toegestaan aan een lijstbeheerder vervang een webverzoek dat overeenkomt met een reguliere expressie in het bijzonder met een andere URL.
Hubert Figuiere, wie heeft deze functie geïntroduceerd, legde uit dat:
“Sinds Adblock Plus 3.2 voor Chrome, Firefox en Opera (en ontwikkelingsversies van 3.1.0.2053), stelt een nieuwe filteroptie $ rewrite je in staat om de URL van een bron te herschrijven in plaats van deze te blokkeren.
Wanneer Adblock Plus een verzoek-URL toewijst aan een filter met de $ rewrite-optie, transformeert het de URL op basis van de verstrekte regel en vertelt het de browser om de bron tegelijkertijd te laden.
De syntaxis van de $ regel rewrite specificeert een tekenreeks die dient als sjabloon voor de nieuwe URL.
$ n wordt vervangen door de n-de subovereenkomst van de reguliere expressie van het filter. Dit is dezelfde syntaxis als de JavaScript-functie String.prototype.replace ().
Als de resulterende URL relatief is (d.w.z. je hebt geen gastheer), de oorsprong van de oorspronkelijke zoekopdracht zal als basis worden gebruikt. In beide gevallen, als de nieuwe URL de oorsprong niet deelt, wordt het herschrijven als niet succesvol beschouwd en zal het oorspronkelijke verzoek slagen.
Ook worden $ herschrijffilters om veiligheidsredenen genegeerd voor SCRIPT-, SUBDOCUMENT-, OBJECT- en OBJECT_SUBREQUEST-zoekopdrachten. Deze optie is handig voor het wijzigen of verwijderen van queryparameters ».
Het enige nadeel is dat de vervangende tekenreeks een relatieve URL moet zijn, wat betekent dat deze geen hostnaam bevat en, wanneer deze wordt herschreven, tot hetzelfde oorspronkelijke domein moet behoren als het verzoek.
Code-uitvoering wordt zelfs gedaan op google maps
Een beveiligingsonderzoeker legde uit dat:
Onder bepaalde omstandigheden is het mogelijk voor een niet-geautoriseerde, kwaadwillende filteronderhouder om een regel te maken die een extern script in een bepaalde site injecteert.
Om dit te doen, zoek gewoon naar een site die scripts laadt vanaf elk domein dat een open omleiding bevat en gebruik XMLHttpRequest of Fetch om de uit te voeren scripts te downloaden.
Het was niet zo moeilijk om dit alleen te doen gebruik Google Maps gewoon als proof of concept.
De onderzoeker legde dat uit aan de volgende criteria moet worden voldaan zodat een webservice kan worden misbruikt met deze methode:
- De pagina moet een JS-string laden met XMLHttpRequest of Fetch en de retourcode uitvoeren.
- De pagina mag de bronnen waaruit deze kan worden opgehaald met behulp van richtlijnen voor inhoudsbeveiligingsbeleid, niet beperken of de uiteindelijke verzoek-URL valideren voordat de gedownloade code wordt uitgevoerd.
- De bron van de opgehaalde code moet een open server-side omleiding of willekeurige gebruikersinhoud van de host hebben.
Het gebruik van XMLHttpRequest of Fetch om scripts te downloaden en de omleiding te openen, zijn de twee sleutels tot het probleem.
Om dit probleem te verminderen, het wordt aanbevolen dat websites de header van het contentbeveiligingsbeleid en de optie connect-src gebruiken om een witte lijst van sites op te geven waarvan scripts kunnen worden geladen.