¿Se puede prevenir XSS 100% al establecer la política de seguridad de contenido como default-src 'self' ? ¿Hay alguna manera de que XSS pueda suceder en ese caso? Una posibilidad que se me ocurre es inyectar de forma dinámica las entradas de los usuarios en uno de sus scripts en el lado del servidor, ¿está de acuerdo? ¿Hay otras vulnerabilidades en las que puedas pensar?
El CSP en dicha configuración debería habilitar las siguientes medidas de seguridad:
Como tal, XSS debería ser posible solo en los casos en que los recursos en el dominio pueden ser controlados por un atacante, como usted mencionó.
Puede bloquear el CSP aún más configurando default-src 'none' y luego habilitando explícitamente solo los tipos de contenido que espera usar en el sitio. Esto ayuda a reducir aún más su superficie de ataque al deshabilitar tipos de contenido como Flash, applets de Java, SVG, lienzos, etc. cuando no los está utilizando.
Un vector adicional que quizás no haya considerado es Anulaciones de la hoja de estilo relativa al camino (PRSSI) , de lo contrario conocido como vulnerabilidades de sobrescritura de ruta relativa (RPO). Estos funcionan aprovechando el comportamiento de manejo de URL en algunos software de CMS, donde los caracteres de ruta aparecen después de que se toma un script como parámetros (por ejemplo, example.com/wiki/index.php/Something muestra la página Something ). Cuando se incluye una hoja de estilo relativa a la ruta (por ejemplo, main.css en lugar de /main.css ), esto puede abusarse algunas veces. En nuestro ejemplo, debido a que main.css se importa en relación con la ruta actual, una inclusión en la URL de ejemplo anterior podría hacer que el navegador intente cargar example.com/wiki/index.php/main.css como una hoja de estilo. Si puedes crear una página wiki llamada main.css , esto te permitiría controlar el contenido de esa hoja de estilo y potencialmente cargar CSS malicioso (por ejemplo, con la directiva expression ). Puedes hacer lo mismo con las importaciones de JavaScript relativas a la ruta. La solución aquí es siempre hacer referencia al contenido por su ruta canónica completa.
default-src 'self' permite XSS a través de JSONP y ataques de rastreo de tipo de contenido:
De particular interés es nuestra falta de identidad en nuestra lista de fuentes. Mientras La obtención de JavaScript desde uno mismo parece relativamente segura (y extremadamente común), debe evitarse cuando sea posible.
Hay casos de ventaja que cualquier desarrollador debe ocuparse de cuando se permite a sí mismo como una fuente de scripts. Puede haber un olvido Punto final JSONP que no desinfecta el nombre de la función de devolución de llamada. O, otro punto final que sirve contenido influenciado por el usuario con una tipo de contenido que los navegadores pueden rastrear como JavaScript. GitHub tiene varios puntos finales. Por ejemplo, devolvemos commit diffs como texto / plano.
Lea otras preguntas en las etiquetas xss javascript content-security-policy