nemrég sebezhetőséget fedeztek fel amely lehetővé teheti a fenntartók számára a szűrőlisták blokkolását az Adblock Plus, az AdBlock és az uBlocker böngészőbővítményekhez szűrők létrehozására, amelyek távoli parancsfájlokat injektálnak a webhelyekre.
A 10 milliót átlépő felhasználói bázissal ha rosszindulatú szkripteket fecskendeznének a hirdetésblokkolókba, ennek jelentős hatása lenne mert nem kívánt tevékenységeket hajthatnak végre, például cookie-k lopását, kapcsolati információkat, oldalátirányításokat vagy más nem kívánt viselkedést okozva.
Azoknak, akik nem ismerik a hirdetésblokkolókat, alapvetően URL-listákat használnak rosszindulatú hirdetésekkel és viselkedéssel kapcsolatos.
általában Kis csoport ember, vagy akár egyetlen ember irányítja őket.
Amikor ezek a listák olyan hirdetésblokkoló kiterjesztéssel vannak betöltve, mint az Adblock Plus, ez a kiterjesztés megakadályozza, hogy a böngésző csatlakozzon a listában szereplő URL-ekhez, és ez megakadályozza a kapcsolatot a rosszindulatú hirdetésekkel vagy szkriptekkel.
A $ rewrite filter opció okozza a problémát
Mikor AdblockerPlus 3.2 2018-ban indult el hozzáadott egy új szűrőlista opciót, $ rewrite néven.
Ez az opció megengedett listakezelőnek cserélje ki a webes kérelmet, amely megfelel egy reguláris kifejezésnek különösen egy másik URL-lel.
Hubert Figuiere, aki bevezette ezt a funkciót, kifejtette, hogy:
„Mivel az Adblock Plus 3.2 Chrome, Firefox és Opera (és a 3.1.0.2053 fejlesztői verziói) óta az új $ rewrite szűrő opció lehetővé teszi, hogy blokkolás helyett átírja egy erőforrás URL-jét.
Amikor az Adblock Plus a $ rewrite opcióval hozzárendel egy kérelem URL-jét egy szűrőhöz, akkor a megadott szabály alapján átalakítja az URL-t, és felszólítja a böngészőt, hogy egyidejűleg töltse be az erőforrást.
A $ szabály szintaxisa rewrite megad egy karakterláncot, amely sablonként szolgál az új URL-hez.
A $ n helyére a szűrő n-edik részegyezésének reguláris kifejezése lép. Ez ugyanaz a szintaxis, mint a JavaScript String.prototype.replace () függvény.
Ha a kapott URL relatív (vagyis nincs gazdája), az eredeti lekérdezés eredetét vesszük alapul. Mindkét esetben, ha az új URL nem osztja meg az eredetet, az újraírás sikertelennek minősül, és a kezdeti kérelem sikeres lesz.
A $ átírási szűrőket biztonsági okokból figyelmen kívül hagyják a SCRIPT, SUBDOCUMENT, OBJECT és OBJECT_SUBREQUEST lekérdezéseknél. Ez az opció kényelmes a lekérdezési paraméterek módosítására vagy kiküszöbölésére ».
Az egyetlen hátrány, hogy a helyettesítő karakterláncnak relatív URL-nek kell lennie, ami azt jelenti, hogy nem tartalmaz hosztnevet, és átírásakor ugyanahhoz a származási tartományhoz kell tartoznia, mint a kérelem.
A kód végrehajtása még a Google Maps-en is megtörténik
Egy biztonsági kutató elmagyarázta hogy:
Bizonyos feltételek mellett egy jogosulatlan rosszindulatú szűrő-karbantartó létrehozhat olyan szabályt, amely távoli parancsfájlt injektál egy adott webhelyre.
Ehhez csak keressen egy webhelyet, amely szkripteket tölt be bármely olyan domainről, amely nyitott átirányítást tartalmaz és használja az XMLHttpRequest vagy a Fetch parancsot a futtatáshoz szükséges szkriptek letöltéséhez.
Nem volt túl nehéz megtalálni, mert ezt egyedül csinálni csak használja a Google Maps-et a koncepció bizonyítékaként.
A kutató ezt elmagyarázta a következő kritériumoknak kell teljesülniük hogy egy webszolgáltatás kihasználható legyen ezzel a módszerrel:
- Az oldalnak be kell töltenie egy JS karakterláncot az XMLHttpRequest vagy a Fetch használatával, és végre kell hajtania a visszatérési kódot.
- Az oldalnak nem szabad korlátoznia azokat a forrásokat, amelyekből a tartalombiztonsági irányelvek segítségével lekérhető, vagy a letöltött kód futtatása előtt érvényesítenie kell a végső kérelem URL-jét.
- A lekért kód forrásának nyitott kiszolgálóoldali átirányítással vagy tetszőleges felhasználói tartalommal kell rendelkeznie a gazdagéptől.
Az XMLHttpRequest vagy a Fetch használata a parancsfájlok letöltéséhez és az átirányítás megnyitásához a probléma kulcsa.
A probléma enyhítése érdekében javasoljuk, hogy a webhelyek használják a tartalombiztonsági irányelv fejlécét és a connect-src beállítást annak a webhelynek az engedélyezési listájához, ahonnan szkriptek tölthetők be.