Es una amenaza latente que todo programador o desarrollador de aplicaciones web debe tenerlo siempre presente, cuantos más tipos de filtros o validaciones tengan sus formularios será mejor, aunque está cien por cien comprobado que no hay ninguna web que esté inmune al ataque de estas personas mal nombradas como “hackers”. Bien profundicemos más ésta técnica.
Como todos sabemos en toda web dinámica existe una comunicación directa y en tiempo real entre el servidor de datos y los clientes que acceden a ella, por citar un ejemplo sencillo, para acceder a una web restringida ésta nos solicita usuario y contraseña (comúnmente llamado loguearse) ; la web le presenta un formulario donde el usuario ingresa su usuario y contraseña, éstos datos son enviados generalmente a otro archivo que los procesa, el cual realiza una query (consulta SQL) accediendo a la BD sin más.  Mas o menos de ésta manera:

$sql= "SELECT * FROM usuarios WHERE usuario = '" + Usuario + "' and password ='"+ pass + "';"

Un usuario común y corriente colocaría por ejemplo su usuario y contraseña normal, así: pepe y 020304 respectivamente, lo que la consulta quedaría así :

Hasta aquí todo normal, pero qué pasaría si un usuario mal intencionado además de esto agregara lo siguiente  en el campo password:

El código de color rojo es la inyección SQL que se está realizando, y esto tranquilamente nos permitiría ingresar en sitios restringidos, claro está en aquellas web donde no le han dado la respectiva importancia a ésta técnica. Lo que la query quedaría así:

Como vemos la inyección sql (de color rojo) se ha realizado con la intención de burlar la restricción de acceso, pero se puede realizar cosas mucho más desastrosas en la BD, cosas como estas:

Con lo cual nos eliminaría toda la tabla que almacena los datos de los usuarios. “Terrible verdad!”
En conclusión está técnica mal intencionada de dañar  webs puede llegar a ser realmente lamentable para los webmasters  ya que coloca código malicioso embebido dentro del bueno.

PROTEGERSE  DE LAS INYECCIONES SQL

ASIGNACION DE MÍNIMOS PRIVILEGIOS.
La cuenta que se determina para conectarse en una aplicación web, debe tener sólo privilegios que ésta necesita, ni más ni menos , demás está decir que no se debe conectar como usuario “SA” o como administrador, por el contrario la cuenta sólo debe acceder a los objetos que la aplicación necesita.

VALIDAR  TODAS LAS ENTRADAS
Si utiliza campos de texto en el que sólo  se deben ingresar números pues valídelos para tal efecto y especifique la longitud de caracteres a ingresar. Si permite el ingreso de texto asegúrese  de  que su aplicación busca caracteres como comas, puntos y comas, signo igual, paréntesis, palabras claves SQL,  Todos los lenguajes de programación  emplean expresiones regulares, para este tipo de validación así que no hay excusa para ningún desarrollador o programador  emplearlos. Pareciera que este tipo de protección fuera obvia, pero muy a menudo es la principal deficiencia que convierte a una aplicación web vulnerable a los ataques por inyección SQL.

EMPLEO DE PROCEDIMIENTOS ALMACENADOS
Utilizar las instrucciones SQL “puras” embebidas en el lenguaje de programación a utilizar, es una potente herramienta en las aplicaciones web, pero la combinación de este SQL dinámico con la entrada de datos del usuario hace mucho más vulnerable a nuestra aplicación web. Utilizar procedimientos almacenados y aceptar los datos del usuario como parámetros en lugar de cómo comandos sql, limitaría a lo que cualquier intruso quisiera hacer.
UTILIZAR COMILLAS DOBLES EN LUGAR DE SIMPLES
En el archivo que procesa los datos de entrada del usuario reemplazar  las comillas simples por comillas dobles, ésta simple precaución puede determinar el truncamiento de las inyecciones SQL, dado que las comillas simples finalizan las expresiones SQL,  y posibilitan la entrada de expresiones de más potencia, la simple sustitución de la comilla simple hará que al atacante en su inicio por inyectar SQL lo lleve al fracaso.

INYECCIÓN  SQL  AVANZADA

- OBTENIENDO INFORMACION DE LOS MENSAJES DE ERROR
Ésta es la manera como personas sin escrúpulos valiéndose, del motor de la base de datos, va obtenido información relevante de la estructura de la base de datos, y porque no decir los datos que ella contiene, con una sencilla orden como ésta
Suponiendo que la figura de la BASE DE DATOS ES LA SIGUIENTE:

   Create table users(  id int,
       Username varchar(255),
      Password varchar(255),
       Privs int
   )

Y tiene un formulario de login con los campos username y password
Entonces el atacante empieza averiguar de la siguiente manera.
En el campo username realiza la inyección, así :

Username: ‘ having 1=1 –-

Bien veamos que le devuelve el motor de la base de datos.

Pues como se observa ya averiguo el nombre de la tabla y el nombre del campo que tiene la llave principal, y así podrá terminarse de averiguar con toda la estructura de la base de datos.
Así que hay que vigilar muy bien este tipo de inyección avanzada

- ELIMINANDO LAS COMILLAS SIMPLES
Ahora si los desarrolladores  usan algún tipo de método  o función para filtrar las comillas simples (‘)., y admitimos que con esto, estaría por resuelto la inyección SQL estaríamos engañándonos , aquí una línea de código SQL . a tener  en cuenta:

Aquí realiza una perfecta instrucción SQL de actualización de datos, Y LO MAS IMPORTANTE SIN UTILIZAR LAS COMILLAS SIMPLES.

- LIMITANDO LA LONGITUD DE INGRESO DE CARACTERES.
Limitar la longitud de caracteres que el usuario puede ingresar en la aplicación es una enorme obstrucción para el atacante, pero no imposible en hacer daño a nuestra aplicación; porque con una pequeña cantidad de código inyectado puede darnos más de un dolor de cabeza, así por ejemplo :

Con esto el atacante conseguirá que se apague el  servidor de datos. Usando tan sólo 12 caracteres como inyección SQL. Recordad, que los guiones (--) generan un comentario en la misma línea con lo cual no provocaría error en la línea SQL generada.
O también puede realizar lo siguiente:

Con esto está más que suficiente demostrado el daño que causaría, ya  que nos eliminaría cualquiera de nuestras tablas.

Referencias:
http://www.bhean.com/downloads/InyeccionDeSQLAvanzada.doc
http://www.bhean.com/downloads/InyeccionDeSQLAvanzada.doc
http://blogs.ngingenieria.com/?p=34