lunes, 19 de octubre de 2015

SQL INJECTION: "Consultame que me gusta"

Si bien ya habia escrito sobre SQL Injection (Inyecciones SQL part1 Y Inyecciones SQL part2), la entrada de hoy se la dedico a lo que con seguridad es la fallo mas explotado, me refiero a los famosos “SQL INJECTION”, en donde la misión será en procura de dejar alguna idea amigable de cómo es el funcionamiento de esta vulnerabilidad sin entrar en demasiados tecnicismos.


Primero hay que entender que SQL es un lenguaje de consultas (un lenguaje para “preguntar”). Consultas dirigidas a un gestor de bases de datos como puede, ser; “MySql”, “MsSql”, “PostgreSQL”, “Oracle” y un largo etc. Estos gestores serán las aplicaciones que se encargaran de almacenar, ordenar y gestionar toda la información contenida en las bases de datos.

El lenguaje SQL tiene comandos para definir la estructura de la base de datos, como por ejemplo: “CREATE TABLE”, “ALTER TABLE”, “DROP TABLE”, etc. Y comandos para manipular la información almacenada en la base de datos.

Ejemplo de consulta:
SELECT * FROM tbl_usuarios
En nuestro ejemplo la consulta anterior nos devolverá todos los registros de la tabla: “tbl_usuarios


APLICACIONES WEB DISPUESTAS A RESPONDER TODAS NUESTRAS CONSULTAS.

Antes desarrolle la idea ultra básica sobre lo que es SQL, por lo que ahora rápidamente salto a al mundo web en donde tenemos por una lado, a los que PREGUNTAN/consultan y quienes están dispuesto a responder esas consultas. Podemos pensar al “Sql injection” como una analogía de ciertos juegos de preguntas y respuestas.

Si se presta atención a la url de los portales por los que a menudo navegamos seguramente (de incontables ejemplos) nos encontraremos con rutas que incluyen archivos similares a: “

…/productos.php?id=1, …/productos.asp?id=32, …/productos.aspx?id=1, …/productos/1
…/post.php?id=123123, …/post.aspx?id=123123, …/post.asp?id=123123, …/post/123123
…/noticia_amp.php?id=123, …/noticia.aspx?id=13,…/post.asp?id=123123, …/noticia/123123,
ETC,

En el ejemplo anterior, vemos archivos típicos de cualquier aplicación web que donde el identificador “ID” es la variable que en favor del valor que posea será uno u otro el producto, articulo, posteo o noticia que se cargue sobre la web.

Tenemos que entender que el valor de ese ID apuntara a un registro dentro de la base de datos.

Si bien el valor del ID no estaría pensado para ser modificado manualmente, el hacerlo desde la misma URL sería un request totalmente valido que llegara al servidor y en consecuencia respondido y devuelto al navegador quien finalmente se encargara de resolver el cambio que fuere.

Básicamente cuando sobre la url modificamos el valor de la variable ID y enviamos el cambio (le damos al enter Xd) también estamos realizando consultas a una base de datos que serán devueltas a nosotros siempre que el administrador/programador del portal lo haya consentido.

Siendo mas “tecnicos” no nos limitaremos solo a cambiar el valor de un ID por otro, vamos un paso más lejos y aprovechamos el camino que nos da nuestra variable hacia la base de datos para hacerle consultas armadas por nosotros.

Consideren una consulta como la siguiente:
../user.php?id=22+union select 1,user_name(),3,4,5,6,7
../news-and-events.php?id=22%2b%20(select%20case%20when%20(substr(user(),1,1)=%27a%27)%20then%200%20else%201%20end)--

Nosotros somos libres de armar y enviar las consultas que se nos antojen, la “magia”, esta cuando estas consultas son respondidas y esto dependerá de lo permisivo (descuidado, despreocupado) que sea el admin en la lógica aplicada en su aplicación por lo tanto si envio una consulta al server y esta es respondida asumo que al admin del portal lo ha considerado o permitido y punto.
***
ANALOGAMENTE...    
Situación:

Se requiere “cruzar” un determinado sitio, un método seria forzando sus entrada/s, podemos pensar en un ataque de fuerza bruta contra un formulario de login, tal caso podríamos compararlo con un sujeto que a fuerza de ganzúas intenta atentar contra una cerradura para cruzar una puerta. Ni decir que de conseguir entrar a un sitio ajeno con esta técnica muy probablemente nos  traerá un problemita legal.

Se nos presenta otro escenario en donde cierta aplicación web acepta nuestra propias consultas SQL armadas en la misma URL que el navegador nos ha proporcionado (Sql injection mode: ON) y a fuerza de estas consultas SQL nos hacemos con todos los registros de una base de datos. 

Análogamente se nos presenta otro escenario en el cual con la dirección correcta de una casa nos posicionamos en una de sus muchas puertas (de servicio) habilitadas.

Detrás de cada una de estas puertas nos encontramos a los huéspedes y responsables de ofrecer distintos servicios dentro de la casa. Por ejemplo podemos encontrar entradas/puertas para el jardinero, mayordomo, mucamas, vigilancia ,...[analogía en desarrollo]

En vez de forzar la cerradura (a fuerza de ganzúas, por ejemplo) nos inclinamos por llamar a la puerta esperando a establecer una comunicación con algún responsable que comprenda nuestro lenguaje. A este responsable le empezamos a hacer muchas y distintas preguntas/consultas sobre el contenido interno de la casa y vamos tomando nota de sus respuestas (¿la clave de la alarma de la casa?). Pasado un tiempo y luego de incontables consultas tendremos un reflejo grafico del interior de la casa sin haber entrado.

Llegue a un punto interesante.
Un SQLi explotado podrá permitirnos obtener prácticamente cualquier registro de la base de dato.

Volviendo a nuestra analogía voy a cerrar el post con una pregunta: ¿quién es el malo de esta situación? Una pregunta mejor formulada podría ser: ¿quién es el culpable que exista un texto/log -a bases de respuestas- con información/detalles internos de la casa, el fulano que pregunta o el responsable interno que responde a cada consulta?

Saludos,

@Capitan_Alfa

No hay comentarios.:

Publicar un comentario