Los ataques de SQL Injection suponen un riesgo enorme para las aplicaciones web que dependen de un backend de base de datos para generar contenido dinámico. En este tipo de ataque, los hackers 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, vea los Ataques de Inyección SQL a las Bases de Datos. En este artículo, echamos un vistazo a varias formas en las que puede probar sus aplicaciones web para determinar si son vulnerables a los ataques de inyección SQL.

Escaneo automatizado por inyección SQL

Una posibilidad es utilizar un escáner de vulnerabilidades de aplicaciones 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 para detectar posibles vulnerabilidades de SQL Injection. Sin embargo, son bastante caros, ya que cuestan hasta $25,000 por asiento.

Pruebas de inyección SQL manuales

¿Qué debe hacer un desarrollador de aplicaciones deficiente? En realidad, puede ejecutar algunas pruebas básicas para evaluar sus aplicaciones web en busca de vulnerabilidades de SQL Injection utilizando nada más que un navegador web. Primero, una palabra de precaución: las pruebas que describimos sólo buscan fallas básicas en la inyección SQL. No detectan técnicas avanzadas y son algo tediosas de usar. Si puede permitírselo, utilice un escáner automático. Sin embargo, si usted no puede manejar esa etiqueta de precio, la prueba manual es un gran primer paso.La manera más fácil de evaluar si una aplicación es vulnerable es experimentar con ataques de inyección inocuos que en realidad no dañarán su base de datos si tienen éxito, pero que le proporcionarán evidencia de que necesita corregir un problema. Por ejemplo, supongamos que usted tiene una simple aplicación web que busca a un individuo en una base de datos y proporciona información de contacto como resultado. Esa página puede usar el siguiente formato de URL:

Podemos asumir que esta página realiza una búsqueda en la base de datos, utilizando una consulta similar a la siguiente:

SELECT phone
> SELECT phone

 directorio FROM 

< >.

Experimentemos un poco con esto. Con nuestra suposición anterior, podemos hacer un simple cambio en la URL que prueba los ataques de inyección 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 SQL, simplemente conecta este nombre falso en la sentencia SQL que ejecuta contra la base de datos, lo que resulta en:

SELECT phone

>Seleccionar teléfono

Directorio FROM

.WHERE apellido =’chapple’ y nombre=’mike’<
>.

AND (seleccione count(*) de fake)> 0

.

OR '1'='1'

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>.

Notarás que la sintaxis de arriba es un poco diferente a la de la URL original. Nos tomamos la libertad de convertir la variable con codificación 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 añadimos algunos saltos de línea para propósitos similares.

Evaluación de los resultados

La prueba se produce cuando se intenta cargar la página web con la URL indicada anteriormente. Si la aplicación web se comporta bien, 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 ha encontrado ningún usuario con el nombre mike+AND+(select+count(*)+from+fake)+%3e0+OR+1%3d1
.Chapple!

Por otro lado, si la aplicación es vulnerable a la inyección SQL, pasará la sentencia directamente a la base de datos, resultando en una de dos posibilidades. En primer lugar, si su servidor tiene activados los mensajes de error detallados (lo que no debería), verá algo parecido a esto:

Pre>Microsoft OLE DB Provider for ODBC Drivers error <'80040e37'
[Microsoft][ODBC SQL Server Driver][SQL Server]Nombre de objeto inválido ‘falso’.

/directory.asp, línea 13

.

Por otro lado, si su servidor web no muestra mensajes de error detallados, obtendrá un error más genérico, como:

Error interno del servidor
El servidor encontró un error interno o una mala configuración y no pudo completar su solicitud.Si recibe uno de los dos errores anteriores, su aplicación es vulnerable al ataque de inyección SQL. Algunos de los pasos que puede seguir para proteger sus aplicaciones contra los ataques de SQL Injection incluyen: