SQL Injection: MyBatis Mapper

La creación de una instrucción SQL dinámica con una entrada procedente de un origen que no es de confianza podría permitir a un usuario malintencionado modificar el significado de la instrucción o ejecutar comandos SQL arbitrarios.

Se producen errores SQL Injection cuando:

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

2. Los datos se utilizan para crear dinámicamente una consulta SQL.



Los archivos XML del asignador MyBatis le permiten especificar parámetros dinámicos en las instrucciones SQL y suelen estar definidos con los caracteres #, de este modo:

    <select id="getItems" parameterType="domain.company.MyParamClass" resultType="MyResultMap">
        SELECT *
        FROM items
        WHERE owner = #{userName}
    </select>

El carácter # con llaves alrededor del nombre de la variable indica que MyBatis creará una consulta parametrizada con la variable userName. Sin embargo, MyBatis también le permite concatenar variables directamente con instrucciones SQL usando el carácter $, lo que abre la puerta a la SQL Injection.

Ejemplo 1: El código siguiente crea y ejecuta dinámicamente una consulta SQL 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 actualmente autenticado.

    <select id="getItems" parameterType="domain.company.MyParamClass" resultType="MyResultMap">
        SELECT *
        FROM items
        WHERE owner = #{userName}
        AND itemname = ${itemName}
    </select>

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, solo funciona correctamente si itemName no contiene un carácter de comilla simple. Si un atacante 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 siguiente consulta mucho más simple:

    SELECT * FROM items;

Esta simplificación de la consulta permite que el atacante 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 impedir ataques SQL Injection es tratarlos como un problema de validación de entrada y aceptar solo los caracteres de una lista de valores seguros permitidos o bien identificar y excluir una lista de valores potencialmente malintencionados (lista de denegación). Las listas de permitidos pueden ser un medio muy eficaz de aplicar estrictas reglas de validación de entrada, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, la lista de denegación presenta enormes lagunas que la hacen ineficaz para impedir los ataques 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

La asignación manual de escapes a los caracteres de la entrada de las consultas SQL puede servir de ayuda, pero no garantizará la seguridad de la aplicación frente a los ataques SQL Injection.

Otra solución que comúnmente se propone para afrontar los ataques 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 transferir a sus parámetros. Sin embargo, existen muchas formas de saltar estas limitaciones y muchas instrucciones interesantes que pueden pasarse a los procedimientos almacenados. De nuevo, los procedimientos almacenados pueden evitar algunos ataques, pero no garantizarán la protección de la aplicación frente a ataques SQL Injection.