How To: ASP.NET で SQL インジェクションから保護する方法

適用対象

• ASP.NET version 1.1
• ASP.NET version 2.0

概要

目次

このガイドの目的

• SQL インジェクション攻撃がどのように作動するかを学習する。
• 入力を制約して、SQL インジェクションを防止する。
• タイプが異なっても支障のない SQL コマンド パラメータを使用して、SQL インジェクションを防止する。
• リスクをさらに削減するためのその他の対抗手段を学習する。

はじめに

• 入力検証の不徹底。
• タイプが異なっても支障のないパラメータを使用しない SQL ステートメントのダイナミック構成。
• 特権を超えるデータベース ログインの使用。

SQL インジェクションの例

' ; DROP DATABASE pubs  --

// ダイナミック SQL を使用する場合。
SqlDataAdapter myCommand = new SqlDataAdapter(
"SELECT au_lname, au_fname FROM authors WHERE au_id = '" +
SSN.Text + "'", myConnection);

// ストアド プロシージャを使用する場合。
SqlDataAdapter myCommand = new SqlDataAdapter(
		"LoginStoredProcedure '" +
		 SSN.Text + "'", myConnection);

SELECT au_lname, au_fname FROM authors WHERE au_id = '172-32-9999'

SELECT au_lname, au_fname FROM authors WHERE au_id = ''; DROP DATABASE pubs --'

SELECT au_lname, au_fname FROM authors WHERE au_id = ''

; DROP DATABASE pubs

注意   複数の SQL ステートメントを区切るのに、セミコロンは必ずしも必要ありません。 必要かどうかは、ベンダまたはインプリメンテーションによって異なりますが、Microsoft SQL server では不要です。 たとえば、以下は SQL Server では 2 つの別々のステートメントとして解析されます。

SELECT * FROM MyTable DELETE FROM MyTable

--'

ガイドライン

• 入力データを制約して清浄化します。 タイプ、長さ、フォーマット、および範囲を検証して、既知の正常なデータかどうかをチェックします。
• タイプが異なっても支障のない SQL パラメータをデータ アクセスで使用します。 そのようなパラメータは、ストアド プロシージャまたは動的に作成される SQL コマンド文字列で使用することができます。 SqlParameterCollection などのパラメータ コレクションでは、タイプ チェックと長さの検証を行うことができます。 パラメータ コレクションを使用すると、入力はリテラル値として扱われ、SQL Server で実行可能コードとして扱われなくなります。 パラメータ コレクションを使用する別の利点として、タイプと長さのチェックを実施することができます。 値が範囲外であると、例外が起動されます。 これは、防御の増強を示す好例です。
• データベース内で制限された許可をもつアカウントを使用します。 理想的には、データベース内の選択したストアド プロシージャに対する実行許可だけを認可し、テーブルへの直接アクセス権は与えないでください。
• データベース エラー情報を公開しないようにします。 データベース エラーが起きた場合、詳細なエラー メッセージをユーザーに開示しないように努めます。

注意   SSL (Secure Sockets Layer) や IPSec (IP Security) などを使用する従来型のセキュリティ対策では、 SQL インジェクション攻撃からアプリケーションを保護することはできません。

ステップの概要

• ステップ 1 - 入力の制約。
• ステップ 2 - ストアド プロシージャでのパラメータの使用。
• ステップ 3 - ダイナミック SQL でのパラメータの使用。

ステップ 1 - 入力の制約

ASP.NET Web ページでの入力の制約

<%@ language="C#" %>
<form id="form1" runat="server">
<asp:TextBox ID="SSN" runat="server"/>
<asp:RegularExpressionValidator ID="regexpSSN" runat="server"
			ErrorMessage="Incorrect SSN Number"
			ControlToValidate="SSN"
			ValidationExpression="^\d{3}-\d{2}-\d{4}$" />
</form>

