CWE-89
Weakness ID:89(Weakness Base)
Status: Draft
SQLインジェクション
解説
解説要約
ソフトウェアが外部からの入力内容を上位コンポーネントを通じて使用し、その内容からSQLコマンドを構築している場合において、意図しているSQLコマンドを改ざんできてしまう特殊な要素を、適切に無効化せずに下位コンポーネントに送信する際に発生する脆弱性です。
詳細な解説
ユーザからの入力に含まれる SQL 構文に対する除去や引用符の処理が十分でないと、生成された SQL クエリにおいて、入力が通常のデータではなく SQL として解釈されてしまう可能性があります。これは、クエリのロジックを変えてセキュリティチェックを回避する、あるいは新たなステートメントを挿入してバックエンドのデータベースを改ざん（場合によってはシステムコマンドを実行）するのに利用される可能性があります。
SQL インジェクションは、データベースと連動する Web サイトによく見られるようになりました。本脆弱性は、容易に発見、悪用されるので、最小限度のユーザ数を有するサイトやソフトウェアパッケージにおいても攻撃を受ける可能性が高いです。この脆弱性は、SQL が制御とデータを区別しないことに起因します。
脆弱性の発生時期
アーキテクチャおよび設計
実装
操作
該当するプラットフォーム
言語
全て
分類
データベースサーバ
脆弱性の発生状況
本脆弱性は、データベースにユーザからの入力を保存するデータリッチアプリケーションで発生します。
一般的な影響
| 影響を受ける範囲 | 影響 |
|---|---|
| 機密性 | 技術的インパクト：アプリケーションデータの読み取り
SQL データベースは一般的に機密データを保持することが多いため、SQL インジェクションの脆弱性により機密性を損失する可能性があります。 |
| 認証 | 技術的インパクト：保護メカニズムの回避 ユーザ名およびパスワードのチェックに使用される SQL コマンドが脆弱な場合、パスワードを知らないユーザにシステムへ接続される可能性があります。 |
| 認可 | 技術的インパクト：保護メカニズムの回避 SQL データベースに認可情報が保存されている場合、SQL インジェクション攻撃によりその情報を書き換えられる可能性があります。 |
| 完全性 | 技術的インパクト：アプリケーションデータの改ざん SQL インジェクション攻撃により、機密情報の読み取り、改ざんや削除が行われる可能性があります。 |
攻撃を受ける可能性
非常に高い
攻撃を可能にする要因
ユーザからの入力を含むクエリを動的に生成するアプリケーション
検出手段
自動静的分析
本脆弱性は自動静的分析ツールによって検出が可能です。最近のツールの多くは、フォールスポジティブを最小化するために、データフロー分析や制約ベースの技術を使用しています。
自動静的分析は、入力の妥当性チェックが適切に行われている場合、例えば、セキュリティ上影響のない警告や、コードの変更を要求しない警告といったフォールスポジティブを識別できない可能性があります。
自動静的分析は、直接 SQL コマンドを呼び出すようなカスタム API 関数や、サードパーティのライブラリの使用を検出できない場合、特に API やライブラリのコードが分析に使用できない場合において、フォールスネガティブを引き起こす可能性があります。
この手段で、100％の精度を担保することややカバーは不可能なため、完璧な解決策ではありません。
自動静的分析
本脆弱性は、ファズテスト(ファジング)、ロバストネステスト(頑健性のテスト)や、フォールトインジェクション(エラーをわざと起こすテスト)等、多種多様な入力を持つ膨大なテストケースを使用してソフトウェアを分析する、動的なツールや技術を用いて検出することが可能です。
ソフトウェアの処理速度は低下しますが、処理が不安定になったり、クラッシュする、不正確な結果を出すといったことはありません。
有効性：中
手動分析
手動による分析は本脆弱性の発見に有効ですが、時間的な制約の中でコード全てを分析することは不可能であると考えます。全ての入力について考慮が必要な脆弱性の場合は攻撃可能な側面が大き過ぎるため、この手法による分析は困難です。
脆弱なコード例
例 1:
2008年、 同一のSQL インジェクションの攻撃文字列を用いて様々なプログラムが攻撃され、多くの Web サーバが被害に遭いました。この攻撃により、Web サイトが改ざんされ、悪意のあるコードの拡散に利用されました。
例 2:
以下のコードは、特定のユーザ名と一致する項目を検索する SQL クエリを動的に構築、実行するものです。表示する項目を、現在認証されているユーザ名と一致する項目のみに制限します。
サンプル言語： C# （悪い例）
... 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>;
しかし、このクエリはベースとなる定まったクエリ文とユーザの入力した文字列を連結して、動的に構築するため、itemName にシングルクォートを含まない場合のみ正しく動作します。例えば、「wiley」というユーザ名を用いて攻撃者が、以下を入力した場合：
（攻撃）
name' OR 'a'='a
itemNameに対して、このクエリは以下のようになります。
（攻撃）
SELECT * FROM items WHERE owner = 'wiley' AND itemname = 'name' OR 'a'='a';
加えられた
（攻撃）
OR 'a'='a'
という条件により WHERE句 は常に「真」となるため、クエリは論理的に、
（攻撃）
SELECT * FROM items;
と同様の意味となります。これにより攻撃者は、認証されたユーザが所有する項目のみを返すという要求を回避します。つまり、このクエリは入力されたユーザ名に関わらず、items テーブル内に保存された全てのエントリを返します。
例 3:
この例では、 例 2 とは異なる悪意ある値の効果を検証します。 「wiley」というユーザ名を用いて攻撃者が、以下の文字列を入力した場合、
（攻撃）
name'; DELETE FROM items; --
この文字列が itemName に入力されることにより、このクエリは以下の様に2つに分かれます。
サンプル言語： SQL （攻撃）
SELECT * FROM items WHERE owner = 'wiley' AND itemname = 'name'; DELETE FROM items; --'
Microsoft(R) SQL Server 2000 を含む多くのデータベースサーバは、セミコロンで区切られた複数の SQL ステートメントを同時に実行します。今回のような攻撃文字列を入力された場合、セミコロンで区切られた構文のバッチ処理を許可しない Oracle とその他のデータベースサーバではエラーを返しますが、バッチ処理を許可しているデータベースでは、攻撃者が任意のコマンドを実行する可能性があります。
多くのデータベースサーバにおいて、「--」以降のステートメントはコメントとして扱われ実行されません。今回の場合、「--」により改ざんされたクエリの最後に残ったシングルクォートをコメント化し取り除きます。この様なコメントを許容しないデータベースサーバにおいても、コメントを使用しない類似する仕組みにより一般的な攻撃の被害に遭う可能性があります。
攻撃者が以下のような文字列を入力した場合、
（攻撃）
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 インジェクションを入力に対する妥当性の確認の問題として扱い、安全な文字のみ登録して許可するホワイトリスト方式と、潜在的に悪意のある値を定めエスケープ処理を行うブラックリスト方式が挙げられます。 ホワイトリスト方式は、厳しい入力の妥当性の確認を行うことを強制するとても効果的な方法で、パラメータ化されたSQLステートメントはメンテナンスが少なく、セキュリティの観点で保証を与えます。 ブラックリスト方式は、ほとんどの場合において抜け漏れが多く、SQL インジェクション攻撃の対策として十分ではありません。例えば、攻撃者は以下のことが可能です。
・クォートで囲われていないフィールドを狙う
・エスケープ処理されるメタキャラクタを使用せずに攻撃する
・挿入したメタキャラクタを隠蔽するために、ストアドプロシージャを利用する
SQL クエリに対する入力を手動でエスケープ処理する方法が役立ちますが、SQL インジェクション攻撃からアプリケーションを確実に保護することはできません。
他の一般的な解決策として、ストアドプロシージャを利用することが挙げられます。しかし、ストアドプロシージャはある種類の SQL インジェクション攻撃に対しては有効ですが、その他大多数の SQL インジェクション攻撃に対しては効果がありません。例えば、以下の PL/SQL プロシージャは一つ目の例で挙げたような 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;
ストアドプロシージャは、パラメータに引き渡すステートメントのタイプを制限することにより、SQL インジェクション攻撃の防御に役立ちます。しかし、制限を回避する手段や、ストアドプロシージャを回避するステートメントは数多く存在します。この場合もやはり、SQL インジェクション攻撃からアプリケーションを確実に保護することはできません。
例 4:
MS SQL にはシェルコマンドの実行を有効にする組み込み関数が存在します。このようなコンテキストにおける SQL インジェクションは非常に危険です。次のクエリを例に挙げます。
（悪い例）
SELECT ITEM,PRICE FROM PRODUCT WHERE ITEM_CATEGORY='$user_input' ORDER BY PRICE
ここで、$user_input にはユーザからの入力がフィルタリングされていない状態で引き渡されます。 ユーザが以下の文字列を入力した場合
（攻撃）
' exec master..xp_cmdshell 'dir' --
このクエリは以下のように解釈されます。
（攻撃）
SELECT ITEM,PRICE FROM PRODUCT WHERE ITEM_CATEGORY='' exec master..xp_cmdshell 'dir' --' ORDER BY PRICE
不正な入力により、このクエリは3つに分解され、クエリ、シェルコマンドの実行文、およびコメント文に変更されます。
[1] 一番目のSQL クエリ : SELECT ITEM,PRICE FROM PRODUCT WHERE ITEM_CATEGORY=''
[2] 二番目のSQLクエリ（シェルコマンドを実行） : exec master..xp_cmdshell 'vol'
[3] MS SQLのコメント文 : --' ORDER BY PRICE
例 5:
以下の例は、MessegeID に与えられたメッセージサマリを出力します。
サンプル言語： PHP （悪い例）
$id = $_COOKIE["mid"];
mysql_query("SELECT MessageID, Subject FROM messages WHERE MessageID = '$id'");
プログラマは cookie は改ざんが不可能であると想定し、$id に対する妥当性の確認を省略します。しかし、実際には特別に作成したクライアントコードの利用や、Web ブラウザ内でさえ cookie の改ざんは容易です。
mysql_query() の呼び出し時に $id がシングルクォートで囲われているため、攻撃者は呼び出す mid cookie を次のように改ざんします。
（攻撃）
1432' or '1' = '1
結果として、クエリは以下の様になります。
（結果）
SELECT MessageID, Subject FROM messages WHERE MessageID = '1432' or '1' = '1'
このコードは、メッセージ ID 1432 を検索するだけでなく、その他の全てのメッセージを呼び出します。
この場合は、コードの単純な変更により SQL インジェクションの脆弱性を取り除くことができます。
サンプル言語： PHP（良い例）
$id = intval($_COOKIE["mid"]);
mysql_query("SELECT MessageID, Subject FROM messages WHERE MessageID = '$id'");
しかし、このコードがユーザにより異なるメッセージボックスをサポートするものである場合、アプリケーションのユーザがメッセージを閲覧する権限を持っているか確認するために、アクセスコントロールのチェック (CWE-285) が必要となります。
例 6:
この例では、ユーザから入力された名前を受け取り、データベースへの登録を行います。
サンプル言語：Perl （悪い例）
$userKey = getUserID();
$name = getUserInput();
# ensure only letters, hyphens and apostrophe are allowed
$name = whiteList($name, "^a-zA-z'-$");
$query = "INSERT INTO last_names VALUES('$userKey', '$name')";
ユーザからの入力に対してホワイトリスト方式を適応していますが、この場合には欠点があります。 まず、SQL でコメントを構築するために使用されるハイフンが許可されています。ユーザが「--」を入力すると、それ以降のステートメントはコメントとして扱われ、セキュリティロジックを回避される可能性があります。
さらに、このホワイトリストでは、データとコマンドの区別をするアポストロフィも許可されています。ユーザが名前にアポストロフィを入力すると、ステートメント全体の構造が変わったり、プログラムの制御フローが変更され、場合によっては機密情報にアクセスされたり、改ざんされる可能性があります。
この場合では、ハイフンやアポストロフィは名前として使用される正規の文字として許可するよう要求されています。データやコマンドの誤解釈を避ける代替策として、既存のステートメントを使用するか、全てのデータ及び命令の誤った解釈を防ぐルーチンのエンコーディングの適用が望ましいでしょう。
発見された事例
| 参照 | 詳細 |
|---|---|
| CVE-2004-0366 | chain: SQL injection in library intended for database authentication allows SQL injection and authentication bypass. |
| CVE-2008-2790 | SQL injection through an ID that was supposed to be numeric. |
| CVE-2008-2223 | SQL injection through an ID that was supposed to be numeric. |
| CVE-2007-6602 | SQL injection via user name. |
| CVE-2008-5817 | SQL injection via user name or password fields. |
| CVE-2003-0377 | SQL injection in security product, using a crafted group name. |
| CVE-2008-2380 | SQL injection in authentication library. |
被害の緩和策
フェーズ：アーキテクチャおよび設計
戦略： ライブラリ、フレームワーク
本脆弱性の発生を防ぐ、あるいは本脆弱性を回避しやすい構造を提供する、十分に検査されたライブラリやフレームワークを使用してください。
例として、適切な使用により SQL インジェクションに対する強力な保護となる Hibernate Java Beans や Enterprise Java Beans などの永続性を持つレイヤが挙げられます。
フェーズ：アーキテクチャおよび設計
戦略：パラメータ化
可能であれば、自動的にデータとコード間の分離を強制するような、構造化された仕組みを使用してください。
このような仕組みにより、開発者が手動で行う代わりに、出力が生成される全ての箇所に、関連するクォート、エンコード、入力の妥当性チェックの機能を自動的に提供することが可能です。
用意されたステートメント、パラメータ化されたクエリ、ストアドプロシージャを用いて SQL クエリを処理して下さい。その際、パラメータや変数を受け入れ、強い型付をサポートするものを使用して下さい。SQL インジェクションを再導入する可能性があるため、決して動的な構造や "exec" や類似する関数を含むものの使用は避けて下さい。
フェーズ：アーキテクチャおよび設計、オペレーション
戦略： 環境の強化
必要なタスクを実行するために求められる最小限の権限を使用してコードを実行してください。可能であれば、一つのタスクのみに使用される、権限を限定した単独のアカウントを作成してください。それにより、攻撃が成功した場合でも、即座に他のソフトウェアやその環境へアクセスされることを防ぐことができます。例えば、特に日常的なオペレーションにおいて、めったにデータベースの管理者権限を必要としないデータベースアプリケーションが挙げられます。
具体的には、ユーザアカウントをSQLデータベースに作成する場合、最小特権の原則に従って下さい。ユーザへの権限付与は必要最小限のみとすべきです。システムの要件に、ユーザ自身のデータの読み取りおよび変更が含まれている場合、他のユーザのデータを読み取りや書き込みができないよう権限を制限して下さい。ストアドプロシージャは実行のみ許可するなど、可能な限りデータベースのオブジェクトへのパーミッションは厳しく制限して下さい。
フェーズ：アーキテクチャおよび設計
CWE-602 を防ぐために、クライアント側で行われる全てのセキュリティチェックがサーバ側でも同様に行われていることを確認してください。攻撃者はチェックが行われたあとに値を改ざんする、あるいはチェックを完全に消去することで、クライアント側のチェックを回避することが可能です。その場合、改ざんされた値がサーバに送信されます。
フェーズ：実装
戦略：出力エンコーディング
リスクを受容し、動的に生成されるクエリやコマンドを使用する必要がある場合には、適切に引数をクォートし、引数に含まれる特殊文字をエスケープして下さい。最も慎重な手法として、非常に厳重なホワイトリストを通過しない全ての文字について、エスケープ又はフィルタリングを行う（英数字以外の全ての文字や空白等）ことが挙げられます。空白等の特殊文字の使用が必要な場合は、エスケープ又はフィルタリングの処理後、それぞれの引数をクォートで囲ってください。argument injection（CWE-88）の脆弱性が発生しないよう注意してください。
データベースやプログラミング言語においては、独自に実装する代わりに以下のような機能の利用が有効です。Oracle DBMS_ASSERT パッケージは、パラメータが SQL インジェクションに対する脆弱性を減少するようなプロパティを持っているかどうかのチェックや、そのプロパティを強制することが可能です。また、MySQL の mysql_real_escape_string() API 関数は、C 言語と PHP の両方で利用可能です。
フェーズ：実装
全ての入力は悪意のあるものと想定してください。仕様に厳密に従い許可するホワイトリストを使用する等、既知の入力の妥当性チェック手法を用いてください。仕様に反する入力を拒否する、あるいは入力を仕様に適応する形に変化させてください。ブラックリストに依存してしまう等、悪意のある、あるいは不正な入力を探すことのみに依存しないでください。しかし、ブラックリストは予測される攻撃の検知や、無条件に拒否するべき不正な入力を決定する際に役立ちます。
入力値の妥当性をチェックする際、関連しそうな全ての要素（長さ、入力タイプ、許容する値の範囲、入力の過不足、構文、関連するフィールド間の一貫性、及びビジネスルールの一致、等）について考慮してください。ビジネスルールの例として、"boat" は英数字しか含まないため構文的に有効ですが、もし開発者が "red" や "blue" のような色の名前を想定する場合には有効ではない、というロジックが挙げられます。
SQL クエリを構築する場合には、パラメータやリクエストとして予期される値の文字セットを制限する厳しいホワイトリストを使用してください。これにより、間接的に攻撃の範囲を限定することが可能ですが、適切な出力エンコード及びエスケープと比較すると緩和策としての重要度は下がります。
適切な出力のエンコード、エスケープ、クォートは、SQL インジェクションを防ぐために最も効果的な解決策であるのに対し、入力の妥当性チェックは多層防御で提供するものであることに注意してください。これは、実際に出力される内容を効果的に制限するからです。入力の妥当性のチェックだけでOSコマンドインジェクションを防げるわけではありません。特に、任意の内容を自由に入力可能なテキストフィールドのサポートを必要とする場合は困難になります。例えば、「O'Reilly」という名前は、英語ではありふれた名字であるため妥当性の確認を回避できるように思われます。しかし、アポストロフィが含まれているため、エスケープ処理をするか、別の方法での処理が必要になります。この場合、アポストロフィを取り除くことで SQL インジェクションのリスクを軽減することは可能ですが、不正確な名前が登録されてしまうため、誤った動作を引き起こす可能性があります。
実現可能であれば、これが、エスケープの代わりとしてメタキャラクタを完全に拒否する最も安全な手段です。この手段は、多層防御の効果も発揮します。データがデータベースに登録された後、以降のプロセスは、それ以前に使用されたメタキャラクタのエスケープを無視します。また、それらのプロセスに対してのコントロールは不可能です。
フェーズ：アーキテクチャおよび設計
戦略： 変換による強制
ファイル名やURLのような条件に適合するオブジェクトが制限されている場合、あるいは既知である場合、固定した入力値（数字のID等）から実際のファイル名やURLのマッピングを作成し、それ以外の入力を拒否してください。
フェーズ：実装
エラーメッセージが対象となる読者にとってのみ有益な、最小限の詳細情報しか含まないことを確認してください。メッセージは適度に曖昧になるようにバランスを取る必要があります。エラー内容を判別する方法を公開する必要は必ずしもありません。そのような詳細情報は攻撃が成功する機会を増やす可能性があります。
もし、エラーによる詳細を追跡する必要がある場合、ログメッセージに記録するようにしてください。しかし、攻撃者がログメッセージを閲覧可能である場合に何が起こるかも考慮してください。どんな形式であってもパスワードのような極秘情報が記録されることは避けるべきです。また、ユーザ名が有効か否かといった、攻撃者に内部の構文を推測されてしまうような、一貫性のないメッセージにならないよう避けてください。
SQL インジェクションの背景において、SQL クエリの構造を公開してしまうようなエラーメッセージは、攻撃者が攻撃文字列を組み立てることを助長しまう可能性があります
フェーズ：オペレーション
戦略： ファイアウォール
本脆弱性に対する攻撃を検知するアプリケーションファイアウォールを使用してください。第三者が制作したソフトウェアであるためコードが修正できない場合などに、より総合的なソフトウェアの保証手段となるため、緊急回避策として、または多層防御の目的として効果的です。
有効性：中
アプリケーションファイアウォールは全ての入力ベクターを網羅することができない可能性があります。加えて、入力を検証する処理に対して不正な形式の入力により、防御メカニズムを迂回するような行為が可能です。アプリケーションファイアウォールの機能によっては、不用意に正当なリクエストを拒否、または修正してしまう可能性があります。最終的に、手動によるカスタマイズが必要です。
フェーズ：オペレーション、実装
戦略： 環境の強化
PHP を使用している場合は、register_globals を使用しないようにアプリケーションを設定してください。実装においては、この機能に頼らないようアプリケーションを開発してください。register_globals の類似機能の実装においては CWE-95、CWE-261 及び類似する脆弱性の対象とならないよう警戒してください。
関係性
| Nature | Type | ID | Name | View(s) this relationship pertains to |
|---|---|---|---|---|
| ChildOf | Weakness Class | 20 | Improper Input Validation | Seven Pernicious Kingdoms (primary)700 |
| ChildOf | Weakness Class | 77 | Improper Neutralization of Special Elements used in a Command ('Command Injection') | Development Concepts (primary)699 |
| Research Concepts (primary)1000 | ||||
| ChildOf | Category | 713 | OWASP Top Ten 2007 Category A2 - Injection Flaws | Weaknesses in OWASP Top Ten (2007) (primary)629 |
| ChildOf | Category | 722 | OWASP Top Ten 2004 Category A1 - Unvalidated Input | Weaknesses in OWASP Top Ten (2004)711 |
| ChildOf | Category | 727 | OWASP Top Ten 2004 Category A6 - Injection Flaws | Weaknesses in OWASP Top Ten (2004) (primary)711 |
| ChildOf | Category | 751 | 2009 Top 25 - Insecure Interaction Between Components | Weaknesses in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)750 |
| ChildOf | Category | 801 | 2010 Top 25 - Insecure Interaction Between Components | Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors(primary)800 |
| ChildOf | Category | 810 | OWASP Top Ten 2010 Category A1 - Injection | Weaknesses in OWASP Top Ten (2010)(primary)809 |
| ParentOf | Weakness Variant | 564 | SQL Injection: Hibernate | Development Concepts (primary)699 |
| Research Concepts (primary)1000 | ||||
| MemberOf | View | 630 | Weaknesses Examined by SAMATE | Weaknesses Examined by SAMATE (primary)630 |
| MemberOf | View | 635 | Weaknesses Used by NVD | Weaknesses Used by NVD (primary)635 |
| CanFollow | Weakness Base | 456 | Missing Initialization | Research Concepts1000 |
関係性の補足
SQL インジェクションは、特殊文字の管理ミス、MAID、ブラックリスト／ホワイトリスト上の問題の結果として発生し、認証エラーの要因となる可能性があります。
他組織での分類
| 組織名または組織での分類 | ノード ID | CWEの分類との適合度 | 分類名 |
|---|---|---|---|
| PLOVER | SQL injection | ||
| 7 Pernicious Kingdoms | SQL injection | ||
| CLASP | SQL injection | ||
| OWASP Top Ten 2007 | A2 | CWEの方が詳細 | Injection Flaws |
| OWASP Top Ten 2004 | A1 | CWEの方が詳細 | Unvalidated Input |
| OWASP Top Ten 2004 | A6 | CWEの方が詳細 | Injection Flaws |
| WASC | 19 | SQL Injection |
関連する攻撃パターン
| CAPEC-ID | 攻撃パターン名 (CAPEC Version 1.5) |
|---|---|
| 7 | Blind SQL Injection |
| 66 | SQL Injection |
| 108 | Command Line Execution through SQL Injection |
| 109 | Object Relational Mapping Injection |
| 110 | SQL Injection through SOAP Parameter Tampering |
ホワイトボックスの定義
コードパスが以下の条件を満たす脆弱性
1. 開始ステートメントで入力を受け付ける場合、かつ
2. 終了ステートメントで、以下の条件を満たす SQL コマンドを実行する場合
・入力が SQL コマンドの一部であり、SQL 構文を含む(特にクエリセパレータ等)場合
参照
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 1: SQL Injection." Page 3. McGraw-Hill. 2010.
[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 12, "Database Input Issues" Page 397. 2nd Edition. Microsoft. 2002.
OWASP. "SQL Injection Prevention Cheat Sheet". <http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet>.
Steven Friedl. "SQL Injection Attacks by Example". 2007-10-10. <http://www.unixwiz.net/techtips/sql-injection.html>.
Ferruh Mavituna. "SQL Injection Cheat Sheet". 2007-03-15. <http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/>.
David Litchfield, Chris Anley, John Heasman and Bill Grindlay. "The Database Hacker's Handbook: Defending Database Servers". Wiley. 2005-07-14.
David Litchfield. "The Oracle Hacker's Handbook: Hacking and Defending Oracle". Wiley. 2007-01-30.
Microsoft. "SQL Injection". December 2008. <http://msdn.microsoft.com/en-us/library/ms161953.aspx>.
Microsoft Security Vulnerability Research & Defense. "SQL Injection Attack". <http://blogs.technet.com/swi/archive/2008/05/29/sql-injection-attack.aspx>.
Michael Howard. "Giving SQL Injection the Respect it Deserves". 2008-05-15. <http://blogs.msdn.com/sdl/archive/2008/05/15/giving-sql-injection-the-respect-it-deserves.aspx>.
Frank Kim. "Top 25 Series - Rank 2 - SQL Injection". SANS Software Security Institute. 2010-03-01. <http://blogs.sans.org/appsecstreetfighter/2010/03/01/top-25-series-rank-2-sql-injection/>.
更新履歴
[2011年04月21日]
2010年10月12日時点のデータを元に更新
[2009年06月29日]
2009年02月02日時点の下記 URL を元に作成
http://cwe.mitre.org/data/definitions/89.html
登録日 2011/04/21
最終更新日 2023/04/04
