Es bien conocido por todos aquellos adeptos a la red que existen fallos de seguridad en páginas de internet. Dichos fallos de seguridad se dan en muchos casos por ignorar prácticas mínimas en cuanto al desarrollo web y otras veces son simplemente el fruto de un descuido o un bug inimaginable en la tecnología utilizada para el desarrollo.
Lo primero que RedesZone quiere destacar es que la mencionada página es completamente segura y fiable: un fallo no constituye una generalidad y en este caso la compra de entradas (finalidad última de la página) no se ve alterada en absoluto, siendo la seguridad una constante patente e innegable.
Así mismo, este artículo no tiene como propósito enseñar ni motivar la violación de páginas web en ninguna medida, sino mas bien todo lo contrario: mostrar donde se encuentra el agujero de seguridad para que futuros desarrolladores de páginas web realicen proyectos mas fiables y seguros.
Con esos objetivos en mente, las consultas, la información que pudiera ser de carácter vital para la seguridad de la página o cualquier dato sensible han sido ocultados y/o cambiados.
Por supuesto, el fallo que se recogía en esta página ya ha sido solucionado: RedesZone nunca ha publicado ni publicará o divulgará bajo ningún motivo fallos que puedan ser explotados.
Vamos a explicar la naturaleza del fallo de la página y su solución.
Si visitamos la siguiente URL: www.compraentradas.com, vemos que podemos escoger para pinchar y continuar la navegación una serie de enlaces. Navegando un poco por la página llegamos a una cuyos parámetros contienen un campo, ID=10, dando como resultado esta página: (se ha ocultado la información que podría resultar sensible)
Observemos por un momento la URL de la página:
http://www.compraentradas.com/paginaPropia.php?parametro1 =4¶metro2=XX
Como se puede observar, la página contiene una serie de parámetros que se pasan por dicha URL y que van a ser el objeto de nuestro ataque.
Lo primero que debemos hacer para comprobar que la página es vulnerable a un ataque de SQL Injection. Para ello vamos a poner en el parámetro parametro1 un ID que no exista, por ejemplo:
http://www.compraentradas.com/paginaPropia.php?parametro1=43132313132123¶metro2=XX
Dicha consulta da como resultado la siguiente página: (se ha ocultado la información que podría resultar sensible).
En este caso, todo parece normal, es decir, al poner una URL que no existe, la página muestra como resultado un marco en blanco.
El siguiente paso sería poner algo que un motor de SQL no fuera capaz de entender. Si el resultado de esta prueba es satisfactoria, la página sería vulnerable puesto que no sería capaz de filtrar el contenido que se le ha puesto para la ejecución de la consulta.
Vamos a poner algo como esto (damos por hecho que la consulta sólo admite números en el parámetro1.
Sería algo como esto:
http://www.compraentradas.com/paginaPropia.php?parametro1=4313KKK¶metro2=XX
Si utilizamos esta consulta, da como resultado la siguiente página: (se ha ocultado la información que podría resultar sensible para evitar a los Script Kiddies).
En este caso, ya hemos comprobado que la consulta no filtra los parámetros y que podría ser vulnerable a una inyección. Lo siguiente que un hacker comprobaría sería algo como esto:
http://www.compraentradas.com/paginaPropia.php?parametro1=4313KKK+and+(select+count(*)+from+tabla)>0¶metro2=XX
Si la consulta devuelve una página correcta, significaría que la tabla que hemos puesto existe y la consulta es verdadera y fiable.
Si pusiéramos una consulta que contuviera errores o cuyos campos no fueran correctos, saldría de nuevo la siguiente página o alguna parecida (se omite información que puede resultar sensible)
Jugando un poco con los parámetros de dicha consulta, se llegaría al resultado siguiente:
http://www.compraentradas.com/paginaPropia.php?parametro1=4313+and+(select+count(*)+from+tabla+where+id_tabla_columna=1+and+substring(campo,1,1)>0X129)>0¶metro2=XX
Si esta consulta da como resultado una página correcta, significaría que la posición 1 del campo campo de la tabla tabla tiene es igual a 0X129.
Automatizando este tipo de ataque (existen automatizadores para ello ya escritos) se podrían obtener los datos de cualquier usuario de la web, con lo que el ataque llegaría a obtener datos que serían de carácter personal.
SOLUCIÓN DEL ERROR
En el caso que ocupa a nuestro artículo, el fallo de SQL Injection fue posible debido al no filtrado de algunos parámetros de la aplicación. La corrección de dicho fallo atiende al principio siguiente:
Todo lo que sea de carácter público debe ser filtrado.
Con esta sencilla premisa, el 90% de los ataques pueden evitarse.
Desde RedesZone, queremos agradecerle al director general propietario de compraentradas, Juan Manuel Heredia Gallardo, su amabilidad en el trato y que nos haya permitido publicar este error de seguridad.
Os dejamos un artículo donde explicamos qué es la inyección SQL.
