Prevenir Una Inyeccion SQL En Mi Pagina Web

Reconozco que mi area principal ronda mas en la administracion de sistemas y base de datos, mas sin embargo, no por ello estoy 100% alejada del ambito que envuelve el mundo de la programacion sobretodo web ya que como me movilizo con base de datos relacionales, parte del trabajo es estar pendiente de la seguridad de la misma he impedir que violenten datos :)  . Mis intentos con lenguajes de programacion web no han sido a grandes escalas, pero si a un nivel suficiente como para entender como funciona este ambiente.



Ahora es muy seguro que cualquier desarrollador web o inclusive un operador que ofrezca monitoreo web a una plataforma vamos que hay de todo, se ve ante la situacion del 'hackeo' o posibilidad del mismo. Yo misma considero que las posibilidades tienen distintos niveles de poder ser ejecutadas satisfactoriamente, todo depende que tanto en el tema este un administrador, programador o operador, si conoces una debilidad conoceras la manera de asegurarla o no?. Pues bien, como he venido redactando, en este articulo hare incapie al tan conocido (pero que aun no pasa de moda jeje) inyecciones SQL. Si sabes lo que es, que bien, sino sabes que es esto te explico:

Que es una inyeccion SQL?

La inyección SQL consiste en la modificación de las consultas a nuestra base de datos a partir de los parametros pasados por URL al script en PHP.

En resumen es la capacidad existente de que un usuario remoto pueda mediante el navegador subministrar palabras o frases a la consulta SQL para violentar y obtener datos que no deberia. Me explico , supongamos que tenemos una tabla llamada Empleados con la siguiente info:

Tabla Empleados:

Nombre        ID        contrasena

XXXX          XX      XXXX

Y digamos que tienes un acceso web, desarrollado en cualquier lenguaje de programacion (php, perl, python, asp, etc) y que dicha web solicite el acceso al usuario mediante su Nombre y Contrasena para retornarle el valor de su ID. Para obtener esta info, por lo general el programador pondria una consulta SQL similar a la siguiente en su codigo:

SELECT ID FROM EMPLEADOS WHERE NOMBRE = 'XXX' AND CONTRASENA = 'XXXX'

Lo cual esta correcto, pero...imaginemos que un intruso jugueton a 'hacker'  y a los datos que hay que pasar por el navegador que son su nombre de usuario y contrasena, el intruso al dato de la contrasena le agrega lo siguiente:

' ' OR '' = ' '

Cuando el intruso envie los datos, la consulta SQL de tu codigo quedaria asi:

 SELECT ID FROM EMPLEADOS WHERE NOMBRE = 'XXX' AND CONTRASENA
= ' ' OR '' = ' '

 En este caso, como '' siempre es igual a '', el intruso habra logrado su objetivo y aunque la password sea incorrecta, el intruso podra averiguar el ID de ese empleado en cuestion. En resumen, si la informacion que un usuario envia a traves del navegador a tu codigo fuente es validada como TRUE en la base de datos, esta retornara el valor solicitado y mas independientemente de si es o no correcto el retorno sin privilegios para obtenerlo.

Ahora como previenes esto???. Tienes varias opciones existentes, como por ejemplo utilizar la funcion replace o reemplazo correspondiente a tu lenguaje de programacion, para reemplazar comillas por lo que quieras, aunque no recomiendo esta manera ya que un atacante se las ingenia como sea para atacarte, y no vamos a saber todas las posibilidades de comillas, numeros, palabras, etc que este pueda utilizar. Mi mas recomendado consejo en este tipo de situaciones, son los procedimientos almacenados en SQL. Se que resulta un poco incomodo tener que aprender a realizar procedimientos en la base de datos sino es tu area, pero por recomendacion personal propia, yo lo veo como una manera muy efectiva de prevenir ataques por inyeccion SQL, ya que los procedimientos almacenados evitan leer despues de un espacio en blanco.

Opciones hay varias en internet, existen hasta scripts, parches, modulos, etc. Pero yo expongo la manera de cuidar no solo a nivel de programacion y servidor web, sino cuidando tambien la base de datos, que mejor que cuidarse desde adentro hacia afuera, y no un parche solo externo que protega el web server dejando vulnerable a nuestra base de datos ante otros atentados externos.