SQL Injection: Castle ActiveRecord

Constructing a dynamic Castle ActiveRecord statement with input coming from an untrusted source might allow an attacker to modify the statement's meaning or to execute arbitrary SQL commands.

SQL injection errors related to Castle ActiveRecord occur when:

1. Data enters a program from an untrusted source.

2. The data is used to dynamically construct a query.
Example 1: The following code dynamically constructs and executes a Castle ActiveRecord query that searches for items matching a specified name. The query restricts the items displayed to those where owner matches the user name of the currently-authenticated user.

...
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);

...

The query intends to execute the following code:

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

However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string "name' OR 'a'='a" for itemName, then the query becomes the following:

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

The addition of the OR 'a'='a' condition causes the where clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:

	SELECT * FROM items;

This simplification of the query allows the attacker to bypass the requirement that the query must only return items owned by the authenticated user. The query now returns all entries stored in the items table, regardless of their specified owner.

One traditional approach to preventing Castle ActiveRecord injection attacks is to handle them as an input validation problem and either accept only characters from an allow list of safe values or identify and escape a list of potentially malicious values (deny list). Checking an allow list can be a very effective means of enforcing strict input validation rules, but parameterized Castle ActiveRecord statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, implementing a deny list is riddled with loopholes that make it ineffective at preventing Castle ActiveRecord SQL injection attacks. For example, attackers may:

- Target fields that are not quoted
- Find ways to bypass the need for certain escaped metacharacters
- Use stored procedures to hide the injected metacharacters

Manually escaping characters in input to Castle ActiveRecord queries can help, but it will not make your application secure from Castle ActiveRecord SQL injection attacks.

Another solution commonly proposed for dealing with Castle ActiveRecord injection attacks is to use stored procedures. Although stored procedures prevent some types of Castle ActiveRecord injection attacks, they fail to protect against many others. Stored procedures typically help prevent Castle ActiveRecord SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against Castle ActiveRecord injection attacks.