SQL インジェクション

[アーティクル]
05/08/2024

適用対象: SQL Server Azure SQL データベース Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System (PDW)

SQL インジェクションとは、悪意のあるコードを挿入し、後で SQL Server のデータベースエンジンのインスタンスに渡すことで解析と実行を行う攻撃です。データベースエンジンは、構文的に有効であれば受信したクエリをすべて実行するため、SQL ステートメントを構築するすべてのプロシージャにおいて、インジェクションの脆弱性を検証する必要があります。高いスキルを持った攻撃者は、その気になればパラメーター化されたデータでさえも操作できます。

SQL インジェクションのしくみ

SQL インジェクションは主に、SQL コマンドと連結されて実行されるユーザー入力変数にコードを直接挿入することにより行われます。それほど直接的ではない攻撃では、悪意のあるコードが、テーブル内の記憶領域に格納される文字列に挿入されたり、メタデータとして挿入されたりします。格納された文字列が後で動的な SQL コマンドに連結された場合、悪意のあるコードが実行されます。

インジェクションプロセスは、途中でテキスト文字列を終了し、新しいコマンドを追加することによって行われます。挿入されたコマンドが実行される前に余分な文字列が追加されている可能性があるため、犯罪者は挿入される文字列をコメントマーク -- で終了させます。後続のテキストは実行時には無視されます。

次のスクリプトは、単純な SQL インジェクションを示しています。ハードコードされた文字列とユーザー入力の文字列を連結することによって、SQL クエリが作成されます。

var ShipCity;
ShipCity = Request.form ("ShipCity");
var sql = "select * from OrdersTable where ShipCity = '" + ShipCity + "'";

ユーザーは、都市の名前を入力するように要求されます。ユーザーが「Redmond」と入力した場合、スクリプトによって構築されたクエリの例は次のようになります:

SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';

ただし、ユーザーが次のテキストを入力するとします:

Redmond';drop table OrdersTable--

この場合、スクリプトは次のようなクエリを構築します:

SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';drop table OrdersTable--'

セミコロン (;) は、前のクエリの終了と次のクエリの開始の区切りを示します。ダブルハイフン (--) は、現在行の残りの部分はコメントであるため無視されることを意味します。変更されたコードが構文的に正しい場合、このコードはサーバーによって実行されます。データベースエンジンがこのステートメントを処理する場合、ShipCity が Redmond である OrdersTable にあるレコードをすべて選択します。次に、データベースエンジンが OrdersTable をドロップします。

挿入された SQL コードが構文的に正しい限り、改ざんをプログラムによって検出するのは不可能です。そのため、すべてのユーザー入力を検証し、使用サーバーで作成された SQL コマンドを実行するコードを注意深くレビューする必要があります。この記事の次のセクションでは、コーディングのベストプラクティスについて説明します。

すべての入力を検証する

型、長さ、形式、および範囲をテストすることによってユーザー入力を必ず検証してください。悪意のある入力に対する予防措置を実装するには、アプリケーションのアーキテクチャおよび配置シナリオについて検討する必要があります。セキュリティで保護された環境で実行するようにデザインされたプログラムでも、セキュリティで保護されていない環境にコピーされる可能性があることに注意してください。次の提案をベストプラクティスとして検討してください。

