SQL Injection: LINQ

動的な LINQ ステートメントの構築に信頼されていないソースから受信した入力を使用すると、攻撃者によるステートメントの改変や任意の SQL コマンドの実行が可能になることがあります。

LINQ に関連した挿入エラーが発生するのは、次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。

2. データがクエリの動的な構築に使用された場合。
例 1: 次のコードは、指定された名前に一致するアイテムを検索する LINQ クエリを動的に構築し、実行します。このクエリでは、認証済みユーザーのユーザー名と owner が一致するアイテムだけが表示されます。

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

var items = dataContext.ExecuteCommand<Item>(query);
...

このコードによって実行されるクエリは次のようになります。

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

ただし、クエリは定数ベースのクエリ文字列とユーザー入力の文字列を連結して動的に構築されるため、itemName に単一引用符が含まれない場合のみクエリは正しく動作します。ユーザー名 wiley を持つ攻撃者が文字列「name' OR 'a'='a」を itemName に入力すると、クエリは次のようになります。

	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 を持つ攻撃者が文字列「name'); DELETE FROM items; --」を itemName に入力すると、クエリは次の 2 つのクエリになります。

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

	DELETE FROM items;

	--'

Microsoft(R) SQL Server 2000 などの多くのデータベースサーバーでは、セミコロンで区切って入力した複数の SQL ステートメントをまとめて実行することができます。このような悪意のある文字列は、セミコロンで区切った複数ステートメントのバッチ処理を許可しない Oracle などのデータベースサーバーではエラーになりますが、バッチ処理を許容するデータベースの場合、攻撃者はデータベースに対して任意のコマンドを実行できます。

末尾の 2 つのハイフン (--) に注意してください。多くのデータベースサーバーでは、これ以降のステートメントはコメントとなり、実行されません [4]。この例では、変更されたクエリの末尾に残っている単一引用符が、コメント文字により削除されます。コメントをこのように使用することが許されていないデータベースでも、Example 1 と同様の技法を使用すると一般的な攻撃を有効にできます。攻撃者が文字列「name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a」を入力すると、次の 3 つの有効なステートメントが作成されます。

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

	DELETE FROM items;

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

LINQ Injection の攻撃を阻止する従来からの手段に、これらを入力検証の問題として扱う方法があります。安全な値からなる許可リスト内の文字だけを受け入れるか、悪意のあることが疑われる値をリストで識別して回避する (拒否リスト) かのどちらかを行います。許可リストをチェックする方法は、入力検証ルールの厳密な適用に非常に効果的ですが、パラメーター化された LINQ ステートメントを使用する方がメンテナンスしやすく、セキュリティ上の安全性も高まります。ほとんどの場合と同様、拒否リストを実装する方法には LINQ Injection の攻撃に対する防御を無効にできる抜け穴が多く存在します。たとえば、攻撃者は次のことを実行できます。

- 引用符で囲まれていないフィールドをターゲットとする。
- 特定のメタ文字をエスケープする必要性を回避する方法を見つけ出す。
- ストアドプロシージャを使用して、挿入されたメタ文字を隠す。

LINQ クエリへの入力文字を手動でエスケープすることは便利ですが、アプリケーションを LINQ Injection 攻撃の危険にさらすことになります。

その他、LINQ Injection の攻撃への一般的な対処として、ストアドプロシージャを使用する方法があります。ストアドプロシージャは特定のタイプの LINQ Injection 攻撃を阻止するためには有効ですが、他の多くの攻撃に対しては無力です。ストアドプロシージャは通常、パラメーターに渡されるステートメントのタイプを制限することで LINQ Injection の阻止を助けます。ただし、この制限を回避する方法は多数あり、問題になりそうな多くのステートメントをストアドプロシージャに渡すことができます。ストアドプロシージャは悪用の一部を阻止することができますが、アプリケーションが LINQ Injection 攻撃に対して安全になるわけではありません。