RSS

OWASP Top Ten: A1 – Inyección

17 Dic

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.

Anuncios
 
Deja un comentario

Publicado por en 17 diciembre, 2010 en OWASP

 

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

 
A %d blogueros les gusta esto: