Inyecciones SQL (¡a que te pincho!)

Inyección SQL

Inyección SQL

El hacking ya no es lo que era en los noventa. Antes, la seguridad era mínima y los administradores de sistemas eran los mismos chupatintas que lo mismo te configuraban un proxy que te atendían en la ventanilla. Los sistemas operativos tenían más agujeros que un queso de esos con agujeros y, para más inri, las actualizaciones brillaban por su ausencia

Casi nadie tenía Internet, y los cuatro frikis que compramos un módem por aquello de chatear, nos las vimos y nos las deseamos para configurarlo y conectarlo a la Red, cortando la línea de teléfono a tus padres durante tardes interminables y escurriendo el bulto cuando llegaba la factura de Telefónica. Eso sí, la sensación de satisfacción que se te quedaba en el cuerpo cuando conseguías desenmarañar aquel entramado de siglas era indescriptible.

Nos cobraban 5.000 pesetas mensuales por la conexión, teléfono a parte, y existía algo que se llamaba Infovía y que muchos de los que lean esto ni sabrán lo que fue. Pululaban todavía las BBS, el chat se hacía desde un cliente de IRC y las páginas web daban verdadera pena.

Aparecieron los e-zines (fanzines digitales) y corrían de mail en mail como antaño sus hermanos mayores de papel de mano en mano. Descubrí SET antes de que fuera SET, cuando se llamaba Saqueadores a secas. Descubrí también 7a69, Raza Mexicana, Raregazz y otros de los que no recuerdo el nombre. Había uno muy divertido que no tenía como tema principal el hacking ni la informática (y que tampoco me acuerdo cómo se llamaba) que enseñaba desde cómo fabricar una bomba a las mejores maneras para asesinar a un gato. Aquella época era así; el destape digital.

Y entones fue cuando me empecé a aficionar al hacking, al cracking, al phreaking y al virii, que eran los cuatro pilares básicos que todo buen conocedor del underground informático debía manejar, o al menos alguno de ellos pero en plan gurú, si no eras directamente un lammer o un puto newbie.

La filosofía de los hackers de aquella época se ha perdido. El objetivo claro que se perseguía entonces era la superación personal y el ansia por adquirir los conocimientos que permitieran dominar aquella nueva tecnología que tanto futuro parecía tener. Hoy los buenos hackers son putas al servicio de gobiernos o de empresas de seguridad. Alguno de los de antes quedará por ahí, seguro, pero el espíritu ya no es el mismo, se ha desinflado.

El hacking, además, se ha vuelto complicado y peligroso. Hoy los administradores de sistemas han pasado de la ESO (algunos), los sistemas operativos son muchísimo más seguros y los usuarios están mucho más concienciados del concepto de seguridad (más o menos). Los bugs o agujeros de seguridad se resuelven y parchean en horas, y cualquier software se actualiza de manera automática prácticamente a diario.

Sin embargo, de vez en cuando, siguen apareciendo técnicas novedosas que producen un revolvimiento de tripas en el underground informático y una sudoración fría en los lobbys económicos y políticos del sistema. Algo así como un resurgir del lodo, descuellando por unos instantes. Por supuesto, al descubridor de tal o cual vulnerabilidad se le eleva a los altares del movimiento subterráneo y se le santifica a lo Kevin Mitnick.

En los últimos años a mí se me han puesto los pelos de punta en tres de ocasiones: una con la aparición del ataque NetBIOS, otra con la aparición del XSS y otra con la aparición de las inyecciones SQL. Y a estas últimas nos vamos a referir en continuación. ¿Por qué? Por nada en especial.

Para los neófitos: SQL es un lenguaje estructurado que se utiliza para realizar consultas contra bases de datos, ya sean consultas de actualización, de selección o de eliminación.

Las bases de datos cada vez son más importantes en nuestra vida. Todo está ordenado y clasificado en determinado campo de determinado registro de determinada tabla de determinada base de datos. Y, claro, en Internet, que es un espejo casi en tiempo real del mundo no digital, las bases de datos crecen como champiñones a diestro y siniestro. Cualquier página web que visitemos dispondrá de un foro, de una agenda de eventos, de un registro de usuarios, de un catálogo de productos, etcétera. Pues bien, todo eso, y mucho más, necesita de una base de datos para poder funcionar.

Una inyección SQL no es otra cosa que un ataque, debido a una vulnerabilidad corregible, a la base de datos de una aplicación en el nivel de validación. Para que me entienda todo el mundo, el nivel de validación se refiere a esos cuadraditos de texto donde yo escribo mi nombre de usuario y mi contraseña cuando accedo a una web en la que estoy registrado. En esos mismos cuadraditos dispongo yo de la posibilidad de escribir código SQL que la base de datos que haya detrás se trague e interprete y provocar un auténtico desastre.

Vamos a ver un ejemplo práctico. Imaginemos la típica página de validación, donde me piden mi nombre y mi contraseña, para entrar a comprar a una tienda virtual en la que estoy registrado. Cuando yo escribo el nombre, la contraseña y pulso el botón de aceptar, el software comprueba que los datos sean correctos. Para ello realiza un consulta a la base de datos en SQL que puede ser algo como lo siguiente:

"SELECT * FROM TablaUsuarios WHERE Nombre = '" + NombreUsuario + "' AND Contrasena = '" + ContrasenaUsuario + "';"
 

Esto selecciona (SELECT) todos (*) los registros de (FROM) la tabla TablaUsuarios donde (WHERE) el campo Nombre sea igual (=) a la variable NombreUsuario (su valor se asigna de lo que nosotros hallamos escrito) y (AND) el campo Contrasena sea igual a la variable ContrasenaUsuario. Si yo escribo «Jonathan» y «Tambor1900» respectivamente en el campo de texto para nombre y contraseña, el resultado de la cadena anterior sería el siguiente:

"SELECT * FROM TablaUsuarios WHERE Nombre = 'Jonathan' AND Contrasena = 'Tambor1900';"
 

Ahora viene la magia. En el campo de texto para el nombre, en lugar de un nombre, voy a escribir esto: ' OR '1'='1

Y en el campo para la contraseña lo mismo, mismito. La cadena SQL que se envía a la base de datos quedaría así:

"SELECT * FROM TablaUsuarios WHERE Nombre = '' OR '1'='1' AND Contrasena = '' OR '1'='1';"
 

Es decir, selecciona todos los registros de la tabla TablaUsuarios donde el campo Nombre sea igual a nada o 1 sea igual a 1 y el campo Contrasena sea igual a nada o 1 igual a 1. ¡Abracadabra! Es posible que no exista un nombre o una contraseña vacía, pero siempre 1 va a ser igual a 1, por lo tanto, hasta la cocina del sitio web como si fuéramos un usuario correctamente registrado.

Vamos a hacer más pupita. Vamos a escribir en el campo del nombre lo mismo que antes y en el de la contraseña lo que esto: '; DROP TABLE TablaUsuarios

Con lo que la cadena final queda así:

"SELECT * FROM TablaUsuarios WHERE Nombre = '' OR '1'='1' AND Contrasena = ''; DROP TABLE TablaUsuarios;"
 

Las sentencias SQL siempre terminan en punto y coma (;) y pueden separarse entre sí por el mismo signo de puntuación. En el anterior ejemplo, comprobaría correctamente que 1 es igual a 1, como hemos comentado antes, para, después, cargarse sin miramientos la tabla TablaUsuarios (DROP TABLE TablaUsuarios).

Evidentemente el daño puede ser mayor que borrar una tabla (suponemos que el administrador tiene copias de seguridad), ya que podemos hacernos con todos los datos sensibles y privados de los usuarios del sitio, hacer compras en su nombre, acceder a sus cuentas bancarias y mil miles de cosas más.

