Es CSP suficiente para prevenir ataques XSS [duplicado]

  

Suponiendo que los usuarios utilizan navegadores modernos, ¿es suficiente implementar una política estricta de CSP para evitar todos los ataques XSS?

No todos los navegadores modernos implementan CSP (IE tiene un soporte muy limitado). Pero suponiendo que el navegador tenga el soporte de CSP adecuado y que su CSP sea muy estricto (¡no es inseguro-eval!), Entonces puede usarse para prevenir XSS con éxito. Pero ...

  

Estoy trabajando en una aplicación Backbone, y me pregunto si todavía tengo que ser datos de usuario de escape en el cliente para mostrar todo el tiempo.

Hay otros ataques aparte de XSS. Si no se escapa adecuadamente, la inyección de HTML puede seguir utilizándose para afectar las partes de la página que no están cubiertas por el CSP, como:

• Incluir enlaces ( <a href=... ) que apuntan a recursos controlados por el atacante. Dependiendo de la página, también se pueden cambiar los enlaces existentes.
• Incluir nuevos formularios o cambiar el destino de envío para los formularios existentes. De esta manera usted podría tomar datos confidenciales.
• Redirige al usuario a las descargas automáticas al incluir HTML con la actualización meta.
• una posible más

La Política de seguridad de contenido (CSP) es solo una capa de seguridad que ayuda a detectar y mitigar ciertos tipos de ataques, incluidos los scripts entre sitios (XSS) y los ataques de inyección de datos. Sin embargo, tenga en cuenta que la seguridad tiene que ver con defensa en profundidad , por lo que sí, aún debe implementar capas de seguridad adicionales y recuerde que la prevención de las vulnerabilidades de ataques de scripts entre sitios en todos los idiomas requiere dos consideraciones principales :

• el tipo de saneamiento realizado en la entrada
  
• ubicación en la que se inserta esa entrada.
  

Es importante recordar que no importa qué tan bien se filtre la entrada; no existe un único método de saneamiento que pueda evitar todas las secuencias de comandos entre sitios (XSS).

El filtrado requerido depende en gran medida del contexto en el que se insertan los datos. La prevención de XSS con datos insertados entre elementos HTML es muy sencilla. Por otro lado, la prevención de XSS con datos insertados directamente en el código JavaScript es considerablemente más difícil y, a veces, imposible.

Para la mayoría de las aplicaciones PHP, htmlspecialchars () será tu mejor amigo. htmlspecialchars () provisto sin argumentos convertirá caracteres especiales a entidades HTML.

Existe otra función que es casi idéntica a htmlspecialchars (). htmlenities () realiza el mismo saneamiento funcional en caracteres peligrosos, sin embargo, codifica todas las entidades de caracteres cuando hay una disponible.

strip_tags () no se debe utilizar exclusivamente para desinfectar datos. strip_tags () elimina el contenido entre las etiquetas HTML y no puede evitar las instancias XSS que existen dentro de los atributos de la entidad HTML. strip_tags () tampoco filtra ni codifica los paréntesis de ángulo de cierre no emparejados. Un atacante puede combinar esto con otras debilidades para inyectar JavaScript completamente funcional en la página.

Addedlashes () se usa a menudo para evitar la entrada cuando se inserta en las variables de JavaScript.

No, esto se debe en parte al soporte del navegador. Por ejemplo, Internet Explorer solo admite parcialmente las Políticas de seguridad de contenido .

Además, un CSP debe verse como una solución secundaria eficaz para XSS. Piense en ello como en la protección contra el código donde el desarrollador ha olvidado generar la codificación correctamente. Esto protegerá su aplicación en los navegadores compatibles mientras se crea la solución y antes de implementarla en sus sistemas de producción.

La codificación correcta de la salida garantiza el cumplimiento de los estándares web, lo que aumenta la seguridad y la funcionalidad. Por ejemplo, no querría que su aplicación web se muestre incorrectamente si el usuario ha decidido poner <> caracteres en sus entradas.

Además, puede ser posible que usuarios nefarios rompan su sitio de otras maneras, a pesar del CSP. Por ejemplo, incluir otros scripts de fuentes permitidas, o incluirlos dos veces para crear una Denegación de Servicio para otros usuarios donde se muestra la salida (ya que el duplicado rompe la lógica de la página). Un atacante también podría editar el contenido de su sitio de otras maneras.

En resumen, recomendaría no utilizar funciones de seguridad adicionales para cortar esquinas en otros lugares. Deben ser complementarios: siempre piense en defensa en profundidad .