SQL Injection: SubSonic

通过不可信来源的输入构建动态 SubSonic 指令，攻击者就能够修改指令的含义或者执行任意 SQL 命令。

与 SubSonic 相关的 SQL injection 错误在以下情况下出现：

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

2. 数据用于动态地构造一个查询。
示例 1：以下代码动态地构造并执行了一个 SubSonic 查询，该查询可以搜索与指定名称相匹配的项。该查询仅会显示条目 owner 与被授予权限的当前用户一致的条目。

...
string userName = ctx.getAuthenticatedUserName();
string query = "SELECT * FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ ItemName.Text + "'";

IDataReader responseReader = new InlineQuery().ExecuteReader(query);
...

查询计划执行以下代码：

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

但是，由于这个查询是动态构造的，由一个不变的基查询字符串和一个用户输入字符串连接而成，因此只有在 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';

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

— 把没有被黑名单引用的值作为目标
- 寻找方法以绕过某些需要转义的元字符
- 使用存储过程隐藏注入的元字符

手动去除 SubSonic SQL 查询中的元字符有一定的帮助，但是并不能完全保护您的应用程序免受 SubSonic SQL injection 攻击。

防范 SubSonic Injection 攻击的另外一种常用方式是使用存储过程。虽然存储过程可以阻止某些类型的 SubSonic injection 攻击，但是对于绝大多数攻击仍无能为力。存储过程有助于避免 SubSonic SQL injection 的常用方式是限制可作为参数传入的指令类型。但是，有许多方法都可以绕过这一限制，许多危险的表达式仍可以传入存储过程。所以再次强调，存储过程可以避免部分情况，但是并不能完全保护您的应用系统抵御 SubSonic injection 的攻击。