Hoy tenia ganas de escribir un post sobre Blind Sqlinjection, y dado que este tipo de problema es mas facil explicarlo por medio de un ejemplo, hice una búsqueda en Google para ver algún sitio que ayudara a entender la vulnerabilidad.
Generalmente haciendo una búsqueda con inurl: y alguna expresión con el termino ID vamos a recibir varios sitios como respuesta. Entre los sitios seguramente una parte sufre de este tipo de problemas.
Verificar si un sitio sufre de Blind Sql Injection es fácil.
Verificar digo, no aprovechar. Esto ultimo es mas complicado pero no imposible.
Entonces realice una búsqueda y elegi un sitio al azar, este sitio parecía prometedor tenia como entrada un código de articulo y un par de parámetros mas.
Para verificar como respondía, deje solamente el código de articulo , no ingrese ningún parámetro , ni carácter especial.
Pero lo que devolvió fue esto :
Este error que vimos, dice poco , solo nos informa el path y el query con el que se accede a los datos.
Este que sigue, ya es un poco mas complicado. ( click para ampliar )
Entrega el código del SQL, el tipo de Base de Datos, el nombre de la base de datos, el path y el tipo de aplicación con el cual fue desarrollado.
Es decir, estamos ante dos de los problemas que vimos en este post :
1 ) Nunca confiar en lo que envia el usuario, validar lo que se ingresa.
2 ) En caso de problemas, mostrar al usuario una pagina de error pre configurada. Nunca entregar información en los errores.
Para quienes busquen buenas practicas para desarrollo de aplicaciones, un buen sitio para comenzar es OWASP.
No comments:
Post a Comment