if (Regex.IsMatch(Request.Cookies["SSN"], "^\d{3}-\d{2}-\d{4}$"))
{
// データベースにアクセスします。
}
else
{
// 有害な入力を処理します。
}

データ アクセス コード内の入力の制約

• 信頼されていないクライアント。 信頼されないソースからのデータの取り込みが許可されている場合や、データがどの程度徹底的に検証および制約されたかが判然としない場合、データ アクセス ルーチンへの入力を制約する検証ロジックを追加します。
• ライブラリ コード。 複数のアプリケーションで使用するように設計されたライブラリとしてデータ アクセス コードがパッケージ化されている場合、データ アクセス コードは独自の検証を行う必要があります。クライアント アプリケーションに関して、安全であるという想定を行えないからです。

using System;
using System.Text.RegularExpressions;

public void CreateNewUserAccount(string name, string password)
{
// 小文字または大文字、アポストロフィ、ピリオド、または空白
// のみが名前で使用されているかどうかをチェックします。また、
// 1 ～ 40 文字の長さであるかどうかもチェックします。
if ( !Regex.IsMatch(userIDTxt.Text, @"^[a-zA-Z'./s]{1,40}$"))
throw new FormatException("Invalid name format");

// パスワードは、少なくとも 1 つの数字、1 つの小文字、
// 1 つの大文字から成り、8 ～ 10 文字の長さであるか
// どうかをチェックします。
if ( !Regex.IsMatch(passwordTxt.Text,
@"^(?=.*\d)(?=.*[a-z])(?=.*[A-Z]).{8,10}$" ))
throw new FormatException("Invalid password format");

// データ アクセス ロジックを実行します (タイプが異なっても支障のないパラメータを使用して)
...
}

ステップ 2 - ストアド プロシージャでのパラメータの使用

using System.Data;
using System.Data.SqlClient;

using (SqlConnection connection = new SqlConnection(connectionString))
{
DataSet userDataset = new DataSet();
SqlDataAdapter myCommand = new SqlDataAdapter(
"LoginStoredProcedure", connection);
myCommand.SelectCommand.CommandType = CommandType.StoredProcedure;
myCommand.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11);
myCommand.SelectCommand.Parameters["@au_id"].Value = SSN.Text;

myCommand.Fill(userDataset);
}

パラメータ化したストアド プロシージャをアプリケーションが使用する方法の確認

CREATE PROCEDURE dbo.RunQuery
@var ntext
AS
exec sp_executesql @var
GO

• ストアド プロシージャは、ステートメントに引き渡されたものをすべて実行します。 @var 変数を以下のものに設定することを検討してください。

  DROP TABLE ORDERS;
  

  この場合、ORDERS テーブルが除去されます。

• ストアド プロシージャは、dbo 特権で稼働します。
• ストアド プロシージャ用に選択した名前 (RunQuery) は不適切です。 攻撃者がデータベースを綿密に調べれば、ストアド プロシージャの名前が判明してしまいます。 RunQuery といった名前を付けると、そのストアド プロシージャは、指示されたクエリを実行するに違いないと見当をつけられます。

ステップ 3 - ダイナミック SQL でのパラメータの使用

using System.Data;
using System.Data.SqlClient;

using (SqlConnection connection = new SqlConnection(connectionString))
{
DataSet userDataset = new DataSet();
SqlDataAdapter myDataAdapter = new SqlDataAdapter(
"SELECT au_lname, au_fname FROM Authors WHERE au_id = @au_id",
connection);
myCommand.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11);
myCommand.SelectCommand.Parameters["@au_id"].Value = SSN.Text;
myDataAdapter.Fill(userDataset);
}

パラメータ バッチの使用

