Cuando hablé sobre los ataques de Black Hat SEO, os conté muy por encima que es un ataque por SQL Injection. Pues hoy vamos a ver una forma de evitarlos.
¿Qué es un ataque por Inyección SQL?
Con un ataque de este tipo lo que intentan es conseguir la información que almacenamos en nuestra base de datos, modificarla o incluso eliminarla. Para ello localizan archivos a los que les pasamos variables a través de GET o POST.
Vamos a ver un ejemplo, si tenemos un archivo con una query de este estilo:
&query='DELETE * FROM noticias WHERE id="'.$_GET['id'].'"';
En un archivo llamado noticias.php y le pasamos el parámetro id por la url (get), podrán atacarnos llamando al archivo y modificando los parámetros a pasarle:
noticias.php?id=12" OR 1="1
Si volvemos a la query, veremos que con los nuevos parámetros, esta quedaría así:
&query='DELETE * FROM noticias WHERE id="12" OR 1="1"';
Por lo que modificarían nuestra query, haciéndola siempre posible, pues 1 es igual a 1, por lo tanto eliminaría todas las noticias de nuestra tabla, cuando nosotros lo que queríamos era eliminar una única noticia.
En el caso de pasar las variables por POST también sería posible el ataque, pues añadirían el código malicioso en un campo del formulario dando el mismo resultado.
¿Cómo evitamos un ataque de este tipo?
Cómo no queremos que nos arruinen de por vida, vamos a utilizar dos funciones php muy útiles: sprintf y mysql_real_escape_string. Si las aplicamos a nuestra query, quedaría así:
$query = sprintf("DELETE * FROM noticias WHERE id='%d'",
mysql_real_escape_string($id));
Con sprintf damos formato a nuestra sentencia asignando el espacio justo para los parámetros a recoger (%d para un número, %s para una cadena, etc) y con mysql_real_escape_string escapamos caracteres especiales, por lo que si nos hicieran el mismo ataque (12″ OR 1=”1) nos devolvería esto:
&query='DELETE * FROM noticias WHERE id="12"';
Cómo véis sólo permanece el 12, eliminando el trozo ” OR 1=”1 y evitando así que la consulta siempre sea posible.
Porque más vale prevenir que curar 
Twittea esto Guardalo en Delicious Compartelo en Facebook
Enero 23rd, 2010 at 5:17 am
Tu lo has dicho, te lian una de estas y se acabó lo que se daba. Muy interesante la entrada
Enero 25th, 2010 at 17:26 pm
Gracias Public enemy
Este es mejor remedio que cruzar los dedos y esperar que no nos toque a nosotros xD
Enero 29th, 2010 at 11:02 am
Me ha gustado el artículo, es muy directo y entendible. Gracias, probaré tus códigos a ver que tal.
Saludos.
Febrero 18th, 2010 at 1:47 am
A partir de la versión 5 y creo que a partir de la 4.X de MySQL este problema ya está resuelto y no es necesario ningún tipo de protección extra. De todas formas el bug de MySQL también afecta a PHPMyAdmin con lo que tendrían acceso a todas las bases de datos que tuvieses ahí creadas, la liada sería mucho mayor.
Esta forma de reventar bases de datos ya está en desuso y tan solo se enseña a modo anecdotico en bases de datos para saber que se puede hacer si no se usa con cuidado, si sabes ocultar bien el código no tienen porque hacer daño a tu base de datos.
Un saludo!!
Febrero 22nd, 2010 at 18:47 pm
Gracias por tu comentario Alex!
javierh yo tengo entendido que no está en desuso, al contrario, que es bastante utilizado para ataques de black hat seo.. aunque ya me dejas en duda, voy a tener que investigar un poquito más.. gracias por el dato!