界: Input Validation and Representation

入力の検証や表現の問題は、メタキャラクター、代替エンコーディング、数値表現などによって引き起こされます。セキュリティの問題は、入力を信頼することに起因します。この問題に含まれるのは、「Buffer Overflow」、「Cross-Site Scripting」攻撃、「SQL Injection」などです。

12 見つかった項目

脆弱性

SQL Injection

Abstract

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

Explanation

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

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

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


...
v_account = request->get_form_field( 'account' ).
v_reference = request->get_form_field( 'ref_key' ).

CONCATENATE `user = '` sy-uname `'` INTO cl_where.
IF v_account IS NOT INITIAL.
CONCATENATE cl_where ` AND account = ` v_account INTO cl_where SEPARATED BY SPACE.
ENDIF.
IF v_reference IS NOT INITIAL.
CONCATENATE cl_where "AND ref_key = `" v_reference "`" INTO cl_where.
ENDIF.

SELECT *
    FROM invoice_items
    INTO CORRESPONDING FIELDS OF TABLE itab_items
    WHERE (cl_where).
...

このコードによって実行されるクエリは次のようになります (v_account および v_reference が空白でない場合)。


        SELECT *
FROM invoice_items
INTO CORRESPONDING FIELDS OF TABLE itab_items
        WHERE user = sy-uname
        AND account = <account>
        AND ref_key = <reference>.

しかし、クエリは定数ベースのクエリ文字列とユーザー入力の文字列を連結して、動的に構築されるため、SQL Injection 攻撃の対象となります。攻撃者が v_reference に文字列「"abc` OR MANDT NE `+"」を入力し、v_account に文字列「1000」を入力すると、クエリは次のようになります。


                SELECT *
FROM invoice_items
INTO CORRESPONDING FIELDS OF TABLE itab_items
        WHERE user = sy-uname
        AND account = 1000
        AND ref_key = `abc` OR MANDT NE `+`.

OR MANDT NE `+` の条件を追加すると、クライアントフィールドがリテラル + と等しくなることはないため、WHERE 句は常に真 (true) の評価をします。そのため、このクエリは次のような単純なクエリと論理的に等しくなります。


        SELECT * FROM invoice_items
INTO CORRESPONDING FIELDS OF TABLE itab_items.

このクエリの単純化により攻撃者は、クエリが返すのは認証済みユーザーが所有するアイテムのみでなければならないという要件を回避できます。クエリは、特定のユーザーに関係なく、invoice_items テーブルに格納されているすべてのエントリを返すようになりました。

例 2: この例では、従業員が自分の住所を更新できるプログラムで ADBC API を使用することを検討します。


        PARAMETERS: p_street TYPE string,
                    p_city TYPE string.

		Data: v_sql TYPE string,
			  stmt TYPE REF TO CL_SQL_STATEMENT.

v_sql = "UPDATE EMP_TABLE SET ".

"Update employee address. Build the update statement with changed details
IF street NE p_street.
CONCATENATE v_sql "STREET = `" p_street "`".
ENDIF.
IF city NE p_city.
CONCATENATE v_sql "CITY = `" p_city "`".
ENDIF.

l_upd      = stmt->execute_update( v_sql ).

もしも不満を抱いている従業員がいてパラメーター p_street に対して「"ABC` SALARY = `1000000"」のような文字列を入力すると、アプリケーションではデータベースを変更された給与で更新できます。

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

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

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

References

[1] SAP OSS notes 1520356, 1487337, 1502272 and related notes.

[2] S. J. Friedl SQL Injection Attacks by Example

[3] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine

[4] P. Finnigan SQL Injection and Oracle, Part One Security Focus

[5] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press

desc.dataflow.abap.sql_injection

Abstract

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

Explanation

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

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

2. データが SQL クエリの動的な構築に使用された場合。

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


        ...
        var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
        var username:String = String(params["username"]);
        var itemName:String = String(params["itemName"]);
        var query:String = "SELECT * FROM items WHERE owner = " + username + " AND itemname = " + itemName;
          
        stmt.sqlConnection = conn;
        stmt.text = query;
        stmt.execute();
        ...

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


        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 攻撃に対して安全になるわけではありません。

References

[1] S. J. Friedl SQL Injection Attacks by Example

