En las extensiones de navegador, el impacto de una vulnerabilidad depende en gran medida del contexto y de los permisos solicitados. Existen herramientas estáticas (JSHint, validador AMO) para verificar el código, pero ninguna de ellas es 100% confiable, especialmente para el código ofuscado.

Por lo tanto, no voy a mostrar una expresión regular mágica que le indique si un código es vulnerable o no, pero le daré una breve descripción de cómo funcionan las extensiones y una pequeña lista de posibles problemas específicos de la extensión.

Herramientas existentes

La herramienta de análisis de código estático de Mozilla, utilizada en addons.mozilla.org está disponible públicamente como AMO Validator . Esta herramienta funciona para todos los complementos basados en Jetpack . En primer lugar, identifica (mediante hash) y excluye todas las bibliotecas JS incluidas en la lista blanca. Luego, ejecuta estos casos de prueba en el contenido restante del archivo XPI.

Ninguno de los otros proveedores ha publicado una herramienta de este tipo. Afortunadamente, las extensiones (no los complementos) para Chrome / Safari / Opera no pueden obtener tantos privilegios como los complementos de Firefox.

Extracción

Los complementos de Firefox (xpi) y Opera (oex) son archivos zip con una extensión diferente.
Las extensiones de Chrome (crx) son archivos zip con un encabezado CRX anterior.
Las extensiones de Safari (safariextz) son archivos xar firmados.

7-zip es capaz de extraer todos estos archivos.

Permisos

Chrome, Safari y Opera requieren que el desarrollador de la extensión declare los permisos para acceder a ciertos orígenes o características. Estas declaraciones se pueden encontrar en:

• Chrome: /manifest.json . Consulte patrones de coincidencia y advertencias de permiso
• Safari: /<extension-name>.safariextension/Info.plist . Consulte Acceso y permisos .
• Ópera: /config.xml . Consulte config.xml .

El acceso al origen no se puede configurar en los complementos de Firefox.

Scripts de contenido / Scripts inyectados

Todos los entornos de extensión admiten la ejecución de código en páginas que coinciden con un patrón de URL predefinido. Estos se llaman scripts de contenido en Chrome / Firefox, y scripts inyectados en Opera / Safari. Estos scripts tienen acceso directo al DOM de la página, pero no acceso directo a las variables de JavaScript de la página, porque los contextos de ejecución difieren.

Páginas de fondo

Estas páginas son la parte más privilegiada de una extensión.

Vulnerabilidades

No voy a mencionar errores obvios, como el uso de setTimeout con cadenas (estos ya se mencionan en la respuesta de Bobince), o los métodos inverosímiles que probablemente no sean accidentales, como una extensión que obtiene credenciales de una página y la envía a un servicio web malicioso.

• Usar .innerHTML o jQuery para analizar external HTML (consulte esta pregunta sobre el desbordamiento de pila ):

  // Example 1:
  var heading = $(xhr.responseText).find('h1').text();
  // Example 2:
  document.body.innerHTML += '';
  // For: <img src="bogus" onerror="do_something_evil_with_privileges()">
  

• Uso del evento window.onmessage sin validar los datos o verificar event.origin . En el siguiente ejemplo, cualquier tercero puede usar window.open y postMessage para enviar un mensaje a Gmail, y abusar de las funciones que se han filtrado involuntariamente:

  // Content script running on https://mail.google.com/mail/
  addEventListener('message', function(event) {
      if (event.data.type === 'send-mail') doSomething();
      // or:
      notifyBackgroundPage(event.data);
  });
  

• Cargando código externo (JS) (peor: cargar código externo a través de http). Si la fuente externa está comprometida, todos los usuarios serán susceptibles de abuso.

• Uso de marcos de extensión de navegador cruzado como Crossrider y Kango . Son convenientes para los desarrolladores, pero las extensiones generadas solicitan un número innecesario de permisos.

• No restringe suficientemente la influencia de una API de extensión. Un ejemplo extremo: eliminar la marca de cookie httpOnly para todos los sitios, en lugar de solo el sitio relevante. Esto también incluye ejecutar scripts de contenido en demasiadas páginas.

• Problemas de privacidad:

  • Uso de servicios como Google Analytics (búsqueda de _gaq.push )
  • Cargando activos externos, como botones de redes sociales.

La mayoría de los vectores regulares también son relevantes para las extensiones. Utilice las hojas de trucos en enlace o eche un vistazo a enlace .

Formas comunes de inyectar JS desde JS.

En casi todas las circunstancias, lo que está mal:

• eval
• new Function()
• setTimeout y setInterval con una cadena para el primer parámetro
• setAttribute (o equivalente de marco, por ejemplo, attr() ) en un atributo de controlador de eventos (o nombre de atributo variable) on...
• javascript: URLs

Puede ser necesario en circunstancias limitadas, pero se debe mantener al mínimo y las instancias restantes deben ser cuidadosamente auditadas:

• createElement('script') y configurando el texto del cuerpo
• asignando una URL externa variable a <script> o <link>
• a través de inyección HTML: establecer innerHTML en una cadena que se creó con una variable sin escape, por ejemplo, div.innerHTML= '<p>'+message+'</p>' . Por lo general, se reemplaza mejor con métodos de creación de contenido de estilo DOM (especialmente dado un marco para facilitarlo); para algunos casos, como enormes tablas largas, puede ser necesaria una solución que involucre la creación de marcas
• inyección HTML oculta detrás de una función de marco, por ejemplo, cualquiera de las funciones de manipulación de jQuery ( .html() , .append() , .before() etc.) invocadas con un argumento de cadena (use el método abreviado $('<div>', {dynamic attributes}) en su lugar)

Puede ser inevitable en algunos casos, pero es necesario verificar:

• usando una URL variable al navegar por location , crear un enlace, o configurar la imagen / objeto / iframe / etc src (o new Image() , o CSS url() propiedades). Existen esquemas de URL peligrosos (incluidos, entre otros, javascript: ), por lo que es necesario incluirlos en la lista blanca. Este es un problema muy común en las extensiones de navegador, que a menudo termina haciendo un XSS universal
• Inyección de CSS en el contenido establecido en style elemento / atributo (utilizando propiedades peligrosas como enlaces y expresiones para elevar a JS inyección)

No estoy seguro de cómo se aplicaría a las extensiones del navegador, pero en las aplicaciones web generalmente busco cadenas codificadas para concatenar con variables. A menudo no es un problema, pero me ayuda a encontrar lugares donde HTML se está creando a partir de la información sin formato del usuario. Por ejemplo, el código podría verse como:

var myHtml = "<h1>" + userinput + "</h1>";

Esto no es seguro porque la entrada del usuario puede contener HTML (incluido el script), y debe ser HTML escapado antes de ser utilizado de esta manera.

Aquí hay una expresión regular que encuentra casos de cadenas codificadas que concatenan con variables:

["']\s*\+|\+\s*["']