Standard SQL Injection Testing-Parte 4

Ejemplo 1 ( SQL Injection clásico)

Considere la siguiente consulta de SQL:

Generalmente se utiliza una consulta similar desde la aplicación web para autenticar a un usuario. si la consulta devuelve un valor, significa que dentro de la base de datos existe un usuario con ese conjunto de credenciales, entonces se le permite al usuario iniciar sesión en el sistema, de lo contrario se le niega el acceso.

Supongamos que insertamos los siguientes valores de nombre de usuario y contraseña;

La consulta en sql seria la siguiente; 

Si suponemos que los valores de los parámetros son enviados al servidor a través del método GET, y si el dominio del sitio web vulnerable es www.example.com, la petición que llevaremos a cabo sera;

Observamos que la consulta devuelve un valor ( o un conjunto de valores) por que la condición es siempre verdadera ( OR 1=1).

De esta manera el sistema ha autenticado al usuario sin conocer el nombre de usuario y contraseña; En algunos sistemas la primera fila de una tabla de usuario seria un usuario administrador.

Este puede ser el perfil devuelto en algunos casos. Otro ejemplo de consulta es el siguiente;

Hay dos problemas, uno debido al uso de los paréntesis y otro debido al uso de la función hash MD5, primero resolveremos el problema de los paréntesis, eso simplemente consiste en añadir un numero de paréntesis de cierre hasta que obtengamos una consulta corregida. Para resolver el segundo problema tratamos de eludir la segunda condición.

Añadimos a nuestra consulta un símbolo final que significa que esta comenzando un comentario, de esta manera, todo lo que sigue a tal símbolo se considera un comentario.

Cada DBMS tiene su propia sintaxis para comentarios , sin embargo, un símbolo común de las bases de datos es /*. En oracle el símbolo es el --, dicho esto, los valores que usaremos como nombre de usuario y contraseña son;

La consulta SQL quedaría de la siguiente manera;

La solicitud de URL sera: 

esto puede devolver una serie de valores, a veces, el código de autenticacion verifica que el numero de registros/resultados devueltos es exactamente igual a 1.

En los ejemplos anteriores, esta situación seria difícil ( en la base de datos solo hay un valor por usuario). Para evitar este problema, basta con insertar un comando SQL que imponga la condición de que el numero de resultados devueltos sea uno.

Para alcanzar este objetivo, utilizamos el operador "LIMIT <num>", donde <num> es el numero de resultados / registros que queremos que se devuelvan. Con respecto al ejemplo anterior, el valor de los campos quedaría así; 

La solicitud en URL sera; 

PD: Parte 5, Select Statement, continuara..

Detection Techniques SQL INJECTION-Parte 3

El primer paso  es entender cuando la aplicación interactua con un servidor de base de datos para acceder a los datos.

Algunos ejemplos cuando una aplicación necesita hablar con una base de datos: 

Authentication forms( formularios de autenticacion): 

Esto es cuando la autenticacion se realiza a traves de un formulario web, es muy probable que las credenciales de usuario se comparen con una base de datos que contiene todos los nombres de usuario y contraseñas ( o, hashes de contraseñas).

Search engine ( motores de busqueda):

La cadena enviada por el usuario puede ser utilizada en una consulta SQL que extrae todos los registros relevantes de una base de datos.

E-commerce sites(sitios de comercio electronico):

Es muy probable que los productos y sus características ( precio,

descripción, disponibilidad,etc.) se almacenen en una base de datos.

el testeador tiene que hacer una lista de todos los campos de entrada cuyos valores puedan ser utilizados en la creación de una consulta SQL, incluyendo campos ocultos de las peticiones POST y luego probarlos por separado, tratando de interferir con la consulta y generar un error.

considere también las cabeceras HTTP y las COOKIES.

La primera prueba suele consistir en añadir una sola cita (') o un punto y coma (;) al campo o parámetro que se esta probando.

El primero se utiliza en SQL como terminador de cadenas y, si no se filtra por la aplicación, daría lugar a una consulta incorrecta.

La segunda se utiliza para terminar una Sentencia SQL y, si no se filtra, también es probable que genere un error. La salida de un campo vulnerable puede parecerse a la siguiente ( en un Microsoft SQL Server, en este caso):

También se pueden utilizar delimitadores de comentarios (- or /**/,etc.) y otras palabras clave como SQL como AND y OR para intentar modificar la consulta.

una técnica muy simple pero a veces todavía efectiva es simplemente insertar una cadena donde se espera un numero, ya que se puede generar un error como el siguiente:

Supervise todas las respuestas desde el servidor web y eche un vistazo al código fuente HTML/Javascript. A veces el error presente en su interior, pero por alguna razon ( por ejemplo, un error de javascript, comentarios HTML,etc.) no se presenta al usuario.

Un mensaje de error completo, como los de los ejemplos, proporciona una gran cantidad de información al testeador con el fin de montar una ataque de inyección exitoso.

Sin embargo, las aplicaciones a menudo no proporcionan tantos detalles; un simple '500 Server Error' o una pagina de error personalizada puede ser emitida, lo que significa que necesitamos usar técnicas de inyección ciega.

En cualquier caso, es muy importante probar cada campo por separado; solo una variable debe variar mientras que todas las demás permanecen constantes, para poder entender con precisión que parámetros son vulnerables y cuales no.

PD: Parte 4 se llamara "Standard SQL Injection Testing"