SQL Injection: Castle ActiveRecord

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

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

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

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

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

SimpleQuery<Item> queryObject = new SimpleQuery(queryString);
Item[] items = (Item[])queryObject.Execute(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 表中的所有条目，而不论其指定所有者是谁。

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

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

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

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