OWASP Top Ten: A2 – XSS

El siguiente tipo de ataques que vamos a ver según las realizada por OWASP para su Top Ten es el de XSS (Cross Site Scripting). Se abrevia como XSS para no confundir con CSS (Cascade Style Sheets) utilizado para dar estilos a documentos HTML o XML. Los fallos de XSS ocurren cuando un atacante consigue ejecutar una secuencia de comandos en el navegador de la victima permitiéndole de esta forma secuestrar sesiones, redirigir al usuario a página no confiables, insertar código hostil, etc… En general, todo aquello que se os ocurra con lenguajes de script. Básicamente, se basa en explotar la no validación de entradas de una aplicación, mediante el cual un atacante puede ejecutar código malicioso en los navegadores clientes, apoyándose en los lenguajes de script como pueden ser JavaScript o VBScript. Quizás, el punto más lioso de este ataque y lo que desconcierta la primera vez que la gente tiene noticias de él, es que aunque el sistema vulnerable es el servidor, en este caso la aplicación web, el que sufre los efectos de esto son los usuarios.

Para aclararlo un poco más, vamos a ver un caso en el que se podría producir este tipo de ataques.

Imaginaros que tenemos un foro vulnerable a XSS, particularmente, el cuerpo del mensaje que publicamos no se valida de forma correcta. Yo como usuario del foro podría publicar un post en el que el cuerpo del mensaje fuera un iframe no visible(width, heigth, frameborder iguales a 0) y en el poner una redirección a un página exterior que he creado donde almacena la propiedad “document.cookie” en un fichero de texto. Cuando yo publique el post, todos los usuarios que lo lean, sin darse cuenta, realizarán una petición a mi página con código maliciosa pudiendo, de esta forma, hacerme con los datos de sus cookies y suplantándolos en el foro.

Espero que ahora haya quedado más claro el concepto, sino como siempre, todas las dudas en los comentarios.

Existen tres tipos de ataques XSS:

  • Almacenados

  • Reflejados

  • XSS basado en DOM

Almacenados

En este caso, el atacante ha conseguido guardar en la base de datos de la aplicación vulnerable el código malicioso que afectará al cliente. Este es el caso del ejemplo que he puesto anteriormente.

Reflejados

En este caso será le propio usuario el que tendrá que ejecutar una URL maliciosa. Quizás esto no suene tan fácil, pero entre ingeniería social, y hoy en día, los acortadores URL, esto no es tan difícil. La URL apuntará a nuestra página maliciosa y quizás tenga una redirección a una página válida, para que el usuario no desconfíe.

XSS basado en DOM

En este ataque, a diferencia de los dos anteriores, el código malicioso, no proviene del servidor, sino que es el cliente el que añade nodos al árbol DOM introduciendo en esos nodos el código malicioso.

Para protegernos de este tipo de ataques, lo que deberemos es filtrar todas las entradas de nuestras aplicaciones y escapando todos los datos que recibamos. Además, tendremos que codificar y decodificar, no nos olvidemos nunca que se puede insertar caracteres hexadecimales y demás.

Bueno, espero que os sea de utilidad. Nos vemos.

 

OWASP Top Ten: A2 – XSS

OWASP Top Ten: A1 – Inyección

El primero de los fallos que figura en la lista del proyecto “Top Ten” de OWASP (ya hablamos de este proyecto en el post anterior) es la inyección.

Los fallos de inyección se producen cuando una aplicación recibe datos no confiables y estos no han sido validados adecuadamente antes de procesarlos, lo cual puede llevar a que el programa o aplicación no se comporten de la manera que esperamos.

El problema de este tipo de ataque, es que cualquier persona lo puede llevar a cabo ya que consiste únicamente en el envío de cadenas de texto a la aplicación, generalmente a través de métodos genuinos proporcionados por la aplicación para recibir datos válidos. La efectividad del ataque ya dependerá de la habilidad y conocimientos del atacante. El impacto de este ataque puede ir desde la simple consulta de datos almacenados, hasta el control de nuestro sistema o servidores.

Generalmente, cuando hablamos de inyección simplemente se piensa en inyección SQL, pero esto no es cierto, la inyección SQL es solo una de las posibles, pero tenemos también inyección LDAP, inyección XPATH, comandos del sistema operativo, argumentos de programas, etc…

Inyección SQL

De esta, ya hemos hablado anteriormente en el blog. Consiste en inyectar valores, parámetros o instrucciones para alterar el funcionamiento correcto de la aplicación. Básicamente, consiste en jugar con nuestros conocimientos de SQL y las comillas simples ( ‘ ) para hacer que la aplicación se comporte de manera diferente a como debería. Por ejemplo:

sentencia = “SELECT * FROM users WHERE username = ‘” + username + “’;”

Si introducimos un valor correcto quedaría así:

Valor a introducir -> svoboda

Consulta generada -> SELECT * FROM users WHERE username = ‘svoboda’;

Pero, ¿Qué pasaría si introducimos un valor no correcto?:

Valor a introducir -> svoboda’; DROP TABLE users; SELECT * FROM products WHERE ‘1’ = ‘1

Consulta generada -> SELECT * FROM users WHERE username = ‘svoboda’; DROP TABLE users; SELECT * FROM products WHERE ‘1’ = ‘1’;

Quizás esto último no debería de poder pasar, ¿no?

Inyección LDAP

LDAP es un sistema de listas de control de acceso de un dominio o red determinadas. Para el que este más familiarizado con entornos Windows, viene siendo lo mismo que el Directorio Activo. Generalmente, para las identificaciones, los usuarios introducen sus credenciales a través del formularios del siguiente estilo:

<input type=”text” name=”user”>Username:</input>

Recogiéndolo así:

user = Request.Form(“user”)

ldapQuery = “(cn =” + user + “)”

Si el usuario inserta un nombre válido todo debería ir bien:

Valor a introducir -> svoboda

Consulta generada -> (cn=svoboda)

Pero, al igual que antes, ¿qué sucede si modificamos la cadena:

Valor a introducir -> svoboda) (| (password=*)

Consulta generada -> (cn = svoboda) (| (paswword=*))

Esta última cadena, lo que hará es devolvernos el password del usuario svoboda.

Inyección XPATH

XPATH es un lenguaje que permite construir expresiones para recorrer y procesar un documento XML.

Volvemos otra vez al mismo caso que el anterior, nos encontramos ante un formulario para identificarnos en una aplicación, para probar vamos a introducir una comilla simple a ver que pasa. En este caso, si todo va bien, nos devolverá un error de este estilo:

System.Xml.XPath.Exception:

Error during parse of

string(//user[name/text()='” and pass/text()=”])

De aquí podemos deducir la estructura del XML que se está empleando:

<user>

<name></name>

<pass></pass>

<user>

Y a partir de aquí lo único que tendremos que hacer es realizar la inyección:

Valor a introducir -> ‘ or 1=1 or “=’

Consulta generada -> string(//user[name/text()=” or 1=1 or ”=” and pass/text()=”])

Si todo sale según lo previsto, la consulta nos debería devolver el primer registro del XML.

El resto de inyecciones son similares, en los argumentos de un programa o en un sistema operativo, si no se filtran las cadenas que se introducen en él, se pueden realizar acciones para las que la aplicación no está preparada.

Para evitar las inyecciones, sean del tipo que sean, lo que deberemos hacer el filtras cualquier tipo de dato que se introduzca en nuestra aplicación, sea el origen de este es que sea. Existen herramientas de análisis que nos pueden ayudar a auditar nuestro código, pero algo que deberíamos hacer desde ya, es mentalizar a nuestros desarrolladores sobre la importancia de la validación y filtrado de datos.

Nos vemos.

OWASP Top Ten: A1 – Inyección

OWASP

El proyecto OWASP (Open Web Application Security Project) es un proyecto abierto dedicado a la seguridad en aplicaciones web. Consiste en una comunidad a nivel mundial enfocada en la mejora de la seguridad en las aplicaciones de software. OWASP está organizada en proyectos y capítulos locales repartidos por todo el mundo dedicados al desarrollo de documentación, herramientas y estándares de código libre, además, esta abierta a la participación de cualquier persona y/o patrocinador.

El proyecto está orientado a conseguir desarrollos de software más seguros mediante:

  • El desarrollo de herramientas útiles para identificar y corregir fallos.

  • La definición de estándares.

  • El aprendizaje de los grupos involucrados en los desarrollos para evitar que se produzcan fallos.

  • La discusión de fallos o problemas por parte de la comunidad.

El proyecto arrancó en el año 2001, y a lo largo de este tiempo ha ido progresivamente arrancando proyectos destinados a conseguir los objetivos comentados anteriormente. Algunos de los proyectos existentes a día de hoy son:

– Top Ten: Es una lista de los 10 problemas de seguridad web más frecuentes detectados por OWASP.

– WebGoat: Programa diseñado, para a través de diferentes lecciones, mostrar distintas vulnerabilidades en un entorno simulado.

– WebScarab: Herramienta para realizar pruebas en aplicaciones web que intercepta las llamadas que se realizan.

– ESAPI: Es una librería de código abierto que permite a los desarrolladores escribir de forma fácil aplicaciones más seguras.

– ASVSP: Pretende ser un estándar unificado para medir la seguridad a la hora de testear diferentes aplicaciones web.

– AntiSamy: Es una librería par evitar la introducción de código malicioso en clientes, está enfocada a HTML/CSS, y la no intrusión de código mediante JavaScript.

– Testing project: Es una guía para definir una metodología de pruebas pero no enfocada a test de intrusión, sino al ámbito del ciclo de vida del desarrollo del software.

Además, de otros tantos que podremos encontrar fácilmente en la página del proyecto.

Seguiremos hablando de este proyecto en futuros post, más concretamente, del proyecto “Top Ten” en el que veremos, paso a paso, cada una de las 10 vulnerabilidades más frecuentes en aplicaciones web. Nos vemos.

OWASP