アプリケーションによって受信されるデータのサイズ、型、内容を推測で処理しない。たとえば、次のような評価を行う必要があります。
- 郵便番号の入力がアプリケーションから期待されている場所に対して、ユーザーの誤りあるいは悪意のあるユーザーによって 2-GB のビデオファイルが入力された場合、アプリケーションはどのような動作をするか。
- DROP TABLE ステートメントがテキストフィールドに埋め込まれている場合、アプリケーションはどのような動作をするか。
入力のサイズとデータ型をテストし、適切な制限を適用します。これは、意図的なバッファーオーバーランを防ぐのに役立ちます。
文字列変数の内容をテストし、予測される値のみを受け入れる。バイナリデータ、エスケープシーケンス、およびコメント文字を含む入力は拒否します。これは、スクリプトインジェクションを防ぐのに役立ち、バッファーオーバーランをねらった攻撃に対する防御にもなります。
XML ドキュメントを扱う場合、入力時にすべてのデータをスキーマに照らして検証します。
Transact-SQL ステートメントをユーザー入力から直接構築しないこと。
ストアドプロシージャを使用して、ユーザー入力を検証する。
多層環境では、信頼関係ゾーンへ入る前にすべてのデータを検証する必要がある。検証プロセスをパスしないデータは拒否し、直前の層にエラーを返す必要があります。
複数層の検証を実装する。軽い悪意を持つユーザーに対する予防策は、決然たる攻撃者に対しては有効ではありません。より適切な実践方法は、ユーザーインターフェイスを介した入力時に検証を行い、その後の信頼境界を越えるすべてのポイントでも検証を行うことです。

たとえば、クライアント側アプリケーションでのデータ検証によって、単純なスクリプトインジェクションを防ぐことができます。ただし、次の層で、この入力が既に検証済みであると推測されると、クライアントを迂回する能力を持つ悪意のあるユーザーは、システムへ無制限にアクセスできることになります。
検証されていないユーザー入力は決して連結しないでください。文字列の連結は、スクリプトインジェクションの最初の段階です。
ファイル名の作成に使用できるフィールドでは、次の文字列を受け付けないでください: AUX、CLOCK$、COM1 から COM8、CON、CONFIG$、LPT1 から LPT8、NUL および PRN。

可能であれば、次の文字を含む入力は受け入れないでください。

入力文字	Transact-SQL での意味
`;`	クエリの区切り記号。
`'`	文字データ文字列の区切り記号。
`--`	単一行コメントの区切り記号。 `--` 以降、その行の末尾までのテキストは、サーバーによって評価されません。
`/* ... */`	コメントの区切り記号。 `/` と `/` の間にあるテキストについては、サーバーによる評価は行われません。
`xp_`	`xp_cmdshell`など、カタログ拡張ストアドプロシージャ名の先頭に使用します。

タイプセーフ SQL パラメーターを使用する

データベースエンジンの Parameters コレクションは、型チェックおよび長さの検証に使用できます。 Parameters コレクションを使用する場合、入力は実行可能コードとしてではなくリテラル値として扱われます。 Parameters コレクションを使用することの他の利点は、型チェックおよび長さのチェックを適用できることです。範囲外の値により、例外がトリガーされます。次のコードフラグメントは、Parameters コレクションの使用方法を示しています:

SqlDataAdapter myCommand = new SqlDataAdapter("AuthorLogin", conn);
myCommand.SelectCommand.CommandType = CommandType.StoredProcedure;
SqlParameter parm = myCommand.SelectCommand.Parameters.Add("@au_id",
    SqlDbType.VarChar, 11);
parm.Value = Login.Text;

この例では、 @au_id パラメーターは実行可能コードとしてではなくリテラル値として扱われます。この値は型および長さについてチェックされます。 @au_id の値が指定された型および長さの制約に従っていない場合は、例外がスローされます。

ストアドプロシージャとパラメーター化された入力を使用する

ストアドプロシージャがフィルターされていない入力を使用する場合、このストアドプロシージャは SQL インジェクションの影響を受けやすくなります。たとえば、次のコードには脆弱性があります。

SqlDataAdapter myCommand =
    new SqlDataAdapter("LoginStoredProcedure '" + Login.Text + "'", conn);

ストアドプロシージャを使用する場合、パラメーターをストアドプロシージャの入力として使用する必要があります。

動的な SQL を使用した Parameters コレクションを使用する

ストアドプロシージャを使用できない場合でも、次のコード例に示すようにパラメーターを使用することができます。

SqlDataAdapter myCommand = new SqlDataAdapter(
    "SELECT au_lname, au_fname FROM Authors WHERE au_id = @au_id", conn);
SqlParameter parm = myCommand.SelectCommand.Parameters.Add("@au_id",
    SqlDbType.VarChar, 11);
parm.Value = Login.Text;

入力をフィルターする

入力をフィルターすると、エスケープ文字が削除されることで SQL インジェクションの防御に役立ちます。ただし、問題となり得る文字は数が多いため、フィルタリングは信頼性の高い防御策にはなりません。次の例では、文字の文字列区切り記号を検索しています。

private string SafeSqlLiteral(string inputSQL)
{
    return inputSQL.Replace("'", "''");
}

LIKE 句

LIKE 句を使用する場合、ワイルドカード文字もエスケープする必要があることに注意してください:

s = s.Replace("[", "[[]");
s = s.Replace("%", "[%]");
s = s.Replace("_", "[_]");

SQL インジェクションのコードを確認する

EXECUTE、 EXEC、または sp_executesqlを呼び出すすべてのコードを確認する必要があります。次のようなクエリを使用すると、これらのステートメントを含むプロシージャの識別に役立てることができます。このクエリは、 EXECUTE または EXECという語の後に 1 ～ 4 個のスペースがあるかどうかをチェックします。

SELECT object_Name(id)
FROM syscomments
WHERE UPPER(TEXT) LIKE '%EXECUTE (%'
    OR UPPER(TEXT) LIKE '%EXECUTE  (%'
    OR UPPER(TEXT) LIKE '%EXECUTE   (%'
    OR UPPER(TEXT) LIKE '%EXECUTE    (%'
    OR UPPER(TEXT) LIKE '%EXEC (%'
    OR UPPER(TEXT) LIKE '%EXEC  (%'
    OR UPPER(TEXT) LIKE '%EXEC   (%'
    OR UPPER(TEXT) LIKE '%EXEC    (%'
    OR UPPER(TEXT) LIKE '%SP_EXECUTESQL%';

QUOTENAME() および REPLACE() でのパラメーターをラップする

選択された各ストアドプロシージャで、動的な Transact-SQL で使用されるすべての変数が正しく処理されることを確認します。ストアドプロシージャの入力パラメーターから取得するデータ、またはテーブルから読み取るデータは、QUOTENAME() または REPLACE() でラップする必要があります。 QUOTENAME() に渡される @variable の値のデータ型は sysname であり、文字列の最大長は 128 文字であることに注意してください。

@variable	推奨ラッパー
セキュリティ保護可能なリソースの名前	`QUOTENAME(@variable)`
<= 128 文字の文字列	`QUOTENAME(@variable, '''')`
> 128 文字の文字列	`REPLACE(@variable,'''', '''''')`

この方法を使用すると、SET ステートメントを次のように変更できます:

