html - name - ¿Qué nos protege CSP si permite inseguro en línea?
metadatos html para buscadores (2)
Actualmente estoy habilitando CSP con la siguiente configuración:
Header set Content-Security-Policy: "default-src ''self'' data:; script-src ''self''
''unsafe-inline''; style-src ''self'' ''unsafe-inline''; img-src ''self'' data:"
Parece que no hace mucho para mejorar la seguridad real. El verdadero problema es con JS en línea. Esto puede ser anulado en cualquier momento. Permitir inseguro-en línea no nos protege de mucho, ¿de qué nos protege?
Gracias por tu tiempo.
La opción unsafe-inline debe usarse cuando mover o reescribir el código en línea en su sitio actual no es una opción inmediata, pero aún desea usar CSP para controlar otros aspectos (como object-src, prevenir la inyección de js de terceros, etc. .). Tiene razón en que in unsafe-inline no ofrece mucha seguridad ya que permite la ejecución de scripts in-page inseguros y manejadores de eventos.
El evaluador de CSP de Google es una herramienta ingeniosa para determinar si su política es sólida.
Un caso de uso donde se usa la opción unsafe-inline se puede encontrar en la documentación del Desarrollador web de Google en la Política de seguridad del contenido :
Un administrador del foro de discusión de bodas quiere asegurarse de que todos los recursos solo se carguen a través de canales seguros, pero en realidad no escribe mucho código; Reescribir fragmentos grandes del software de foro de terceros que está repleto de guiones y estilos en línea está más allá de sus capacidades. La siguiente política sería efectiva:
Content-Security-Policy: default-src https:; script-src https: ''unsafe-inline''; style-src https: ''unsafe-inline''Aunque
https:se especifica endefault-src, las directivas de guiones y estilos no heredan automáticamente esa fuente. Cada directiva sobrescribe completamente el valor predeterminado para ese tipo específico de recurso.
Aunque estoy de acuerdo en que no protege de mucho, la explotación clásica de XSS es el marco de explotación del navegador, donde tienes un servidor en Internet, y cuando obtienes un agujero en XSS, aparece "http://bad.example.com /hook.js "> y ahora puede controlar el navegador de la víctima desde ese servidor. Le dice que abra una ventana oculta para mantener el acceso, y luego tiene comunicaciones bidireccionales con su navegador.
Un CSP con "inseguro en línea" aún permite potencialmente la misma explotación (suponiendo que los exploits quepan en el espacio que puede inyectar), pero es marginalmente más difícil conectarse con el mundo exterior para recibir instrucciones o para filtrar datos.
Dicho esto, creo que todavía es posible hacer la mayoría de los mismos ataques a través de otros canales si puede inyectar una parte de cliente sofisticada en una página web.
Con mi sombrero de atacante en "auto inseguro en línea" es más difícil de explotar que ningún CSP en absoluto. Espero que las herramientas de ataque se adapten a CSP débiles, pero significará que muchos de los exploits comunes están inmediatamente fuera de juego o más difíciles.