La seguridad en las aplicaciones se torna cada vez más compleja, con la presencia de técnicas que van desde la ingeniería social hasta ataques DoS, pasando por la sencilla inyección de código SQL. No se pueden imaginar la cantidad de aplicaciones que día a día crean los programadores con este fallo crítico.

sql server inyeccion

¿En qué consiste la inyección SQL? Es una técnica de hackeo con un funcionamiento bastante simple. Se basa en atacar aplicaciones cuyo formulario de inicio de sesión o cuadros de texto no se encuentran validados completamente o de la manera adecuada.

Paso a ilustrarles un ejemplo, se necesita que tengan nociones de SQL.

Supongamos que tenemos una aplicación construida en PHP y MySQL, pueden instalarlo localmente si tienen WampServer, la cual tiene una página de inicio de sesión: login.php.

Ahora bien, login.php tiene dos campos de texto, uno para el usuario y otro para la clave. El del usuario tendrá name user y el de la clave tendrá name pass.

Los name son campos que sirven para identificar los inputs y recuperarlos desde la página a la cual es enviada la acción. El formulario sería algo así:

Usuario:
Clave:

Supongamos que al iniciar sesión aqui seremos redirigidos a una página de tipo index.php. Aquí es donde suelen haber errores. Comúnmente lo que hacen las aplicaciones aquí es recuperar el código de ésta manera:

$usua = $_POST['user'];
$clav = $_POST['pass'];

Lo cual no tiene gran relevancia, si estamos usando un método POST en el formulario de login.php, pero lo que ocasiona el problema es el código que le sigue … éste:

$sql="SELECT * FROM usuarios WHERE user = '$usua' AND password='$clav'";

Lo que hace esa sentencia es verificar que existe el usuario mediante la devolución de un registro completo (y único en teoría). Por ejemplo, suponiendo que nuestro nombre de usuario sea Pepe y nuestra clave sea pepito123, entonces la cadena sql quedaría de ésta forma:

$sql="SELECT * FROM usuarios WHERE user = 'Pepe' AND password='pepito123'";

Aquí es donde entra la inyección SQL. No nos complicaremos mucho y comenzaremos con el clásico usuario vacío que valida todo y omitiremos la validación de clave. ¿Cómo? De la siguiente manera:

Usuario: ' or 1=1 --'
Clave: dsadsadas (da igual, escriban lo que sea, luego veremos por qué)

Al pasar estos valores por la cadena de validación SQL tendremos lo siguiente:

$sql="SELECT * FROM usuarios WHERE user = '' or 1=1 --'' AND password='dsadsadas'";

En MySQL un — es el inicio de un comentario, por lo que todo lo que se encuentra luego de éste par de caracteres no se ejecutará, por lo que solo nos quedará:

$sql="SELECT * FROM usuarios WHERE user = '' or 1=1 ";

Obviamente es improbable que se cumpla que exista nuestro usuario de login con nombre vacío (user = ''), sin embargo la segunda condición (1=1) siempre se cumple, por lo que podemos acceder a sistemas con bastante facilidad.

Evidentemente se exhiben cambios entre versiones de bases de datos y lenguajes de programación, por eso me tomé el trabajo de referirlos a un material bastante interesante que encontré en la web (enlace al final del post).

Esta hoja de referencia para inyección en SQL contiene códigos de guía para bases de dato Oracle, MySQL, SQL Server, PostgreSQL y lenguajes de programación como PHP, ASP, ASP.NET y Java, además de las diferentes combinaciones.

Se sorprenderán de la cantidad de aplicaciones que tienen vulnerabilidades que permiten inyección SQL en su formulario de login o inicio de sesión, ustedes no comentan los mismos errores. Yo mismo encontré problemas de este tipo en aplicaciones web de mi facultad como parte de un proyecto para mi curso de Seguridad Informática en la UNI.

Enlace: Ferruh

Disclaimer: Este artículo solo tiene fines informativos y académicos, el autor no se hace responsable del uso indebido que se le pueda dar al conocimiento aqui expuesto.

