SQL Injection: NHibernate

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

次の場合に SQL Injection エラーが発生します。

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

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

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

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

	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';

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

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

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

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