03- Connection String Attacks (II de VI)

Delegación de autenticación en aplicaciones web

A la hora de establecer un sistema de autenticación para una aplicación web se puede optar por crear un sistema propio de credenciales o delegar la autenticación al motor de base de datos.

En muchas ocasiones el programador de la aplicación opta por utilizar un único usuario para conectarse al motor de base de datos. Este usuario representará a la aplicación web dentro del motor de base de datos y ella misma, utilizando esta conexión, realizará consultas a una tabla de usuarios dónde gestiona las credenciales de usuario.

Figura 4: Autenticación controlada por la aplicación web
Como se utiliza un único usuario que accede a todo el contenido de la base de datos se hace imposible implantar un sistema granular de permisos sobre los diferentes objetos de la base de datos o realizar un seguimiento de las acciones de cada usuario, delegando estas tareas en la propia aplicación Web. Si un atacante es capaz de aprovechar vulnerabilidades en el código de la aplicación para acceder a la base de datos, esta quedara completamente expuesta. Esta arquitectura es utilizada por la mayoría aplicaciones web expuestas a Internet, como Joomla o Mambo entre otros.

Como ventaja, permite al administrador de la base de datos no tener un gran número de usuarios que puede que sólo accedan una vez a la aplicación y disfrutar de un entorno mucho más fácilmente portable de un entorno a otro. El objetivo de un atacante en este tipo de entorno será extraer el contenido de la tabla de usuarios para poder acceder a las credenciales.

La otra alternativa, consiste en implementar una delegación del proceso de autenticación en la base de datos, así se puede utilizar la cadena de conexión para comprobar las credenciales de un usuario. Si el usuario existe y tiene privilegios podrá conectar la aplicación a la base de datos. Por el contrario, si el usuario no tiene privilegios no podrá entrar en la base de datos y, por tanto, tampoco podrá acceder a la aplicación web.

Este sistema permite delegar toda la lógica y gestión de credenciales al motor de bases de datos. Como ventajas, esta arquitectura permite auditar granularmente los permisos en la base de datos, así como tracear fácilmente y evitar ataques de elevación e privilegios cuando se produzcan fallos en el código de la aplicación web. Como inconveniente principal tiene la necesidad de dar de alta en el sistema todos los usuarios. Sin embargo, para aquellas aplicaciones web cuyo objetivo es gestionar la propia base de datos, es necesario utilizar una arquitectura como ésta.

Figura 5: Autenticación en aplicaciones web delegada
Cada uno de estos sistemas ofrece diferentes ventajas e inconvenientes. Este artículo se centra en el segundo de los entornos, es decir, aplicaciones web con al autenticación delegada al motor de bases de datos.

Connection String Injection

Las técnicas de Connection String Injection permiten a un atacante, en un entorno de validación delegada, inyectar parámetros mediante la adición de nuevos parámetros con el carácter punto y coma.

Suponiendo un ejemplo en el que se solicite usuario y contraseña para crear una cadena de conexión, un atacante podría quitar el sistema de encriptación introduciendo, en este caso en la contraseña algo como:

contraseña; Encryption=off

Al generar la cadena de conexión se añadirá el valor Encryption a los parámetros configurados previamente.

Connection String Builder en .NET

Microsoft, conociendo la posibilidad de realizar este tipo de inyecciones en las cadenas de conexión, incluyó a partir de la versión 2.0 del Framework las clases“ConnectionStringBuilder”, que permiten, a través de la clase base(DbConnectionStringBuilder) o través de las clases especificas para los diferentes proveedores (SqlConnectionStringBuilder, OleDbConnectionStringBuilder, etcetera), crear cadenas de conexión con una sintaxis correcta y de forma segura, ya que solo se admiten pares clave/valor validos y se controlan los intentos de inserción de entradas malintencionadas escapando adecuadamente los intentos de inserción.

Figura 6: Información en MS sobre Injección en cadenas de conexión
El uso de estas clases a la hora de construir dinámicamente una cadena de conexión evitaría las inyecciones, sin embargo, no es utilizado por todos los desarrolladores de código y, por supuesto, no por todas las aplicaciones. Esto puede ser debido principalmente a la no existencia de formas de atacar estas vulnerabilidades de manera práctica, ya que basta con echar un vistazo a OWASP y descubrir que no hay documentada ninguna forma de ataque.

Figura 7: Resultados en OWASP sobre ataques a cadenas de conexión