SQL Injection: MyBatis Mapper

通过来自不受信任数据源的输入构建动态 SQL 语句，攻击者就能够修改语句的含义或者执行任意 SQL 命令。

SQL Injection 错误会在以下情况下出现：

1.数据从一个不可信数据源进入程序。

2.数据用于动态地构造 SQL 查询。



使用 MyBatis Mapper XML 文件可在 SQL 语句中指定动态参数，而这些文件通常使用 # 字符来定义，如下所示：

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

使用 # 字符并在变量名称两侧添加大括号表示 MyBatis 将创建含 userName 变量的参数化查询。但是，MyBatis 也允许使用 $ 字符将变量直接连接到 SQL 语句，因而为发动 SQL Injection 攻击敞开了大门。

示例 1：下列代码可动态地构建并执行一个 SQL 查询，用来搜索与指定名称相匹配的条目。该查询仅会显示条目所有者与当前经过身份验证的用户的名称一致的条目。

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

但是，由于该查询是动态构造的，由一个常数基本查询字符串和一个用户输入字符串连接而成，因此只有在 itemName 不包含单引号字符时，该查询才能正常运行。如果一个用户名为 wiley 的攻击者为 itemName 输入字符串“name' OR 'a'='a”，则该查询会变成：

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

如果添加条件 OR 'a'='a'，WHERE 子句的值将始终为 true，这样该查询在逻辑上就等同于一个更为简单的查询：

    SELECT * FROM items;

通常，查询应仅返回已通过身份验证的用户所拥有的条目，而通过以这种方式简化查询，攻击者就可以规避这一要求。现在，查询会返回存储在 items 表中的所有条目，而不论其指定所有者是谁。

示例 2：此示例说明了将不同的恶意值传递给Example 1.中构造和执行的查询所带来的影响。如果一个用户名为 wiley 的攻击者为 itemName 输入字符串“name'; DELETE FROM items; --”，则该查询就会变为以下两个查询：

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

    DELETE FROM items;

    --'

包括 Microsoft(R) SQL Server 2000 在内的很多数据库服务器都可以一次性执行多条用分号分隔的 SQL 语句。在不允许批量执行用分号分隔的语句的 Oracle 和其他数据库服务器上，此攻击字符串只会导致错误；但是在支持批量执行的数据库上，此类型攻击可以使攻击者针对数据库执行任意命令。

注意末尾的一对连字符 (--)；这在大多数数据库服务器上都表示该语句剩余部分将视为注释，不会加以执行 [4]。在这种情况下，可通过注释字符删除修改后的查询遗留的末尾单引号。而在不允许通过这种方式使用注释的数据库上，攻击者通常仍可使用类似于 Example 1 中所用的技巧进行攻击。如果攻击者输入字符串“name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a”，将创建以下三个有效语句：

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

    DELETE FROM items;

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

阻止 SQL Injection 攻击的一种传统方法是将其作为一种输入验证问题来处理，只接受列在安全值允许列表中的字符，或者识别并避免列表中的潜在恶意值（拒绝列表）。检查允许列表是一种非常有效的方法，它可以强制执行严格的输入验证规则，但是参数化的 SQL 语句所需的维护工作更少，而且能提供更好的安全保障。而对于通常采用的拒绝列表实现方式，由于总是存在一些小漏洞，所以并不能有效地防止 SQL Injection 攻击。例如，攻击者可以：

- 将未引用的字段作为目标
- 寻找方法以绕过某些需要转义的元字符
- 使用存储过程隐藏注入的元字符

手动转义 SQL 查询输入中的字符有一定的帮助，但是并不能保证完全保护您的应用程序免受 SQL Injection 攻击。

防范 SQL Injection 攻击的另外一种常用解决方法是使用存储过程。虽然存储过程可以阻止某些类型的 SQL Injection 攻击，但是对于绝大多数攻击仍无能为力。存储过程有助于避免 SQL Injection 攻击的常用方式是限制可传入存储过程参数的语句类型。但是，有许多方法都可以绕过这一限制，许多危险的语句仍可以传入存储过程。所以再次强调，存储过程在某些情况下可以避免一些漏洞，但是并不能完全保护您的应用程序免受 SQL Injection 攻击。