¿Es la política de seguridad de contenido un enfoque que vale la pena apoyar?

6

Mozilla Firefox 4.0 admite algo llamado Política de seguridad de contenido que deshabilita la interpretación de Java Script incrustado . Solo se ejecutan los archivos Java Script externos a los que se hace referencia usando una etiqueta de script y que están en un dominio de la lista blanca.

Actualmente solo Mozilla Firefox 4.0 lo admite, pero es un borrador de W3C .

Dado que volver a escribir una aplicación web existente para dejar de usar los atributos on es mucho trabajo, surge la pregunta, si vale la pena.

¿Es probable que otros navegadores lo admitan? ¿Existen formas conocidas de eludir la protección (asumiendo que los archivos .js son estáticos)?

    
pregunta Hendrik Brummermann 28.03.2011 - 16:48
fuente

3 respuestas

7

CSP, junto con el indicador de seguridad de cookie HTTP, HSTS y X-FRAME-OPTIONS, siempre serán mis encabezados de respuesta HTTP favoritos para mejorar la seguridad de los usuarios en todo momento.

Consulte también - Habilitación de la seguridad del navegador en aplicaciones web

    
respondido por el atdre 04.04.2011 - 22:06
fuente
5

Creo que este mecanismo tendría un valor real solo en un conjunto específico de circunstancias.

En el caso general, de una aplicación web normal, sería mejor que corrijas el código para que sea seguro para XSS, como escribió @SteveS.

Sin embargo, hay algunos escenarios donde esto no es fácilmente posible, y estos escenarios están creciendo en popularidad. Me refiero al "contenido generado por el usuario", donde debe permitir que los usuarios ingresen (casi) cualquier información, incluido el contenido HTML arbitrario: blogs, sitios de redes sociales, CMS, etc. ...

Ahora, la parte de seguridad de mi parte se está encogiendo, y de inmediato quiero saltar y gritar: "No, no necesitas para hacer eso, ¡encuentra una mejor manera! ". Pero, por supuesto, ese no es realmente el punto ...
Y sí, hay formas indirectas de evitar esa situación, ya que los usuarios ingresan un código HTML arbitrario, ya sea con la inclusión de ciertas etiquetas en la lista blanca o mediante un sistema de marcado alternativo (como Markdown utilizado aquí), pero son una especie de confusión, limitando su funcionalidad y no es trivial para algunos usuarios finales.

En pocas palabras, habrá algunas aplicaciones web que aceptarán HTML arbitrario , por cualquier razón que la empresa considere necesaria, y puede ser contraproducente gritar sobre cómo Es inseguro, porque eso no va a funcionar.
En estos casos, la Política de seguridad de contenido puede agregar un gran valor y mitigar la función XSS en gran medida.

    
respondido por el AviD 29.03.2011 - 08:56
fuente
1

En teoría, es una buena idea, pero creo que la pregunta más importante es: ¿qué está resolviendo esto? Puedo ver que hace la vida más fácil para prevenir XSS, pero aún necesitas generar JavaScript dinámicamente, así que en lugar de atacar la página en sí, solo atacas los archivos .js. Pero dijiste archivos estáticos .js ...

Mi conjetura es que es más un problema que su valor. Es mejor que reescribas tu código para que sea seguro para XSS que confiar en el navegador para cualquier cosa.

    
respondido por el Steve 28.03.2011 - 18:31
fuente

Lea otras preguntas en las etiquetas