Recentment s'ha descobert una vulnerabilitat que podria permetre als mantenidors de bloquejar les llistes de filtres per Adblock Plus, AdBlock i les extensions de navegador uBlocker per a crear filtres que injectin scripts remots en els llocs web.
Amb una base d'usuaris que ha creuat la marca dels 10 milions, si s'injectessin scripts maliciosos en els bloquejadors d'anuncis, això tindria un impacte considerable perquè podrien realitzar activitats no desitjades, com el robatori de cookies, informació connexió, causant redireccions de pàgina o un altre comportament no desitjat.
Per a aquells que no estan familiaritzats amb els bloquejadors de publicitat, bàsicament aquestes utilitzen llistes d'URL relacionades amb anuncis i comportaments maliciosos.
En general, són dirigits per un petit equip de persones o fins i tot una sola persona.
Quan aquestes llistes es carreguen amb una extensió de bloqueig d'anuncis com Adblock Plus, aquesta extensió evitarà que el navegador es connecti a les URL posades en la llista i per tant això evita la connexió a anuncis o scripts maliciosos.
L'opció de filtre $ rewrite és la causant de el problema
Quan Adblocker Plus 3.2 es va llançar en 2018, es va agregar una nova opció de llista de filtres, anomenada $ rewrite.
aquesta opció permetre a un mantenidor de llistes reemplaçar una sol·licitud web que coincideixi amb una expressió regular en particular amb un altre URL.
Hubert Figuière, qui va introduir aquesta funció, va explicar que:
«Des Adblock Plus 3.2 per Chrome, Firefox i Opera (i versions de desenvolupament de l'3.1.0.2053), una nova opció de filtre $ rewrite li permet tornar a escriure la URL Un recurs en lloc de bloquejar-lo.
Quan Adblock Plus assigna un URL de sol·licitud a un filtre amb l'opció $ rewrite, transforma l'URL segons la regla proveïda i li diu a el navegador que carregui el recurs a el mateix temps ».
La sintaxi de la regla de $ rewrite especifica una cadena que serveix com a plantilla per a la nova URL.
$ N se substitueix per l'expressió regular n-th sub-match de l'filtre. És la mateixa sintaxi que la funció String.prototype.replace () de JavaScript.
Si l'URL resultant és relativa (És a dir, no té un host), l'origen de la consulta original es farà servir com a base. En qualsevol cas, si la nova URL no comparteix l'origen, la reescriptura es considerarà com fallida i la sol·licitud inicial es passarà.
«A més, els filtres $ rewrite s'ignoren per a les consultes SCRIPT, SUBDOCUMENT, OBJECT i OBJECT_SUBREQUEST per raons de seguretat. Aquesta opció és convenient per a modificar o eliminar paràmetres de consulta ».
L'únic inconvenient és que la cadena de reemplaçament ha de ser un URL relativa, el que significa que no conté un nom de host i que, quan es reescriu, ha de pertànyer a el mateix domini d'origen que la sol·licitud.
L'execució de codi fins i tot es realitza en Google Maps
Un investigador de seguretat va explicar que:
sota certes condicions, és possible que un mantenidor de filtres maliciós no autoritzat creu una regla que injecta un script remot en un lloc en particular.
Per fer això, només s'ha de buscar un lloc que carregui seqüències d'ordres de qualsevol domini que contingui un redireccionament obert i utilitzeu XMLHttpRequest o Fetch per descarregar les seqüències d'ordres per executar.
No va ser massa difícil de trobar perquè per fer això només només cal fer servir de Google Maps com a prova de concepte.
L'investigador va explicar que s'han de complir els següents criteris perquè un servei web pugui explotar-se amb aquest mètode:
- La pàgina ha de carregar una cadena JS utilitzant XMLHttpRequest o Fetch i executar el codi retornat.
- La pàgina no ha de restringir els orígens des dels quals es pot recuperar mitjançant les directrius de la política de seguretat de contingut, ni validar l'URL de sol·licitud final abans d'executar el codi descarregat.
- L'origen d'el codi recuperat ha de tenir un redireccionament obert de la banda de servidor o contingut d'usuari arbitrari de l'amfitrió.
L'ús de XMLHttpRequest o Fetch per descarregar scripts i obrir la redirecció són les dues claus de el problema.
Per mitigar aquest problema, es recomana que els llocs web facin servir la capçalera de política de seguretat de contingut i l'opció connect-src per especificar una llista blanca de llocs des dels quals es poden carregar els scripts.