using System.Data;
using System.Data.SqlClient;
. . .
using (SqlConnection connection = new SqlConnection(connectionString))
{
SqlDataAdapter dataAdapter = new SqlDataAdapter(
"SELECT CustomerID INTO #Temp1 FROM Customers " +
"WHERE CustomerID > @custIDParm; SELECT CompanyName FROM Customers " +
"WHERE Country = @countryParm and CustomerID IN " +
"(SELECT CustomerID FROM #Temp1);",
connection);
SqlParameter custIDParm = dataAdapter.SelectCommand.Parameters.Add(
				  "@custIDParm", SqlDbType.NChar, 5);
custIDParm.Value = customerID.Text;

SqlParameter countryParm = dataAdapter.SelectCommand.Parameters.Add(
			  "@countryParm", SqlDbType.NVarChar, 15);
countryParm.Value = country.Text;

connection.Open();
DataSet dataSet = new DataSet();
dataAdapter.Fill(dataSet);
}
. . .

その他の考慮事項

• 最小特権をもったデータベース アカウントを使用します。
• エラー情報を公開しないようにします。

最小特権をもったデータベース アカウントの使用

1. Web サーバーのネットワーク サービス アカウント用の SQL Server ログインを作成します。 ネットワーク サービス アカウントは、DOMAIN\WEBSERVERNAME$ という ID でデータベース サーバーに提示されるネットワーク資格情報をもっています。 たとえば、ドメインが XYZ という名前で、Web サーバーが 123 という名前であれば、XYZ\123$ 用のデータベース ログインを作成します。
2. データベース ユーザーを作成し、そのユーザーをデータベース ロールに追加して、該当するデータベースへの新規のログイン アクセス権を認可します。
3. そのデータベース ロールから該当するストアド プロシージャを呼び出したり、データベース内の該当するテーブルにアクセスしたりできるようにするための許可を確立します。 アプリケーションが使用する必要のあるストアド プロシージャへのアクセス権だけを認可し、アプリケーションの最低限の要件をベースにして、それに見合ったテーブルへのアクセス権だけを認可します。

   たとえば、データベースの検索だけを実行し、データの更新はまったく行わない ASP.NET アプリケーションに対しては、テーブルへの読み取りアクセス権しか認可する必要はありません。 それによって、攻撃者が SQL インジェクション攻撃に成功しても、その攻撃者が与える可能性のある被害は限られます。

エラー情報の公開の差し控え

ご意見、ご提案

• Wiki: Security Guidance Feedback ページ: http://channel9.msdn.com/wiki/default.aspx/Channel9.SecurityGuidanceFeedback (英語)
• メール: secguide@microsoft.com (英語) までメールをお寄せください。

• 推奨事項に関する技術的な問題
• 実用性および利便性に関する問題

テクニカル サポート

コミュニティおよびニュースグループ

• MSDN ニュースグループ: http://www.microsoft.com/japan/msdn/newsgroups/
• ASP.NET Forums: http://forums.asp.net/ (英語)

ご協力いただいた方々

• ご協力いただいた社外の方々: Andy Eunson; Chris Ullman, Content Master; David Raphael, Rudolph Araujo, Foundstone Professional Services; Manoranjan M. Paul
• MCS (Microsoft Consulting Services) および PSS 関係者: Wade Mascia, Tom Christian, Adam Semel, Nobuyuki Akama, Microsoft Corporation
• MPD (Microsoft Product Group) 関係者: Stefan Schackow, Vikas Malhotra, Microsoft Corporation
• MSDN 関係者: Kent Sharkey, Microsoft Corporation
• Microsoft IT 関係者: Eric Rachner, Shawn Veney (ACE Team), Microsoft Corporation
• テスト チーム: Larry Brader, Microsoft Corporation; Nadupalli Venkata Surya Sateesh, Sivanthapatham Shanmugasundaram, Sameer Tarey, Infosys Technologies Ltd
• 編集チーム: Nelly Delgado, Microsoft Corporation; Sharon Smith, Tina Burden McGrayne, Linda Werner & Associates Inc
• リリース管理: Sanjeev Garg, Microsoft Corporation