[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine

[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus

[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press

desc.dataflow.actionscript.sql_injection

Abstract

Explanation

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

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

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


...
string userName = ctx.getAuthenticatedUserName();
string query = "SELECT * FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ ItemName.Text + "'";
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
...

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


	SELECT * FROM items
	WHERE owner = <userName>
	AND itemname = <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;

	--'


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

	DELETE FROM items;

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

References

[1] S. J. Friedl SQL Injection Attacks by Example

[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine

[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus

[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press

desc.dataflow.dotnet.sql_injection

Abstract

Explanation

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

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

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


...
ctx.getAuthUserName(&userName); {
CString query = "SELECT * FROM items WHERE owner = '"
				 + userName + "' AND itemname = '"
				 + request.Lookup("item") + "'";
dbms.ExecuteSQL(query);
...

例 2:または、次のコードで SQLite を使用しても類似の結果を得ることができます。


...
sprintf (sql, "SELECT * FROM items WHERE owner='%s' AND itemname='%s'", username, request.Lookup("item"));
printf("SQL to execute is: \n\t\t %s\n", sql);
rc = sqlite3_exec(db,sql, NULL,0, &err);
...

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


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


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

OR 'a'='a' 条件を追加すると、where 句は常に真 (true) の評価をします。そのため、このクエリは次のような単純なクエリと論理的に等しくなります。


	SELECT * FROM items;

このクエリの単純化により攻撃者は、クエリが返すのは認証済みユーザーが所有するアイテムのみでなければならないという要件を回避できます。クエリは、特定の所有者に関係なく、items テーブルに格納されているすべてのエントリを返すようになりました。

例 3: この例では、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';

References

[1] S. J. Friedl SQL Injection Attacks by Example

[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine

[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus

[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press

[5] Parameterized CRecordset and CDatabase for SQL Server

[6] Parameterizing a Recordset Microsoft

[7] ODBC API Reference: SQLNumParams() Microsoft

[8] ODBC API Reference: SQLBindParameter() Microsoft

[9] OLE DB Reference: ICommandWithParameters Microsoft

desc.dataflow.cpp.sql_injection

Abstract

Explanation

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

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

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


...
ACCEPT USER.
ACCEPT ITM.
MOVE "SELECT * FROM items WHERE owner = '" TO QUERY1.
MOVE "' AND itemname = '" TO QUERY2.
MOVE "'" TO QUERY3.

STRING
  QUERY1, USER, QUERY2, ITM, QUERY3 DELIMITED BY SIZE
  INTO QUERY
END-STRING.
  
EXEC SQL
  EXECUTE IMMEDIATE :QUERY
END-EXEC.
...

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


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

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


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

OR 'a'='a' の条件を追加すると、where 句は常に真 (true) の評価をします。そのため、このクエリは次のような単純なクエリと論理的に等しくなります。


	SELECT * FROM items;


	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 攻撃に対して安全になるわけではありません。

References

[1] S. J. Friedl SQL Injection Attacks by Example

[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine

[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus

[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press

desc.dataflow.cobol.sql_injection

Abstract

Explanation

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

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

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


...
<cfquery name="matchingItems" datasource="cfsnippets">
    SELECT * FROM items 
     WHERE owner='#Form.userName#'   
       AND itemId=#Form.ID#
</cfquery>
...

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


	SELECT * FROM items
	WHERE owner = <userName>
	AND itemId = <ID>;

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


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

OR 'a'='a' 条件を追加すると、where 句は常に真 (true) の評価をします。そのため、このクエリは次のような単純なクエリと論理的に等しくなります。


	SELECT * FROM items;

このクエリの単純化により攻撃者は、クエリが返すのは認証済みユーザーが所有するアイテムのみでなければならないという要件を回避できます。クエリは、特定の所有者に関係なく、items テーブルに格納されているすべてのエントリを返すようになりました。

例 2: この例では、Example 1 で構築および実行されたクエリに悪意のある別の値が渡された場合の影響を検討します。ユーザー名 hacker を持つ攻撃者が文字列「hacker'); DELETE FROM items; --」を Form.ID に入力すると、クエリは次の 2 つのクエリになります。


	SELECT * FROM items 
	WHERE owner = 'hacker'
	AND itemId = 'name';

	DELETE FROM items;

	--'


	SELECT * FROM items 
	WHERE owner = 'hacker'
	AND itemId = 'name';

	DELETE FROM items;

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

References

[1] S. J. Friedl SQL Injection Attacks by Example

[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine

[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus

[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press

desc.dataflow.cfml.sql_injection

Abstract

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

Explanation

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

1.信頼できないソースからデータがプログラムに入力された場合。

2.データが SQL クエリの動的な構築に使用された場合。

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


...
	final server = await HttpServer.bind('localhost', 18081);
    server.listen((request) async {
        final headers = request.headers;
        final userName = headers.value('userName');
        final itemName = headers.value('itemName');
        final query = "SELECT * FROM items WHERE owner = '"
            + userName! + "' AND itemname = '"
            + itemName! + "'";
        db.query(query);
    }
	...

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


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


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


	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 攻撃に対して安全になるわけではありません。

desc.dataflow.dart.sql_injection

Abstract

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

Explanation

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

1.信頼できないソースからデータがプログラムに入力された場合。

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


  ...
  rawQuery := request.URL.Query()
  username := rawQuery.Get("userName")
  itemName := rawQuery.Get("itemName")
  query := "SELECT * FROM items WHERE owner = " + username + " AND itemname = " + itemName + ";"

  db.Exec(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';


	SELECT * FROM items;


	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 攻撃に対して安全とすることができるわけではありません。

References

[1] S. J. Friedl SQL Injection Attacks by Example

[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine

[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus

[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press

desc.dataflow.golang.sql_injection

Abstract

Explanation


...
	String userName = ctx.getAuthenticatedUserName();
	String itemName = request.getParameter("itemName");
	String query = "SELECT * FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ itemName + "'";
	ResultSet rs = stmt.execute(query);
...

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


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


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

OR 'a'='a' 条件を追加すると、where 句は常に真 (true) の評価をします。そのため、このクエリは次のような単純なクエリと論理的に等しくなります。


	SELECT * FROM items;


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

	DELETE FROM items;

	--'


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

	DELETE FROM items;

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

一部には、モバイルの世界では SQL Injection のような古典的な Web アプリケーションの脆弱性は意味がなく、自分に降りかかる攻撃をするはずがない、という見方があります。しかし忘れてはならないモバイルプラットフォームの基本は、さまざまなソースからアプリケーションをダウンロードして同じデバイス上で一緒に実行することです。このため、たとえばバンキングアプリケーションのすぐ隣でマルウェアの一部を実行する可能性が高くなり、モバイルアプリケーションの攻撃面を拡張し、プロセス間通信なども含める必要があります。

例 3: 次のコードでは、Android プラットフォームにExample 1 を応用しています。


...
        PasswordAuthentication pa = authenticator.getPasswordAuthentication();
        String userName = pa.getUserName();
        String itemName = this.getIntent().getExtras().getString("itemName");
        String query = "SELECT * FROM items WHERE owner = '"
                                + userName + "' AND itemname = '"
                                + itemName + "'";
        SQLiteDatabase db = this.openOrCreateDatabase("DB", MODE_PRIVATE, null);
        Cursor c = db.rawQuery(query, null);
...

References

[1] S. J. Friedl SQL Injection Attacks by Example

[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine

[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus

[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press

[5] IDS00-J. Prevent SQL Injection CERT

[6] INJECT-2: Avoid dynamic SQL Oracle

desc.dataflow.java.sql_injection

Abstract

Explanation


	...
	var username = document.form.username.value;
	var itemName = document.form.itemName.value;
	var query = "SELECT * FROM items WHERE owner = " + username + " AND itemname = " + itemName + ";";
	db.transaction(function (tx) {
		tx.executeSql(query);
		}
	)
	...

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


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


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


	SELECT * FROM items;


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

	DELETE FROM items;

	--'


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

	DELETE FROM items;

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

References

[1] S. J. Friedl SQL Injection Attacks by Example

[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine

[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus

[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press

desc.dataflow.javascript.sql_injection

Abstract

Explanation


	...
	$userName = $_SESSION['userName'];
	$itemName = $_POST['itemName'];
	$query = "SELECT * FROM items WHERE owner = '$userName' AND itemname = '$itemName';";
	$result = mysql_query($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;


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

	DELETE FROM items;

	--'


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

	DELETE FROM items;

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

References

[1] S. J. Friedl SQL Injection Attacks by Example

[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine

[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus

[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press

desc.dataflow.php.sql_injection

Abstract

Explanation

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

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

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


procedure get_item (
     itm_cv IN OUT ItmCurTyp,
     usr in varchar2,
     itm in varchar2)
is
     open itm_cv for ' SELECT * FROM items WHERE ' ||
                   'owner = '''|| usr || '''' ||
                   ' AND itemname = ''' || itm || '''';
     end get_item;

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


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


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


	SELECT * FROM items;


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

	DELETE FROM items;

	--'


	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 の攻撃に対して本質的に安全な状態にするわけではありません

References

[1] S. J. Friedl SQL Injection Attacks by Example

[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine

[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus

[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press

[5] David Litchfield Lateral SQL Injection: A New Class of Vulnerability in Oracle

desc.dataflow.sql.sql_injection

Abstract

Explanation


	...
	userName = req.field('userName')
	itemName = req.field('itemName')
	query = "SELECT * FROM items WHERE owner = ' " + userName +" ' AND itemname = ' " + itemName +"';"
	cursor.execute(query)
	result = cursor.fetchall()
	...

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


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


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

OR 'a'='a' 条件を追加すると、where 句は常に真 (true) の評価をします。そのため、このクエリは次のような単純なクエリと論理的に等しくなります。


	SELECT * FROM items;


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

	DELETE FROM items;

	--'


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

	DELETE FROM items;

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

References

[1] S. J. Friedl SQL Injection Attacks by Example

[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine

[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus

[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press

desc.dataflow.python.sql_injection

Abstract

Explanation

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

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

この場合、データのソースが信頼できると Fortify Static Code Analyzer は判断できません。

2. データが SQL クエリの動的な構築に使用された場合。

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


...
  userName = getAuthenticatedUserName()
  itemName = params[:itemName]
  sqlQuery = "SELECT * FROM items WHERE owner = '#{userName}' AND itemname = '#{itemName}'"
  rs = conn.query(sqlQuery)
...

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


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


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

OR 'a'='a' 条件を追加すると、where 句は常に真 (true) の評価をします。そのため、このクエリは次のような単純なクエリと論理的に等しくなります。


  SELECT * FROM items;

このクエリの単純化により攻撃者は、クエリが返すのは認証済みユーザーが所有するアイテムのみでなければならないという要件を回避できます。クエリは、特定の所有者に関係なく、items テーブルに格納されているすべてのエントリを返すようになりました。

Ruby は静的に型付けされていないため、静的型付け言語では使用できない SQL クエリへの他のインジェクションポイントも有効になります。
例 2: 次のコードは、指定された名前に一致するアイテムを検索する SQL クエリを動的に構築し、実行します。このクエリでは、認証済みユーザーのユーザー名と所有者が一致するアイテムだけが表示されます。


...
  id = params[:id]
  itemName = Mysql.escape_string(params[:itemName])
  sqlQuery = "SELECT * FROM items WHERE id = #{userName} AND itemname = '#{itemName}'"
  rs = conn.query(sqlQuery)
...

この場合、次の SQL クエリが実行されると想定されます。


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

今度は私たちが itemName 内に単一引用符を指定する攻撃者から保護され、SQL Injectionの脆弱性を回避したと見なされることがお分かりでしょう。ただし、Ruby は静的に型付けされた言語ではないため、id をある程度変化のある整数と想定していても、実際にはユーザー入力から割り当てられるため、数値であるとは限りません。攻撃者が id の値を 1 OR id!=1-- に変更した場合、id が実際に数値だというチェックがないため、SQL クエリは次のようになります。


SELECT * FROM items WHERE id=1 OR id!=1-- AND itemname = 'anyValue';

末尾の 2 つのハイフン (--) に注意してください。多くのデータベースサーバーでは、これ以降のステートメントはコメントとなり、実行されません [4]。このため、実行される SQL クエリは次の部分になります。


SELECT * FROM items WHERE id=1 OR id!=1;

今度は id の値が 1 かどうかに関係なくテーブルからすべてを選択しています。つまり、テーブル内のすべてと等しくなります。

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

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

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

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

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

References

[1] S. J. Friedl SQL Injection Attacks by Example

[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine

[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus

[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press

desc.dataflow.ruby.sql_injection

Abstract

Explanation

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

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

2. データが SQL クエリの動的な構築に使用された場合。

例 1: 次のコードは、指定された名前に一致するユーザーを検索する SQL クエリを動的に構築し、実行します。このクエリでは、パスパラメーターとして提供されるユーザー名と所有者が一致するアイテムだけが表示されます。


  def doSQLQuery(value:String) = Action.async { implicit request =>
    val result: Future[Seq[User]] = db.run {
      sql"select * from users where name = '#$value'".as[User]
    }
    ...
  }

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


	SELECT * FROM users 
	WHERE name = <userName>

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


	SELECT * FROM users 
    WHERE name = 'name' OR 'a'='a';


	SELECT * FROM users;

このようにクエリを単純化することにより、指定されたユーザーが所有するユーザーのみを返す必要があるというクエリ要件を攻撃者はすり抜けることができます。その結果、指定されたユーザーとは無関係に、クエリは users テーブルに格納されているエントリをすべて返します。

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

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

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

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

References

[1] S. J. Friedl SQL Injection Attacks by Example

[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine

[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus

[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press

[5] IDS00-J. Prevent SQL Injection CERT

[6] INJECT-2: Avoid dynamic SQL Oracle

desc.dataflow.scala.sql_injection

Abstract

Explanation

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

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

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


...
let queryStatementString = "SELECT * FROM items WHERE owner='\(username)' AND itemname='\(item)'"
var queryStatement: OpaquePointer? = nil
if sqlite3_prepare_v2(db, queryStatementString, -1, &queryStatement, nil) == SQLITE_OK {
    if sqlite3_step(queryStatement) == SQLITE_ROW {
    ...
    }
}
...

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


    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;


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

References

[1] S. J. Friedl SQL Injection Attacks by Example

[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine

[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus

[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press

[5] Parameterized CRecordset and CDatabase for SQL Server

[6] Parameterizing a Recordset Microsoft

[7] ODBC API Reference: SQLNumParams() Microsoft

[8] ODBC API Reference: SQLBindParameter() Microsoft

[9] OLE DB Reference: ICommandWithParameters Microsoft

desc.dataflow.swift.sql_injection

Abstract

Explanation


	...
	username = Session("username")
	itemName = Request.Form("itemName")
	strSQL = "SELECT * FROM items WHERE owner = '"& userName &"' AND itemname = '" & itemName &"'"
	objRecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
	...

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


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


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

OR 'a'='a' 条件を追加すると、where 句は常に真 (true) の評価をします。そのため、このクエリは次のような単純なクエリと論理的に等しくなります。


	SELECT * FROM items;


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

	DELETE FROM items;

	--'


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

	DELETE FROM items;

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

References

[1] S. J. Friedl SQL Injection Attacks by Example

[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine

[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus

[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press

desc.dataflow.vb.sql_injection

SQL Injection: Castle ActiveRecord

C#/VB.NET/ASP.NET

Abstract

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

Explanation

Castle ActiveRecord に関連した SQL Injection エラーが発生するのは、次の場合です。

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

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


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

...

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


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


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


	SELECT * FROM items;

このクエリの単純化により攻撃者は、クエリが返すのは認証済みユーザーが所有するアイテムのみでなければならないという要件を回避できます。クエリは、特定の所有者に関係なく、items テーブルに格納されているすべてのエントリを返すようになりました。

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

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

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

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

References

[1] S. J. Friedl SQL Injection Attacks by Example

[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine

[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus

[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press

[5] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5

[6] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete

[7] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5

[8] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1

[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity

[10] Standards Mapping - CIS Kubernetes Benchmark partial

[11] Standards Mapping - Common Weakness Enumeration CWE ID 89

[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [6] CWE ID 089

[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [6] CWE ID 089

[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [6] CWE ID 089

[15] Standards Mapping - Common Weakness Enumeration Top 25 2022 [3] CWE ID 089

[16] Standards Mapping - Common Weakness Enumeration Top 25 2023 [3] CWE ID 089

[17] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754

[18] Standards Mapping - FIPS200 SI

[19] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data

[20] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)

[21] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation

[22] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws

[23] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws

[24] Standards Mapping - OWASP Top 10 2010 A1 Injection

[25] Standards Mapping - OWASP Top 10 2013 A1 Injection

[26] Standards Mapping - OWASP Top 10 2017 A1 Injection

[27] Standards Mapping - OWASP Top 10 2021 A03 Injection

[28] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.4 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.5 Output Encoding and Injection Prevention Requirements (L1 L2 L3)

[29] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls

[30] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1

[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6

[32] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2

[33] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1

[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1

[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1

[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1

[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1

[38] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4

[39] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection

[40] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation

[41] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation

[42] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 089

[43] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 089

[44] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 089

[45] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[46] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[47] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[48] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[49] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[50] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[51] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[53] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[54] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[55] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[56] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[57] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[58] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[59] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[60] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[61] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[62] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[63] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[64] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[65] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[66] Standards Mapping - Web Application Security Consortium Version 2.00 SQL Injection (WASC-19)

[67] Standards Mapping - Web Application Security Consortium 24 + 2 SQL Injection

desc.dataflow.dotnet.sql_injection_castleActiveRecord

SQL Injection: Hibernate

Java/JSP

Abstract

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

Explanation

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

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

2. データが HQL クエリの動的な構築に使用された場合。

例 1: 次のコードは、指定された名前に一致するアイテムを検索する HQL クエリを動的に構築し、実行します。このクエリでは、認証済みユーザーのユーザー名と所有者が一致するアイテムだけが表示されます。


...
	String userName = ctx.getAuthenticatedUserName();
	String itemName = request.getParameter("itemName");
	String query = "FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ itemName + "'";
	List items = sess.createQuery(query).list();
	...

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


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


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

OR 'a'='a' 条件を追加すると、where 句は常に真 (true) の評価をします。そのため、このクエリは次のような単純なクエリと論理的に等しくなります。


	SELECT * FROM items;


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

	DELETE FROM items;

	--'


	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 攻撃に対して安全になるわけではありません。

References

[1] S. J. Friedl SQL Injection Attacks by Example

[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine

[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus

[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press

[5] Hibernate API Documentation

[6] IDS00-J. Prevent SQL Injection CERT

[7] INJECT-2: Avoid dynamic SQL Oracle

[8] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5

[9] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete

[10] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5

[11] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1

[12] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity

[13] Standards Mapping - CIS Kubernetes Benchmark partial

[14] Standards Mapping - Common Weakness Enumeration CWE ID 564

[15] Standards Mapping - Common Weakness Enumeration Top 25 2019 [6] CWE ID 089

[16] Standards Mapping - Common Weakness Enumeration Top 25 2020 [6] CWE ID 089

[17] Standards Mapping - Common Weakness Enumeration Top 25 2021 [6] CWE ID 089

[18] Standards Mapping - Common Weakness Enumeration Top 25 2022 [3] CWE ID 089

[19] Standards Mapping - Common Weakness Enumeration Top 25 2023 [3] CWE ID 089

[20] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754

[21] Standards Mapping - FIPS200 SI

[22] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data

[23] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)

[24] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation

[25] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws

[26] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws

[27] Standards Mapping - OWASP Top 10 2010 A1 Injection

[28] Standards Mapping - OWASP Top 10 2013 A1 Injection

[29] Standards Mapping - OWASP Top 10 2017 A1 Injection

[30] Standards Mapping - OWASP Top 10 2021 A03 Injection

[31] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.4 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.5 Output Encoding and Injection Prevention Requirements (L1 L2 L3)

[32] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls

[33] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1

[34] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6

[35] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2

[36] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1

[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1

[38] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1

[39] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1

[40] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1

[41] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4

[42] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection

[43] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation

[44] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation

[45] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116

[46] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[47] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[48] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[49] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[50] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[51] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[52] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[54] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[55] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[56] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[57] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[58] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[59] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[60] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[61] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[62] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[63] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[64] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[65] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[66] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[67] Standards Mapping - Web Application Security Consortium Version 2.00 SQL Injection (WASC-19)

[68] Standards Mapping - Web Application Security Consortium 24 + 2 SQL Injection

desc.dataflow.java.sql_injection_hibernate

SQL Injection: iBatis Data Map

Java/JSP

Abstract

Explanation

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

1.信頼できないソースからデータがプログラムに入力された場合。

2.データが SQL クエリの動的な構築に使用された場合。

iBatis Data Maps では、次のように、SQL ステートメントで動的パラメーターを指定でき、また通常は # 文字を使用して定義されます。


    <select id="getItems" parameterClass="MyClass" resultClass="items">
        SELECT * FROM items WHERE owner = #userName#
    </select>

変数名の前後の # 文字は、iBatis が userName 変数を使用してパラメーター化されたクエリを作成することを示します。ただし、iBatis では、$ 文字を使用して変数を SQL ステートメントに直接連結することもできるため、SQL Injection のチャンスが高まります。

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


    <select id="getItems" parameterClass="MyClass" resultClass="items">
        SELECT * FROM items WHERE owner = #userName# AND itemname = '$itemName$'
    </select>


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


	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 攻撃に対して安全になるわけではありません。

References

[1] iBatis Working with Data Maps

[2] iBatis Data Mapper Developer Guide

[3] S. J. Friedl SQL Injection Attacks by Example

[4] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine

[5] P. Finnigan SQL Injection and Oracle, Part One Security Focus

[6] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press

[7] IDS00-J. Prevent SQL Injection CERT

[8] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5

[9] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete

[10] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4

[11] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1

[12] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity

[13] Standards Mapping - CIS Kubernetes Benchmark partial

[14] Standards Mapping - Common Weakness Enumeration CWE ID 89

[15] Standards Mapping - Common Weakness Enumeration Top 25 2019 [6] CWE ID 089

[16] Standards Mapping - Common Weakness Enumeration Top 25 2020 [6] CWE ID 089

[17] Standards Mapping - Common Weakness Enumeration Top 25 2021 [6] CWE ID 089

[18] Standards Mapping - Common Weakness Enumeration Top 25 2022 [3] CWE ID 089

[19] Standards Mapping - Common Weakness Enumeration Top 25 2023 [3] CWE ID 089

[20] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754

[21] Standards Mapping - FIPS200 SI

[22] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data

[23] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)

[24] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation

[25] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws

[26] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws

[27] Standards Mapping - OWASP Top 10 2010 A1 Injection

[28] Standards Mapping - OWASP Top 10 2013 A1 Injection

[29] Standards Mapping - OWASP Top 10 2017 A1 Injection

[30] Standards Mapping - OWASP Top 10 2021 A03 Injection

[32] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls

[33] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6

[34] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2

[35] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1

[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1

[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1

[38] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1

[39] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1

[40] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4

[41] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection

[42] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation

[43] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation

[44] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 089

[45] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 089

[46] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 089

[47] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[48] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[49] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[50] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[51] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[52] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[53] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[55] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[56] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[57] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[58] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[59] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[60] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[61] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[62] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[63] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[64] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[65] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[66] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[67] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[68] Standards Mapping - Web Application Security Consortium Version 2.00 SQL Injection (WASC-19)

[69] Standards Mapping - Web Application Security Consortium 24 + 2 SQL Injection

desc.config.java.sql_injection_ibatis_data_map

SQL Injection: JDO

Java/JSP

Abstract

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

Explanation

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

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

2. データが SQL クエリまたは JDOQL クエリの動的な構築に使用された場合。

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


...
	String userName = ctx.getAuthenticatedUserName();
	String itemName = request.getParameter("itemName");
	String sql = "SELECT * FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ itemName + "'";
	Query query = pm.newQuery(Query.SQL, sql);
	query.setClass(Person.class);
	List people = (List)query.execute();
	...

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


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


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

OR 'a'='a' 条件を追加すると、where 句は常に真 (true) の評価をします。そのため、このクエリは次のような単純なクエリと論理的に等しくなります。


	SELECT * FROM items;


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

	DELETE FROM items;

	--'


	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 攻撃に対して安全になるわけではありません。

References

[1] S. J. Friedl SQL Injection Attacks by Example

[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine

[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus

[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press

[5] JDO API Documentation