Actualización 05/02/2010: Recomiendo también revisar este post.

Etiquetas: , , , , ,

Compartir en Facebook Compartir en Twitter

Comentarios ( 14 ) en: Códigos de Inyección SQL
  • Ronny Yinki dijo:
    August 14th, 2009 at 8:46 pm

    interesante, me hace recordar tiempos antiguos

  • ideas geek dijo:
    August 15th, 2009 at 8:08 am

    Si que te lo has organizado bien 😉

    Hace tiempo recibí un ataque al servidor donde atacaron algunos sitios web que tenia alojados. Desde el soporte me dijeron que habia sido un ataque de crackers por inyección de código aunque yo creo que fue por unas extensiones de terceros con vulnerabilidades que tenia en una web gestionada con Joomla.

  • ejner69 dijo:
    August 16th, 2009 at 6:03 pm

    Interesante, ahora entiendo la real magnitud de estas fallas… es realmente simple tomar el control de algo con solo escribir “las palabras mágicas”

  • KnxDT dijo:
    August 16th, 2009 at 6:32 pm

    @ideas geek: Hay que tener bastante cuidado con eso, toda interacción con el sistema es una posible oportunidad para que un hacker, por más novato que sea, pueda entretenerse intentando inyectar código.

    Ejemplos de interfaces de interacción son formularios de comentarios, de contacto, cuadros de búsqueda, la misma URL del blog (sobre todo el uso de parámetros GET), etc.

    @ejner69: Pues sí. En este artículo he mostrado tan solo un caso, existen muchos y cada uno con sus problemas, en el enlace que puse hay una extensa documentación.

    Saludos.

  • Aldo dijo:
    August 16th, 2009 at 8:50 pm

    Gracias, una guía indispensable para la seguridad de nuestras aplicaciones.

  • Bichotoblog dijo:
    September 29th, 2009 at 1:53 pm

    Interesante, lo uso para comprobar la consistencia de algunas aplicaciones mías.

  • KnxDT dijo:
    September 29th, 2009 at 3:23 pm

    La idea es siempre revisar nuestras aplicaciones para ver si son vulnerables. Hace poco asistí a una conferencia de Ethical Hacking y se mostraron ejemplos de ésto, veo que muchos aún no lo toman en cuenta y otros ni siquiera lo conocían.

  • Karen Rodriguez dijo:
    October 26th, 2009 at 4:11 pm

    Interesante el articulo, gracias por compartirla 🙂

  • Guillermo Sandoval dijo:
    November 6th, 2009 at 12:15 am

    Existen también exploits que realizan inyecciones SQL buscando vulnerabilidades propias de las versiones del servior de base de datos.

  • ZeroDayScan: Escanear sitios web online dijo:
    June 24th, 2010 at 4:06 pm

    […] es vulnerable a problemas de seguridad recientemente detectados, si es vulnerable a ataques vía códigos de inyección SQL, […]

  • leandro dijo:
    June 27th, 2010 at 1:02 pm

    Alguien lo probo para saber si realmente funciona ?

  • Mekix dijo:
    July 17th, 2010 at 7:43 pm

    Dudo mucho que un hacker pierda el tiempo de este modo, ademas
    la inyeccion que comentas: ‘ or 1=1 –‘ es mas antigua que tu abuela y se evita facilmente, tal vez para joder a los programadores novatos y nada mas, por ejemplo recuerdo que en el 2003 si no me equivoco lo probe en la web de peru21 y funciono! con la cuenta de admin todavia.

    para los interesados:
    http://unixwiz.net/techtips/sql-injection.html

  • zerocool dijo:
    August 7th, 2010 at 8:18 am

    yo uso la inyeccion sql y me a dado resultado,cada ves ahi mas web vudnerables a este tipo de cosas,que tomen medidas si les da la cabeza jaja.

  • ‘ or 1=1 –‘ dijo:
    August 20th, 2010 at 12:34 am

    Interesante, me agradó el tema y me dejó mucho que reflexionar acerca de mis sistemas y sus vulnerabilidades. A seguir estudiando y mejorando. Saludos desde mexico.