-- Before:
SET @temp = N'SELECT * FROM authors WHERE au_lname ='''
    + @au_lname + N'''';

-- After:
SET @temp = N'SELECT * FROM authors WHERE au_lname = '''
    + REPLACE(@au_lname, '''', '''''') + N'''';

データの切り捨てによって有効になるインジェクション

変数に代入されるすべての動的な Transact-SQL は、その変数に割り当てられているバッファーよりも大きい場合は切り捨てられます。予期しない長さの文字列をストアドプロシージャに渡すことで、強制的にステートメントの切り捨てを行うことができれば、攻撃者が結果を操作することも可能になります。たとえば、次の例のストアドプロシージャは、切り捨てによって有効になるインジェクションの影響を受けやすくなります。

この例では、最大長が 200 文字の @command バッファーがあります。 'sa'のパスワードを設定するには、合計 154 文字が必要です。UPDATE ステートメントの場合は 26 文字、WHERE 句の場合は 16 文字、'sa' の場合は 4 文字、QUOTENAME(@loginname) で囲われた引用符の場合は 2 文字となります: 200 - 26 - 16 - 4 - 2 = 154。ただし、@new が sysname として表されているため、この変数は 128 文字しか保持できません。私たちは、@new でいくつかの単一引用符を渡すことによってこれを克服することができます。

CREATE PROCEDURE sp_MySetPassword
    @loginname SYSNAME,
    @old SYSNAME,
    @new SYSNAME
AS
-- Declare variable.
DECLARE @command VARCHAR(200)

-- Construct the dynamic Transact-SQL.
SET @command = 'UPDATE Users SET password=' + QUOTENAME(@new, '''')
    + ' WHERE username=' + QUOTENAME(@loginname, '''') 
    + ' AND password=' + QUOTENAME(@old, '''')

-- Execute the command.
EXEC (@command);
GO

攻撃者は 128 文字バッファーに 154 文字を渡す場合、古いパスワードがわからなくても、sa の新しいパスワードを設定できます。

EXEC sp_MySetPassword 'sa',
    'dummy',
    '123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012'''''''''''''''''''''''''''''''''''''''''''''''''''

このため、コマンド変数には大きなバッファーを使用するか、動的 Transact-SQL を直接 EXECUTE ステートメント内で実行する必要があります。

QUOTENAME(@variable, '''') および REPLACE() 使用時の切り捨て

QUOTENAME() および REPLACE() から返される文字列は、割り当てられている領域よりも大きくなると、暗黙に切り捨てられます。次の例で作成されるストアドプロシージャは、行われる可能性がある処理を示しています。

この例では、@login、@oldpassword、および @newpassword のバッファーサイズが 128 文字のみでも、QUOTENAME() は最大 258 文字を返すことができるため、一時変数に格納されているデータは切り捨てられます。 @new に 128 文字が含まれている場合は、その結果 @newpassword は 123... n となる可能性があり、n は127 番目の文字となります。 QUOTENAME() によって返される文字列は切り捨てられるため、次のステートメントのようになります:

UPDATE Users SET password ='1234...[127] WHERE username=' -- other stuff here

CREATE PROCEDURE sp_MySetPassword
    @loginname SYSNAME,
    @old SYSNAME,
    @new SYSNAME
AS
-- Declare variables.
DECLARE @login SYSNAME;
DECLARE @newpassword SYSNAME;
DECLARE @oldpassword SYSNAME;
DECLARE @command VARCHAR(2000);

SET @login = QUOTENAME(@loginname, '''');
SET @oldpassword = QUOTENAME(@old, '''');
SET @newpassword = QUOTENAME(@new, '''');

-- Construct the dynamic Transact-SQL.
SET @command = 'UPDATE Users set password = ' + @newpassword
    + ' WHERE username = ' + @login
    + ' AND password = ' + @oldpassword;

-- Execute the command.
EXEC (@command);
GO

このため、次のステートメントでは、すべてのユーザーのパスワードを前のコードで渡された値に設定します。

EXEC sp_MyProc '--', 'dummy', '12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678'

REPLACE() を使用すると、割り当てられたバッファー領域よりも大きくすることで強制的に文字列の切り捨てを行うことができます。次の例で作成されるストアドプロシージャは、行われる可能性がある処理を示しています。

この例では、@login、@oldpassword、および @newpassword に割り当てられたバッファーが 128 文字しか保持できないため、データは切り捨てられますが、QUOTENAME() では最大 258 文字を返すことができます。 @new に 128 文字が含まれている場合は、@newpassword は '123...n' となる可能性があり、n は127 番目の文字となります。 QUOTENAME() によって返される文字列は切り捨てられるため、次のステートメントのようになります:

UPDATE Users SET password='1234...[127] WHERE username=' -- other stuff here

CREATE PROCEDURE sp_MySetPassword
    @loginname SYSNAME,
    @old SYSNAME,
    @new SYSNAME
AS
-- Declare variables.
DECLARE @login SYSNAME;
DECLARE @newpassword SYSNAME;
DECLARE @oldpassword SYSNAME;
DECLARE @command VARCHAR(2000);

SET @login = REPLACE(@loginname, '''', '''''');
SET @oldpassword = REPLACE(@old, '''', '''''');
SET @newpassword = REPLACE(@new, '''', '''''');

-- Construct the dynamic Transact-SQL.
SET @command = 'UPDATE Users SET password = '''
    + @newpassword + ''' WHERE username = '''
    + @login + ''' AND password = ''' + @oldpassword + '''';

-- Execute the command.
EXEC (@command);
GO

QUOTENAME() と同様に、すべての場合に対して十分な大きさである一時変数を宣言することで、REPLACE() による文字列の切り捨てを回避できます。可能であれば、動的 Transact-SQL 内で QUOTENAME() または REPLACE() を直接呼び出すことをお勧めします。あるいは、必要なバッファーサイズを次のように計算できます。 @outbuffer = QUOTENAME(@input)の場合、 @outbuffer のサイズは 2 * (len(@input) + 1)にする必要があります。前の例のように、 REPLACE() を使用し、二重引用符を繰り返すときは、バッファーサイズは 2 * len(@input) で十分です。

次の計算は、すべての場合に対応します。

WHILE LEN(@find_string) > 0, required buffer size =
    ROUND(LEN(@input) / LEN(@find_string), 0)
        * LEN(@new_string) + (LEN(@input) % LEN(@find_string))

QUOTENAME(@variable, ']') 使用時の切り捨て

データベースエンジンのセキュリティ保護可能なリソースの名前が、形式 QUOTENAME(@variable, ']') を使用するステートメントに渡されると、切り捨てが発生する可能性があります。このシナリオを以下の例で説明します。

この例では、@objectname は、2 * 258 + 1 文字を許可する必要があります。

CREATE PROCEDURE sp_MyProc
    @schemaname SYSNAME,
    @tablename SYSNAME
AS
-- Declare a variable as sysname. The variable will be 128 characters.
DECLARE @objectname SYSNAME;

SET @objectname = QUOTENAME(@schemaname) + '.' + QUOTENAME(@tablename);
    -- Do some operations.
GO

型 sysname の値を連結する場合、値ごとに最大 128 文字を十分保持できる大きさの一時変数を使用する必要があります。可能であれば、動的 Transact-SQL 内で QUOTENAME() を直接呼び出します。あるいは、前述のように必要なバッファーサイズを計算できます。

次の方法で共有

SQL インジェクション

SQL インジェクションのしくみ

すべての入力を検証する

タイプセーフ SQL パラメーターを使用する

ストアドプロシージャとパラメーター化された入力を使用する

動的な SQL を使用した Parameters コレクションを使用する

入力をフィルターする

LIKE 句

SQL インジェクションのコードを確認する

QUOTENAME() および REPLACE() でのパラメーターをラップする

データの切り捨てによって有効になるインジェクション

QUOTENAME(@variable, '''') および REPLACE() 使用時の切り捨て

QUOTENAME(@variable, ']') 使用時の切り捨て

フィードバック

その他のリソース

次の方法で共有

SQL インジェクション

SQL インジェクションのしくみ

すべての入力を検証する

タイプ セーフ SQL パラメーターを使用する

ストアド プロシージャとパラメーター化された入力を使用する

動的な SQL を使用した Parameters コレクションを使用する

入力をフィルターする

LIKE 句

SQL インジェクションのコードを確認する

QUOTENAME() および REPLACE() でのパラメーターをラップする

データの切り捨てによって有効になるインジェクション

QUOTENAME(@variable, '''') および REPLACE() 使用時の切り捨て

QUOTENAME(@variable, ']') 使用時の切り捨て

関連するコンテンツ

フィードバック

その他のリソース

タイプセーフ SQL パラメーターを使用する

ストアドプロシージャとパラメーター化された入力を使用する