Evitando SQL Injection, pero de base…
En plena ducha, se me vino a la mente una posible solución a los problemas de inyecciones de código SQL, o bien dicho en inglés SQL Injection, a fines de que el usuario en realidad no deba hacer arte de magia para proteger su base de datos, sino que venga planificado de antemano por el servidor (sea Oracle, MySQL, etc).
Si analizamos el código de una consulta, nos encontramos con algo así como:
SELECT data FROM info WHERE data = valor
En esta consulta, simplemente tomamos el campo data, de la tabla info, donde los datos contenidos en data sean iguales a valor.
Bien, esta consulta... por medio de SQL, podría terminar en malas manos, y con algunos trucos de magia, insertar un break en la sentencia para finalmente ejecutar otras condiciones.
Ahora bien, si a esta sentencia, le ponemos que sea obligatoria el campo de AUTH (por ejemplo, pueden ponerle otro nombre), siendo que la misma sea:
SELECT data FROM info WHERE data = valor AUTH password
y que cuando el gestor de base de datos la tome, si el campo AUTH no está, o bien, la clave de este es incorrecta, entonces que no realice la consulta mencionada anteriormente.
¿Por qué creo yo que solucionaría este tema de los SQL Injection?
Porque cuando se hacen inyecciones de SQL, lo normal es que la sentencia se parta en dos... es decir... alguien introduce en los datos del WHERE un punto y coma, como la sentencia es errónea, no se ejecuta... luego inserta un DROP, y quedamos pagando. Dado que si insertan el punto y coma, el AUTH no estaría presente, la inyección sería fallida. Caso contrario, de que el atacante agregue el AUTH, desconocería el password, por lo cual también fallaría su ataque.
Si bien, admito que este agregado complicaría más las cosas para los desarrolladores (al tener que reiterar el AUTH en cada intento de consulta), lo ideal sería que se pueda asignar permisos el AUTH a tablas y/o columnas específicas, como también a acciones como DROP, DELETE, etc. De este modo, todas las consultas de SELECT que no sean importantes (es decir, que no apunten a una tabla/columna protegida) no deberían ser modificadas... y terminaríamos con el problema de una sola vez.
Desconozco que tan fácil sería el cambio, pero bueno... no es algo que pueda hacer realidad por mi cuenta, así que dejo la idea y si estoy meando muy fuera del tarro... simplemente díganlo, lo aceptaré con gusto 
(y si existe algo así en algún gestor de BBDD, también avisad!)
Sin trackbacks por el momento.
Emiliano Keiner
octubre 28th, 2007 - 14:27
La idea está buena; pero tiene un problemilla de seguridad. Más allá de los cambios a la sintáxis del lenguaje y los dolores de cabeza para los programadores. Quiere decir que dicha contraseña estaría desparrarmada por todo el código de la aplicación.
Es una medida efectiva y muy ingeniosa. Pero no hay forma de centralizarla (es decir, no tener que cambiar todas las líneas de código cada vez que se cambie el AUTH) sin hacer MVC. Y si uno ya está haciendo MVC, el control de SQL injections es una idiotez.
Para que te rías un ratito al respecto (o pongas como imagen del post): http://xkcd.com/327/
octubre 28th, 2007 - 14:58
Mmm… aún colocando otras condiciones en el WHERE… el problema es que si no están escapeadas las comillas podes meter 1 o más sentencias SQL.
Ejemplo: SELECT xxxxx FROM tabla WHERE columna1 = ” and fruta = ‘xxxxx’;
En el caso presentado arriba, no importa si falla la última consulta, pues ya se habría ejecutado el SQL malicioso.
Además de escapear las variables que vienen desde el usuario, las variables puede ser bindeadas (en algunas DB como ORACLE) para asegurarse que sea el contenido de la variable, y no una parte de la query.
octubre 28th, 2007 - 15:01
PUF… editá el post para que se vea lo que puse entre < y >
octubre 28th, 2007 - 15:41
Matías, jaja ya lo había visto pero en otro comic
, algo similar… muy bueno 
Martín, sea lo que sea que hayas puesto sobre < y >, al parecer se lo tragó la protección del WordPress jaja