Proteger a Sus Usuarios Contra ataques XSS basados en DOM

Proteger a sus Usuarios Contra ataques XSS basados en DOM

El script entre sitios (XSS) es uno de los sitios web de ataques de wayshackers más comunes. Las vulnerabilidades XSS permiten a un usuario malicioso extraer trozos arbitrarios de JavaScript cuando otros usuarios visitan su sitio.

XSS es la vulnerabilidad de seguridad reportada públicamente más común, y parte del conjunto de herramientas de cada hacker.

Riesgos

Prevalencia Raras

Explotabilidad Fácil

Impacto Perjudicial

basado en DOM XSS ataques de todos los riesgos asociados con otros tipos de ataque XSS, con theadded bono que son imposibles de detectar desde el lado del servidor.Cualquier página que use fragmentos de URI está potencialmente en riesgo de ataques XSS.

Protección

La protección contra ataques XSS basados en DOM es una cuestión de comprobar que tu Java Script no interprete fragmentos de URI de manera insegura. Existen varias maneras de garantizar esto.

Use un framework JavaScript

Frameworks como AngularJS y React usan plantillas que hacen que la construcción de HTML ad-hoc sea una acción explícita (y rara). Esto impulsará a su equipo de desarrollo hacia las mejores prácticas y hará que las operaciones inseguras sean más fáciles de detectar.

AngularJS

En Angular cualquier contenido dinámico escrito entre corchetes se escapará automáticamente, por lo que lo siguiente es seguro:

 <div>{{dynamicContent}}</div>

Tenga cuidado con cualquier código que vincule contenido dinámico al atributo innerHTML, ya que no se escapará automáticamente:

 <div ="dynamicContent"></div> <div innerHTML="{{dynamicContent}}"></div>
React

En React, cualquier contenido dinámico escrito entre corchetes se escapará automáticamente, por lo que lo siguiente es seguro:

render() { return <div>{dynamicContent}</div>}

React le permite escribir HTML sin procesar vinculando el contenido a la propiedad dangerouslySetInnerHTML, que se nombra para recordarle el riesgo de seguridad. Tenga cuidado con cualquier código que se parezca al siguiente:

render() { return <div dangerouslySetInnerHTML={ __html: dynamicContent } />}
Audite cuidadosamente su Código

A veces, un framework completo de JavaScript es demasiado pesado para su site.In en ese caso, deberá realizar revisiones periódicas del código para localizar las ubicaciones de referencia window.location.hash. Considere la posibilidad de llegar a estándares de codificación acordados sobre cómo se escribirán e interpretarán los fragmentos de URI, y centralice esta lógica en una biblioteca central.

Si utiliza jQuery, compruebe cuidadosamente cualquier código que utilice la funciónhtml(...). Si está construyendo HTML sin procesar en el lado del cliente en la parte posterior de la entrada no confiable, puede tener un problema, ya sea que la entrada provenga de un fragmento de URI o no. Utilice la función text(...) siempre que sea posible.

Si está utilizando las API DOM nativas directas, evite usar las siguientes propiedades y funciones:

  • innerHTML
  • outerHTML
  • document.write

En su lugar, establezca contenido de texto dentro de etiquetas siempre que sea posible:

  • textContent
Analice JSON cuidadosamente

No evalúe JSON para convertirlo en objetos JavaScript nativos, por ejemplo, mediante la función eval(...). En su lugar, use JSON.parse(...).

Detectar Código inseguro Mediante Herramientas de desarrollo

La suite Burp, producida por la empresa de seguridad PortSwigger, se puede utilizar para detectar vulnerabilidades basadas en DOM.

¡No Use Fragmentos De URI En Absoluto!

El código más seguro es el código que no está allí. Si no necesitas usar fragmentos de URI, ¡no lo hagas! Escriba una prueba unitaria para escanear su JavaScript en busca de menciones de window.location.hash, y haga que falle si se encuentra el patrón. Cuando sea necesario usar fragmentos de URI, puede discutir cómo garantizar su uso seguro.

Implementar una Política de seguridad de contenido

Los navegadores modernos admiten políticas de seguridad de contenido Que permiten al autor de una página web controlar desde dónde se puede cargar y ejecutar JavaScript (y otros recursos). Los ataques XSS dependen de que el atacante pueda ejecutar scripts maliciosos en la página web de un usuario, ya sea inyectando etiquetas <script> en línea en algún lugar dentro de la etiqueta <html> de una página, o engañando al navegador para que cargue JavaScript desde un dominio de terceros malicioso.

Al establecer una directiva de seguridad de contenido en el encabezado de respuesta, puede seleccionar el navegador para que nunca ejecute JavaScript en línea y para bloquear qué dominios pueden alojar JavaScript para una página:

Política de Seguridad de Contenidos: auto script-src’ https://apis.google.com

Al incluir en la lista blanca los URI desde los que se pueden cargar los scripts, está indicando implícitamente que no se permite JavaScript en línea.

La directiva de seguridad de contenido también se puede establecer en una etiqueta <meta> en el elemento <head>de la página:

<meta http-equiv="Content-Security-Policy" content="script-src 'self' https://apis.google.com">

¡Este enfoque protegerá a sus usuarios de manera muy efectiva! Sin embargo, puede requerir una cantidad considerable de disciplina para que su sitio esté listo para tal encabezado.Las etiquetas de scripts en línea se consideran una mala práctica en el desarrollo web moderno: mezclar contenido y código dificulta el mantenimiento de las aplicaciones web, pero son comunes en sitios antiguos y heredados.

Para migrar de forma incremental desde scripts en línea, considere el uso de elementos de creación de violación CSP Reports.By al agregar una directiva report-uri en el encabezado de la política, el navegador le notificará de cualquier violación de la política, en lugar de evitar que se ejecute inline JavaScript:

Contenido-Política-de-Seguridad-Solo-Informe: script-src’self’; informe-uri http://example.com/csr-reports

Esto le dará la seguridad de que no hay scripts en línea persistentes,antes de banearlos directamente.

Más información

  • Cómo funciona el Scripting entre sitios
  • Introducción a la Política de Seguridad de Contenido
  • CSP (Política de seguridad de contenido) en la Red de Desarrolladores de Mozilla
  • Vulnerabilidad de Scripting entre sitios basada en DOM
  • Explicación de la Política de Seguridad de contenido
Scripting entre sitios

XSS reflejado

Deja una respuesta

Tu dirección de correo electrónico no será publicada.