El primer paso es entender cuando la aplicación interactua con un servidor de base de datos para acceder a los datos.
Algunos ejemplos cuando una aplicación necesita hablar con una base de datos:
Authentication forms( formularios de autenticacion):
Esto es cuando la autenticacion se realiza a traves de un formulario web, es muy probable que las credenciales de usuario se comparen con una base de datos que contiene todos los nombres de usuario y contraseñas ( o, hashes de contraseñas).
Search engine ( motores de busqueda):
La cadena enviada por el usuario puede ser utilizada en una consulta SQL que extrae todos los registros relevantes de una base de datos.
E-commerce sites(sitios de comercio electronico):
Es muy probable que los productos y sus características ( precio,
descripción, disponibilidad,etc.) se almacenen en una base de datos.
el testeador tiene que hacer una lista de todos los campos de entrada cuyos valores puedan ser utilizados en la creación de una consulta SQL, incluyendo campos ocultos de las peticiones POST y luego probarlos por separado, tratando de interferir con la consulta y generar un error.
considere también las cabeceras HTTP y las COOKIES.
La primera prueba suele consistir en añadir una sola cita (') o un punto y coma (;) al campo o parámetro que se esta probando.
El primero se utiliza en SQL como terminador de cadenas y, si no se filtra por la aplicación, daría lugar a una consulta incorrecta.
La segunda se utiliza para terminar una Sentencia SQL y, si no se filtra, también es probable que genere un error. La salida de un campo vulnerable puede parecerse a la siguiente ( en un Microsoft SQL Server, en este caso):
También se pueden utilizar delimitadores de comentarios (- or /**/,etc.) y otras palabras clave como SQL como AND y OR para intentar modificar la consulta.
una técnica muy simple pero a veces todavía efectiva es simplemente insertar una cadena donde se espera un numero, ya que se puede generar un error como el siguiente:
Supervise todas las respuestas desde el servidor web y eche un vistazo al código fuente HTML/Javascript. A veces el error presente en su interior, pero por alguna razon ( por ejemplo, un error de javascript, comentarios HTML,etc.) no se presenta al usuario.
Un mensaje de error completo, como los de los ejemplos, proporciona una gran cantidad de información al testeador con el fin de montar una ataque de inyección exitoso.
Sin embargo, las aplicaciones a menudo no proporcionan tantos detalles; un simple '500 Server Error' o una pagina de error personalizada puede ser emitida, lo que significa que necesitamos usar técnicas de inyección ciega.
En cualquier caso, es muy importante probar cada campo por separado; solo una variable debe variar mientras que todas las demás permanecen constantes, para poder entender con precisión que parámetros son vulnerables y cuales no.
PD: Parte 4 se llamara "Standard SQL Injection Testing"
No hay comentarios.:
Publicar un comentario