Presentación HDIV
SQL Injection
En este caso la fuente del problema radica en las malas prácticas de programación en la capa de acceso a datos.
Ejemplo: Supongamos que disponemos de una página web en la que se requiere identificación al usuario mediante un formulario. Una vez rellenados el usuario password se envían los dos parámetros hacía img src el servidor:
Como podemos apreciar en el ejemplo, la sql lanzada contra la base de datos se compone mediante la concatenación directa de los datos obtenidos desde el cliente.
Con una petición normal en la que se envían dos datos esperados, la sql generada no comporta ningún problema, pero si los valores son modificados podemos tener un problema de seguridad. Por ejemplo, si el usuario y password enviados son los siguientes:
En este caso, la sql generada es muy diferente puesto que nos devuelve todos los usuarios de la tabla de usuarios sin haber aportado un usuario y password validos. En consecuencia, y si el programa no controla el número de registros obtenidos, podría entrar en la zona privada de la aplicación sin disponer de una credencial que lo permita.
Las consecuencias de la explotación de esta vulnerabilidad puede ser mitigada si se limitan los permisos del usuario de base de datos que es utilizado por la aplicación. Por ejemplo, si el usuario tiene permisos de borrado de datos las consecuencias de ser vulnerables a esta vulnerabilidad pueden ser extremadamente graves.