SQL Injection
27.Mar.2006 ~
3 Comentarios ~
1613 Lecturas
Cuando programamos una aplicación en la que, de forma interactiva, accedemos a una base de datos, debemos cuidar ciertos parámetros básicos para no poner en peligro la integridad de los datos. SQL Injection es una técnica con la que se pretende explotar justamente esta característica.
El origen suele ser un filtrado incorrecto de las variables introducidas por el usario a través, normalmente, de un formulario web. Se trata de inyectar código SQL embebido. Lo veremos mejor con un ejemplo. Un formulario de login, donde se introduce usuario y contraseña. Lo típico sería que, si la dupla introducida fuera Usuario:Antonio, Contraseña:abracadabra el SQL resultante quedaría así:
Había una vez un pingüino aburrido que se puso a jugar. El juego consistía en llamar a la puerta de algunos iglús de Vila Pengüín haciéndose pasar por alguien familiar. En un principio se trataba de algo gracioso aunque no siempre el resultado era satisfactorio. Pero un día encontró una puerta abierta, entró y vió un vale de compra de PenguMarket. No lo cogió porque su ética no lo permitía, salió del iglú y dejó todo tal cual había encontrado.
Días más tarde nuestro pingüino se enteró que la familia que habitaba aquél iglú tenía por costumbre dejar la puerta abierta y por su cabeza pasaron varias cuestiones:
Nuestro pingüino se encuentra desorientado y no sabe cómo actuar, ¿qué haríais vosotros?.
El origen suele ser un filtrado incorrecto de las variables introducidas por el usario a través, normalmente, de un formulario web. Se trata de inyectar código SQL embebido. Lo veremos mejor con un ejemplo. Un formulario de login, donde se introduce usuario y contraseña. Lo típico sería que, si la dupla introducida fuera Usuario:Antonio, Contraseña:abracadabra el SQL resultante quedaría así:
SELECT * FROM Usuarios WHERE User = 'Antonio' AND Password = 'abracadabra'
Ahora supongamos que un usuario malintencionado rellena el formulario poniendo lo siguiente, Usuario: Pepe, Contraseña: pepe' OR 1=1;--. Veamos:
SELECT * FROM Usuarios WHERE User = 'Pepe' AND Password = 'pepe' OR 1=1;--'
La condición 1=1 se cumpliría siempre, con lo que existirían resultados y, dependiendo del código de la aplicación web, podría dejarnos entrar. Una vez visto un ejemplo práctico sencillo y sin profundizar más en el tema (hay ríos de tinta sobre esto) paso a la cuestión moral.
Había una vez un pingüino aburrido que se puso a jugar. El juego consistía en llamar a la puerta de algunos iglús de Vila Pengüín haciéndose pasar por alguien familiar. En un principio se trataba de algo gracioso aunque no siempre el resultado era satisfactorio. Pero un día encontró una puerta abierta, entró y vió un vale de compra de PenguMarket. No lo cogió porque su ética no lo permitía, salió del iglú y dejó todo tal cual había encontrado.
Días más tarde nuestro pingüino se enteró que la familia que habitaba aquél iglú tenía por costumbre dejar la puerta abierta y por su cabeza pasaron varias cuestiones:
- ¿Aviso a los dueños para que nadie les robe el vale de compra?... ¿Y si me denuncian por allanamiento de iglú?... mejor no meterme en temas legales.
- No digo nada... pero ¿y si alguien entra y se gasta el vale en pescados para todo el invierno?.
- ¿Podría decírselo a algún amigo de la familia o cerrajero (saque o no tajada) para que, indirectamente, les adviertan que mejor cerrar la puerta con llave y evitar desgracias? (hispasec, alfa21...).
Nuestro pingüino se encuentra desorientado y no sabe cómo actuar, ¿qué haríais vosotros?.
Comentarios
De todas formas, ¿quién te manda jugar con esas cosas? Yo no hago auditorías gratis XDDDD
Aunque no lo recomiendan, para alagunos debería ser requisito indispensable :P
Tema emails anónimos... hay listas de servidores de correo mal configurados... open relay ¿os suena? ;).