SQL Injection: Hibernate

El uso de Hibernate para ejecutar instrucciones SQL dinámicas creadas con una entrada procedente de un origen que no es de confianza puede permitir que un usuario malintencionado modifique el significado de la instrucción o ejecute comandos SQL arbitrarios.

Se producen errores de SQL Injection cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.



2. Los datos se utilizan para crear de forma dinámica una consulta HQL.

Ejemplo 1: el código siguiente crea y ejecuta dinámicamente una consulta HQL que busca elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos donde el propietario coincide con el nombre de usuario del usuario autenticado actualmente.

...
	String userName = ctx.getAuthenticatedUserName();
	String itemName = request.getParameter("itemName");
	String query = "FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ itemName + "'";
	List items = sess.createQuery(query).list();
	...

La consulta intenta ejecutar el código siguiente:

	SELECT * FROM items
	WHERE owner = <userName>
	AND itemname = <itemName>;

Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, la consulta solo funciona correctamente si itemName no contiene un carácter de comilla simple. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name' OR 'a'='a" para itemName, la consulta se convertirá en lo siguiente:

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name' OR 'a'='a';

La adición de la condición OR 'a'='a' hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la consulta más simple:

	SELECT * FROM items;

Esta simplificación de la consulta permite que el usuario malintencionado pueda eludir el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las entradas almacenadas en la tabla items, independientemente del propietario especificado.

Ejemplo 2: En este ejemplo se examinan los efectos de un valor malintencionado distinto que pasó a la consulta creada y ejecutada en el Example 1. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name'; DELETE FROM items; --" para itemName, la consulta se convertirá en las dos consultas siguientes:

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	--'

Muchos servidores de base de datos, incluido Microsoft(R) SQL Server 2000, permiten que se ejecuten al mismo tiempo varias instrucciones de SQL separadas por punto y coma. Mientras que esta cadena de ataque da como resultado un error en Oracle y otros servidores de base de datos que no permiten la ejecución por lotes de instrucciones separadas por punto y coma, en las bases de datos que permiten la ejecución por lotes, este tipo de ataque permite al usuario malintencionado ejecutar comandos arbitrarios en la base de datos.

Tenga en cuenta el par final de guiones (--), que indican a la mayoría de los servidores de base de datos que el resto de la instrucción se debe tratar como un comentario y no ejecutarse [4]. En este caso el carácter de comentario sirve para quitar la comilla simple final de la consulta modificada. En una base de datos donde no se permite que los comentarios se utilicen de esta manera, el ataque general tendría posibilidades de efectuarse con un truco similar al que se muestra en el Example 1. Si un usuario malintencionado escribe la cadena "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", se crearán las tres instrucciones válidas siguientes:

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	SELECT * FROM items WHERE 'a'='a';

Un enfoque tradicional para la prevención de ataques de SQL Injection es tratarlos como un problema de validación de entradas y aceptar solo los caracteres de una lista de valores seguros permitidos, o bien identificar y omitir una lista de valores potencialmente malintencionados (lista de rechazados). La comprobación de una lista de permitidos puede ser un medio eficaz para aplicar reglas estrictas de validación de entradas, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, implementar una lista de rechazados presenta enormes lagunas que la hacen ineficaz para impedir los ataques de SQL Injection. Por ejemplo, los atacantes podrían:

- Elegir como destino campos que no están entre comillas
- Buscar formas de omitir la necesidad de determinados metacaracteres de escape
- Utilizar procedimientos almacenados para ocultar los metacaracteres inyectados

Eludir manualmente los caracteres de entrada de las consultas SQL puede ayudar, pero no hará que la aplicación sea segura frente a los ataques de SQL Injection.

Otra solución que comúnmente se propone para afrontar los ataques de SQL Injection consiste en utilizar los procedimientos almacenados. Aunque los procedimientos almacenados evitan algunos tipos de ataques de SQL Injection, no pueden proteger frente a muchos otros. Los procedimientos almacenados normalmente ayudan a prevenir los ataques de SQL Injection al limitar los tipos de instrucciones que se pueden pasar a sus parámetros. Sin embargo, existen muchas formas de limitaciones y muchas instrucciones interesantes que pueden pasarse a los procedimientos almacenados. Por otra parte, los procedimientos pueden impedir algunos tipos de ataques, pero no lograrán proteger la aplicación frente a ataques de SQL Injection.