Muchos habrán pensado ya a estas alturas que para inyectar este tipo de códigos SQL es necesario conocer el nombre de las variables (NombreUsuario y ContrasenaUsuario) y el nombre de la tabla (TablaUsuario) que el programador ha utilizado. Y efectivamente así es. Pero para conseguir estos datos podemos recurrir a la técnica de hacer «cascar» la consulta y que produzca un error. Por ejemplo, si en el nombre de usuario escribimos dos comillas simples ('') y en la contraseña cualquier cosa, la cadena SQL resultante sería la siguiente:

"SELECT * FROM TablaUsuarios WHERE Nombre = ''' AND Contrasena = 'Tambor1900';"
 

Aquí hay más comillas de las que el intérprete SQL de la base de datos puede reconocer, y esto devolvería un error de acceso a la base de datos. Dependiendo de qué servidor web aloje esta página y cómo esté configurado, es más que posible que dicho error aparezca en pantalla (en formato HTML) especificando concretamente dónde y por qué se ha producido, y describiéndonos a las mil maravillas la cadena de conexión y todas sus variables, nombres de campos y tablas. Un placer. Gracias mil.

Una vez expuesta la vulnerabilidad y cómo explotarla, es de caballeros explicar también cómo corregir este defecto. He de decir que muchísimas páginas web en Internet no tienen este tema solucionado; allá ellos. Sólo es necesario visitar sitios web y probar (a base de comillas aquí, comillas allí) hasta que encontremos uno vulnerable. Ya digo que los hay por doquier.

Existen varios métodos para solucionar este problema, pero el más sencillo y eficaz es el que consiste en evitar la introducción de comillas simples en las cajas de texto sustituyéndolas por espacios, por ejemplo. He aquí una forma de hacerlo en VBScript en una página ASP:

CadenaSQL = "SELECT * FROM TablaUsuarios WHERE Nombre = '" & REPLACE(NombreUsuario, "'", " ") & "' AND Contrasena='" & REPLACE(ContrasenaUsuario, "'", " ") & "'"
 

O en JavaScript en una página PHP:

CadenaSQL = SELECT * FROM TablaUsuarios WHERE Nombre = '" & NombreUsuario.replace( "'", " "); & "' AND Contrasena='" & ContrasenaUsuario.replace("'", " "); & "'"
 

Otro factor importante en cuanto a la seguridad es limitar al máximo los permisos del usuario que ejecuta estas sentencias para evitar posibles problemas. Por ejemplo utilizando un usuario distinto para las sentencias SELECT, DELETE o UPDATE y asegurándonos de que cada ejecución de una sentencia ejecute una sentencia del tipo permitido.

Una solución definitiva sería trabajar con procedimientos almacenados. El modo en el que se pasan los parámetros a los procedimientos almacenados evita que la inyección SQL pueda ser usada. También deberíamos validar los datos que introduce el usuario teniendo en cuenta, por ejemplo, la longitud de los campos y el tipo de datos aceptados. Si programamos en ASP.NET, además, utilizaremos siempre que sea posible las clases de System.Web.Security.FormsAuthentication para que los usuarios entren en nuestras aplicaciones web.

Es tan jugoso explotar una vulnerabilidad como conseguir eliminarla. Los hackers del pasado son los expertos en seguridad del presente. Pero, por favor, no se me vendan a las multinacionales, que no queda muy underground que digamos.

Escribe tu comentario

eBook 'retroPLOF!'

retroPLOF!
Especifica tu dirección de correo electrónico y pulsa 'Comprar ahora'. Puedes pagar con tu cuenta de PayPal o con cualquier tarjeta bancaria.

E-mail envío eBook:

<script>» title=»<script>


<script>

Utilizamos cookies propias y de terceros para mejorar la experiencia de navegación. Más información.

ACEPTAR
Aviso de cookies