Los ataques de Inyección SQL plantean enormes riesgos para las aplicaciones web que dependen de un backend de base de datos para generar contenido dinámico. En este tipo de ataque, los piratas informáticos manipulan una aplicación web en un intento de inyectar sus propios comandos SQL en los emitidos por la base de datos. Para ver un ejemplo, consulte el artículo Ataques de inyección SQL en bases de datos. En este artículo, echamos un vistazo a varias formas en que puede probar sus aplicaciones web para determinar si son vulnerables a los ataques de inyección de SQL.
Escaneo automatizado de inyección SQL
Una posibilidad es usar un escáner de vulnerabilidad de aplicación web automatizado, como WebInspect de HP, AppScan de IBM o Hailstorm de Cenzic. Todas estas herramientas ofrecen formas fáciles y automatizadas de analizar sus aplicaciones web en busca de posibles vulnerabilidades de inyección de SQL. Sin embargo, son bastante caros, con un costo de hasta $ 25,000 por asiento.
Pruebas de inyección manual de SQL
¿Qué es un pobre desarrollador de aplicaciones para hacer? En realidad, puede ejecutar algunas pruebas básicas para evaluar sus aplicaciones web en busca de vulnerabilidades de Inyección de SQL usando nada más que un navegador web. Primero, una advertencia: las pruebas que describimos solo buscan fallas básicas de Inyección de SQL. No detectarán técnicas avanzadas y son algo tediosas de usar. Si se lo puede permitir, vaya con un escáner automatizado. Sin embargo, si no puede manejar esa etiqueta de precio, las pruebas manuales son un excelente primer paso.La forma más fácil de evaluar si una aplicación es vulnerable es experimentar con ataques de inyección inocuos que no dañarán su base de datos si tienen éxito, pero le proporcionarán pruebas de que necesita corregir un problema. Por ejemplo, suponga que tiene una aplicación web simple que busca un individuo en una base de datos y, como resultado, proporciona información de contacto. Esa página podría usar el siguiente formato de URL: http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike
Podemos suponer que esta página realiza una búsqueda en la base de datos, utilizando una consulta similar a la siguiente: Teléfono SELECT
Del directorio
DÓNDE lastname = 'chapple' and firstname = 'mike'
Vamos a experimentar con esto un poco. Con nuestro supuesto anterior, podemos hacer un cambio simple en la URL que prueba los ataques de inyección de SQL: http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike'+AND+(select+count(*)+from+fake)+%3e0+OR+'1'%3d'1
Si la aplicación web no ha sido protegida adecuadamente contra la inyección de SQL, simplemente conecta este nombre falso en la sentencia de SQL que ejecuta contra la base de datos, lo que resulta en: Teléfono SELECT
Del directorio
DÓNDE lastname = 'chapple' and firstname = 'mike'
Y (seleccione contar (*) de falso)> 0
O '1' = '1'
Notará que la sintaxis anterior es un poco diferente a la de la URL original. Nos tomamos la libertad de convertir la variable codificada en URL para sus equivalentes ASCII para que sea más fácil seguir el ejemplo. Por ejemplo,% 3d es la codificación URL para el carácter '='. También agregamos algunos saltos de línea para propósitos similares. La prueba se produce cuando intenta cargar la página web con la URL que se indica arriba. Si la aplicación web tiene un buen comportamiento, eliminará las comillas simples de la entrada antes de pasar la consulta a la base de datos. Esto simplemente resultará en una búsqueda extraña para alguien con un nombre que incluya un montón de SQL. Verá un mensaje de error de la aplicación similar al siguiente: Error: no se encontró ningún usuario con el nombre mike + AND + (seleccionar + contar (*) + de + falso) +% 3e0 + O + 1% 3d1
¡Chapple!
Por otro lado, si la aplicación es vulnerable a la inyección de SQL, pasará la declaración directamente a la base de datos, lo que dará como resultado una de las dos posibilidades. Primero, si su servidor tiene habilitados los mensajes de error detallados (que no debería), verá algo como esto: Proveedor Microsoft OLE DB para el error '80040e37' de los controladores ODBC
Microsoft Controlador ODBC para SQL Server SQL Server Nombre de objeto no válido 'falso'.
/directory.asp, linea 13
Por otro lado, si su servidor web no muestra mensajes de error detallados, obtendrá un error más genérico, como: error de servidor internoEl servidor encontró un error interno o una configuración incorrecta y no pudo completar su solicitud.
Comuníquese con el administrador del servidor para informar de la hora en que ocurrió el error y de cualquier cosa que haya hecho que pueda haber causado el error.
Más información sobre este error puede estar disponible en el registro de errores del servidor.
Si recibe uno de los dos errores anteriores, su aplicación es vulnerable a un ataque de inyección SQL. Algunos pasos que puede tomar para proteger sus aplicaciones contra ataques de Inyección de SQL incluyen: Evaluando los Resultados
