A2 Cross-Site Scripting (XSS)

SQL Injection Vs. XSS

• El objetivo principal de SQL Injection es el Servidor de la Base de datos

• Los objetivos principales de XSS son los demás Usuarios y distribuir scripts maliciosos

Tipos de XSS

NO PERSISTENTE• Estos agujeros aparecen cuando los datos

proporcionados por el cliente web, con mayor frecuencia en los parámetros de consulta HTTP o en envíos de formularios HTML, es utilizar inmediatamente las secuencias de comandos del lado del servidor para generar una página de resultados para ese usuario, sin desinfectar correctamente la solicitud.

PERSISTENTE

• Ocurre cuando los datos proporcionados por el atacante es salvado por el servidor y, a continuación, se muestra permanentemente en "normales" de páginas devueltas a otros usuarios el curso de la navegación normal, sin HTML adecuado escapar.

Tipos de XSS

• XSS basado en DOM es un cliente (navegador) dictar la ejecución simultánea. Todo este código se origina en el servidor, lo que significa que es responsabilidad del propietario de la aplicación para que sea salvo de XSS, independientemente del tipo de falla XSS

Tipos de XSS

¿Soy vulnerable a XSS?Tiene que asegurarse de que todas las entradas suministrada del usuario sea enviada de vuelta al navegador y verificada como segura(a través de la validación de entrada), y que la entrada del usuario se escapada apropiadamente antes de que se incluye en la página de salida. Codificación de salida apropiada asegura que estas aportaciones se trata siempre como texto en el navegador, en lugar de contenido activo que podría obtener ejecutado. Ambas herramientas estáticas y dinámicas se pueden encontrar algunos problemas XSS automáticamente. Sin embargo, cada aplicación genera páginas de salida diferente y utiliza diferentes intérpretes secundarios navegador como JavaScript, ActiveX, Flash y Silverlight, lo que hace difícil la detección automática. Por lo tanto, la cobertura completa requiere una combinación de revisión manual de código y pruebas de penetración manual, además de los métodos automatizados en uso. Las tecnologías Web 2.0, como AJAX, XSS hacer mucho más difícil de detectar a través de herramientas automatizadas.

¿Como puedo evitar XSS?

XSS sólo se puede prevenir por prácticas de codificación seguras

• Los desarrolladores siempre deben validar y codificar la información recibida por los usuarios

La Codificación debe ser contextual

• Validación de la lista blanca

Lista Blanca• Un XSS Modelo de Prevención Positiva• En este artículo se trata una página HTML como una plantilla, con ranuras donde se permite a

un desarrollador para colocar datos no confiables. Estas ranuras cubren la gran mayoría de los lugares comunes en los que un desarrollador puede querer poner los datos no confiables. Poner los datos no confiables en otros lugares en el HTML no está permitido. Se trata de una "lista blanca" del modelo, que niega todo lo que no esté específicamente permitido.

• Dado el modo de análisis sintáctico navegadores HTML, cada uno de los diferentes tipos de ranuras tiene reglas de seguridad ligeramente diferentes. Cuando usted pone los datos no confiables en estas franjas horarias, es necesario tomar ciertas medidas para asegurarse de que los datos no salir de ese espacio en un contexto que permita la ejecución de código. En cierto modo, este enfoque trata de un documento HTML como una consulta de base de datos con parámetros - los datos se mantienen en lugares específicos y se aísla del contexto de código con escapar.

• Este documento establece los tipos más comunes de las franjas horarias y las reglas para poner los datos no confiables en forma segura. Sobre la base de las diversas especificaciones, conocidos vectores XSS, y una gran cantidad de pruebas manuales con todos los navegadores populares, hemos determinado que las reglas propuestas aquí son seguras.

Normas de prevención de XSS

• REGLA # 0 - Nunca Insertar datos no confiables Excepto en ubicaciones permitidas– No insertar datos importantes en Scipts, comentarios,

nombre de un atributo, en un nombre de etiqueta o directamente en CSS.

• REGLA # 1 - Escape HTML antes de insertar datos no confiables en el contenido del elemento HTML– Es para cuando se desea colocar datos no confiables

directamente en el cuerpo HTML en alguna parte.Esto incluye etiquetas dentro normales como div, p, b, td, etc La mayoría de marcos Web tiene un método para escapar de HTML

• REGLA # 2 - Escape atributo antes de insertar datos no confiables en HTML Atributos comunes– Para poner los datos no son de confianza en los valores de atributos típicos

como el ancho, nombre, valor, etc Esto no debe ser utilizado para los atributos complejos como href, src, estilo, o cualquiera de los controladores de eventos como onmouseover. Es extremadamente importante que los atributos de control de eventos debe seguir la regla # 3 para HTML JavaScript valores de datos.

• REGLA # 3 - Escape JavaScript Antes de insertar datos no confiables en Javascript valores de datos– El único lugar seguro para poner los datos no confiables en este código se

encuentra dentro de una cita "Valor de datos". La inclusión de datos no confiables dentro de cualquier otro contexto JavaScript es bastante peligroso, ya que es muy fácil de cambiar en un contexto de ejecución.

Normas de prevención de XSS

• REGLA # 4 - Escape CSS y estrictamente validar antes de insertar datos no confiables en HTML Valores propiedad Style– Es para cuando se desea colocar datos no confiables en una hoja

de estilo o una etiqueta de estilo. CSS es sorprendentemente potente, y puede ser usado para numerosos ataques. Por lo tanto, es importante utilizar únicamente los datos no confiables en una propiedad de valor y no en otros lugares en los datos de estilo.

• REGLA # 5 - Escape URL antes de insertar datos no confiables en HTML Los valores de los parámetros de URL– Es para cuando se desea colocar datos no confiables en HTTP GET

valor del parámetro

• REGLA # 6 - Utilizar un motor de directiva HTML para validar o limpiar impulsada por el usuario HTML de forma saliente– OWASP AntiSamy, OWASP Java HTML Sanitizer

• REGLA # 7 - Prevenir XSS basado en DOM

• Regla bono: bandera utilizar cookies HTTPOnly– Establece el indicador HTTPOnly en su cookie de

sesión y las cookies personalizadas que tienen que no son accesibles por cualquier javascript que escribiste