【活用ガイド】

CWE-20

Weakness ID:20(Weakness Class)

Status: Draft

不適切な入力確認

解説

解説要約

この脆弱性がある製品は、プログラムの制御フローおよびデータフローへ影響を及ぼす入力に対し、適切な妥当性チェックを行いません。

詳細な解説

ソフトウェアにおける入力の妥当性の確認が不十分な場合、攻撃者が他のアプリケーションのフォームに意図しない入力をする可能性があります。この入力はシステムの一部に受け渡され、制御フローの改ざん、任意のリソースの制御、任意のコードを実行される可能性があります。

脆弱性の発生時期

アーキテクチャおよび設計
実装

該当するプラットフォーム

言語

言語に依存

プラットフォームの補足

入力に対する妥当性の確認は、外部からのデータを扱う全てのシステムにおける問題となる可能性があります。

一般的な影響

 

影響を受ける範囲 影響
可用性 予期しない値の入力により、プログラムがクラッシュ、あるいはメモリや CPU 等のリソースを過度に消費する可能性があります。
機密性 攻撃者がリソースの参照を制御可能な場合、機密データを読み取る可能性があります。
完全性 任意のコマンド実行を含めた悪意ある入力により、予期しない方法でデータや制御フローを改ざんされる可能性があります。

 

攻撃を受ける可能性

高い

検出手段

自動静的分析
入力の妥当性チェックが不十分なインスタンスは、自動静的分析を使用することで検出可能です。 静的分析ツールはアプリケーション特有の入力の妥当性チェックの手法や関数を特定することが可能です。Strutsのようなツールは、妥当性チェックのフレームワークとして、組込みのナレッジを備えています。これらのツールは、関連する警告を抑制したり、警告の優先度を下げられます。これにより、ソフトウェアの入力の妥当性チェックが存在しない箇所に焦点を当てることが可能です。 前段で例示した場合を除き、自動静的分析は入力の妥当性チェックが適切に行われている場合、例えば、セキュリティ上影響のない警告や、コードの変更を要求しない警告といったフォールスポジティブを識別できない可能性があります。

手動静的分析
ビジネスルールの強制等、カスタマイズされた入力の妥当性チェックが要求される場合は、妥当性チェックが適切に実装されることを確認するために手動分析が必要です。

ファジング
ファジング手法は入力の妥当性チェックのエラー検出に有効です。予期しない入力が与えられた場合、ソフトウェアはクラッシュしたり不安定な状態になるのではなく、アプリケーションのコントロールによるエラーメッセージを生成すべきです。例外やインタプリタに生成されたエラーメッセージが発生した場合、入力は検出されずアプリケーションロジックで処理されたことを意味します。

脆弱なコード例

例 1:

 

以下の例は、ユーザが購入する商品の数量を入力し、その入力に基づいて合計金額を計算するショッピングの通信におけるプログラムです。

サンプル言語: Java (悪い例)
...
public static final double price = 20.00;
int quantity = currentUser.getAttribute("quantity");
double total = price * quantity;
chargeUser(total);
…

ユーザは、商品の価格を定める price 変数を操作することはできませんが、数量へ負の値を入力することは制限されていません。攻撃者が負の値を入力した場合、代金の引き落としの代わりに、攻撃者の口座へ入金される可能性があります。

 

例 2:

 

以下の例では、100平方を最大面積とするゲーム盤の幅と高さ (m×n) をユーザの入力により定めます。

サンプル言語: C (悪い例)
...
#define MAX_DIM 100
...
/* board dimensions */
int m,n, error; 
board_square_t *board;
printf("Please specify the board height: ¥n");
error = scanf("%d", &m);
if ( EOF == error ){
die("No integer passed: Die evil hacker!¥n");
}
printf("Please specify the board width: ¥n");
error = scanf("%d", &n);
if ( EOF == error ){
die("No integer passed: Die evil hacker!¥n");
}
if ( m > MAX_DIM || n > MAX_DIM ) {
die("Value too large: Die evil hacker!¥n");
}
board = (board_square_t*) malloc( m * n * sizeof(board_square_t));
...

このコードでは、ユーザが大きな正の値の入力を確認することで、メモリの消費過多を防いでいますが、負の数値に対する確認を行っていません。結果として、オーバーフローしない二つの大きな負の値を指定することにより、膨大なメモリが割り当てられシステムがクラッシュする resource consumption (CWE-400)攻撃を受ける可能性があります。 また、非常に大きな負の値の入力により integer overflow (CWE-190) を引き起こし、その値の扱い方により予期しない動作をする可能性があります。

 

例 3:

 

以下の例では、ユーザの生年月日とホームページを表示する PHP アプリケーションのコードを示しています。
サンプル言語: PHP (悪い例)
$birthday = $_GET['birthday'];
$homepage = $_GET['homepage'];
echo "Birthday: $birthday<br>Homepage: <a href=$homepage>click here</a>"

プログラマは、$birthday には日付の書式、$homepage には有効な URL が入ることを想定しています。しかし、この値は HTTP リクエストから取得するため、攻撃者が改ざんし、birthday あるいは homepage に値を与える <script>タグの入った URL を被害者にクリックさせた場合、Webサーバがコンテンツを返す際、このスクリプトがクライアントのブラウザで実行されます。たとえ $birthday に対する入力を、整数と「-(ダッシュ)」に制限してたとしても、以下の様な入力は可能です。

(攻撃)
2009-01-09--			

このデータが SQL ステートメントで使用された場合、この入力以降のステートメントをコメントとして扱います。コメントはステートメント内の他のセキュリティ関連のロジックを無効にします。この場合、エンコードと入力の妥当性確認を併用することで、防御メカニズムはより有効なものになります。

さらに、XSS (CWE-79) 攻撃および SQL injection (CWE-89) は、この種類のフィールドの防御メカニズムにおける潜在的な結果の一部でしかありません。 コードの前後関係によっては、CRLF Injection (CWE-93)、Argument Injection (CWE-88) や、Command Injection (CWE-77) を引き起こす可能性があります。

 

例 4:

 

以下の例は、ユーザから m と n の一組の数字の入力を受け付けるものです。

サンプル言語: C (悪い例)
void parse_data(char *untrusted_input){
int m, n, error;
error = sscanf(untrusted_input, "%d:%d", &m, &n);
if ( EOF == error ){
die("Did not specify integer value. Die evil hacker!¥n");
}
/* proceed assuming n and m are initialized correctly */
}

このコードではユーザによる初期化された入力から、2つの int 型の値を抜き出します。しかし、攻撃者が「123:」という値を入力した場合、変数 m のみ初期化されます。

(攻撃)
123:

その結果、n を使用すると uninitialized variable (CWE-457) が発生する可能性があります。

 

例 5:

 

以下の例では、オブジェクトの配列を割り当てるため、ユーザの入力を受け取り、その配列を操作します。
サンプル言語: Java (悪い例)
private void buildList ( int untrustedListSize ){
if ( 0 > untrustedListSize ){
die("Negative value supplied for list size, die evil hacker!");
}
Widget[] list = new Widget [ untrustedListSize ];
list[0] = new Widget();
}

この例では、ユーザが指定した値からリストを作り、負の値ではないことを確認するためチェックを行います。しかし、0が入力された場合、サイズが0の配列が生成され、最初の場所に新しいWidgetが保存されます。

 

発見された事例

 

参照 詳細
CVE-2008-5305 Eval injection in Perl program using an ID that should only contain hyphens and numbers.
CVE-2008-2223 SQL injection through an ID that was supposed to be numeric.
CVE-2008-3477 lack of input validation in spreadsheet program leads to buffer overflows, integer overflows, array index errors, and memory corruption.
CVE-2008-3843 insufficient validation enables XSS
CVE-2008-3174 driver in security product allows code execution due to insufficient validation
CVE-2007-3409 infinite loop from DNS packet with a label that points to itself
CVE-2006-6870 infinite loop from DNS packet with a label that points to itself
CVE-2008-1303 missing parameter leads to crash
CVE-2007-5893 HTTP request with missing protocol version number leads to crash
CVE-2006-6658 request with missing parameters leads to information leak
CVE-2008-4114 system crash with offset value that is inconsistent with packet size
CVE-2006-3790 size field that is inconsistent with packet size leads to buffer over-read
CVE-2008-2309 product uses a blacklist to identify potentially dangerous content, allowing attacker to bypass a warning
CVE-2008-3494 security bypass via an extra header
CVE-2006-5462 use of extra data in a signature allows certificate signature forging
CVE-2008-3571 empty packet triggers reboot
CVE-2006-5525 incomplete blacklist allows SQL injection
CVE-2008-1284 NUL byte in theme name cause directory traversal impact to be worse
CVE-2008-0600 kernel does not validate an incoming pointer before dereferencing it
CVE-2008-1738 anti-virus product has insufficient input validation of hooked SSDT functions, allowing code execution
CVE-2008-1737 anti-virus product allows DoS via zero-length field
CVE-2008-3464 driver does not validate input from userland to the kernel
CVE-2008-2252 kernel does not validate parameters sent in from userland, allowing code execution
CVE-2008-2374 lack of validation of string length fields allows memory consumption or buffer over-read
CVE-2008-1440 lack of validation of length field leads to infinite loop
CVE-2008-1625 lack of validation of input to an IOCTL allows code execution
CVE-2008-3177 zero-length attachment causes crash
CVE-2007-2442 zero-length input causes free of uninitialized pointer
CVE-2008-5563 crash via a malformed frame structure
CVE-2008-5285 infinite loop from a long SMTP request
CVE-2008-3812 router crashes with a malformed packet
CVE-2008-3680 packet with invalid version number leads to NULL pointer dereference
CVE-2008-3660 crash via multiple "." characters in file extension

 

被害の緩和策

フェーズ:アーキテクチャおよび設計

戦略:入力の妥当性チェック、ライブラリ、フレームワーク
Struts または OWASP ESAPI Validation API のような、入力の妥当性を確認するフレームワークを使用して下さい。Struts を使用する場合は、CWE-101 カテゴリの脆弱性に注意して下さい。

フェーズ:アーキテクチャおよび設計、実装

ソフトウェアにおいて信頼できない入力を受け付ける箇所を全て把握してください。例:パラメータや引数、cookie、ネットワークから読み込む全て、環境変数、DNSの逆引き、クエリ結果、リクエストヘッダ、URL コンポーネント、e-mail、ファイル、ファイル名、データベース、及びアプリケーションにデータを提供する全ての外部システム
そのような入力は API 呼び出しを間接的に介して行われることに注意してください。

フェーズ:実装

全ての入力は悪意のあるものと想定してください。仕様に厳密に従い許可する入力のホワイトリストを使用する等、既知の受け入れられている入力の妥当性チェック手法を用いてください。仕様に反する入力を拒否する、あるいは入力を仕様に適応する形に変化させてください。ブラックリストに依存してしまう等、悪意のある、あるいは不正な入力を探すことのみに依存しないでください。しかし、ブラックリストは予測される攻撃の検知や、無条件に拒否するべき不正な入力を決定する際に役立ちます。

入力値の妥当性をチェックする際、関連しそうな全ての要素(長さ、入力タイプ、許容する値の範囲、入力の過不足、構文、関連するフィールド間の一貫性、及びビジネスルールの一致、等)について考慮してください。ビジネスルールの例として、"boat" は英数字しか含まないため構文的に有効ですが、もし開発者が "red" や "blue" のような色の名前を想定する場合には有効ではない、というロジックが挙げられます。

フェーズ:アーキテクチャおよび設計

CWE-602 を防ぐために、クライアント側で行われる全てのセキュリティチェックがサーバ側でも同様に行われていることを確認してください。攻撃者はチェックが行われたあとに値を改ざんする、あるいはチェックを完全に消去することで、クライアント側のチェックを回避することが可能です。その場合、改ざんされた値がサーバに送信されます。

サーバ側に対し、クライアント側でのチェックが最小限のメリットしかない場合でも、以下の点において役立ちます。
・クライアント側で拒否されるはずの不正な入力がサーバに受け渡された場合は攻撃の兆候である可能性があるため、侵入検知として機能します。
・クライアント側でのエラーチェックは期待される妥当な入力の参考となるフィードバックを提供します。
・わずかではありますが、予想外の入力エラーに対し、サーバ側の処理時間の削減となります。

フェーズ:アーキテクチャおよび設計

悪意のある入力の検知や出力のエンコードにおいて、ブラックリストによる入力の妥当性の確認は完全ではありません(CWE-184)。一つの文字をエンコードする方法は多数存在するため、見落としが発生する可能性があります。

フェーズ:実装

アプリケーションが複数の情報源から組み合わせてデータを作成する場合、データが完成した後で妥当性の確認を行ってください。個々のデータ要素が妥当性の確認を通過したとしても、組み合せたデータが妥当性の確認を通過するとは限りません。

フェーズ:実装

インタープリタ型言語からネイティブコードへ等、言語のバイナリをまたいでコードを引き渡す場合には、特に注意して入力の妥当性の確認を行ってください。言語バイナリ間で予期しない相互作用が発生する可能性があります。引き渡すコードが、引き渡し先の言語にとって予期していない入力でないか確認してください。例えば、Java はバッファオーバーフローの影響を受けにくいですが、ネイティブコードの呼び出しにおける大きな引数の受け渡しにより、オーバーフローを引き起こす可能性があります。

フェーズ:実装

文字列から数字への変換関数を使用するなど、入力されたデータを予期されたデータの種類に変換して下さい。変換後は、値が予期された範囲に収まっているか、複数のフィールド間において一貫性が保たれているか確認して下さい。

フェーズ:実装

妥当性を確認する前に入力をデコードし、アプリケーションの現在の内部表現に正規化して下さい(CWE-180、 CWE-181)。また、アプリケーションが同じ入力を二回以上デコードしてしまわないよう確認して下さい(CWE-174)。そのようなエラーはチェック済みの危険な入力を呼び込むことにより、ホワイトリストを回避することに利用されます。OWASP ESAPI Canonicalization control のようなライブラリを使用して下さい。

それ以上変化しなくなるまで入力の正規化を繰り返して下さい。これにより、二重デコードや類似する現象を防ぐことが可能です。しかしこの場合、適切にエンコードされた危険なコンテンツを含む入力を書き換えてしまう可能性があります。

フェーズ:実装

コンポーネント間でデータをやり取りする場合、両方のコンポーネントが同じ文字エンコードを行っていることを確認して下さい。それぞれのインターフェースにおいて、適切にエンコーディングが行われていることを確認してください。プロトコル上可能な限り、エンコードを明示的に設定して下さい。

フェーズ:テスト

本脆弱性を検出可能な自動静的分析ツールを使用してください。最近の多くの手法は、フォールスポジティブを最小化するためにデータフロー分析を使用しています。ツールにより 100% の精度やカバーの範囲は実現不可能であるため、完璧な解決策ではありません。

フェーズ:テスト

ファズテスト(ファジング)、ロバストネステスト(頑健性のテスト)や、フォールトインジェクション(エラーをわざと起こすテスト)等、多種多様な入力を持つ膨大なテストケースを使用してソフトウェアを分析する、動的なツールや技術を使用してください。ソフトウェアの処理速度は低下しますが、処理が不安定になったり、クラッシュする、不正確な結果を出すといったことはありません。

関係性

 

Nature Type ID Name View(s) this relationship pertains to
ChildOf Category 19 Data Handling Development Concepts (primary)699
ChildOf Weakness Class 693 Protection Mechanism Failure Research Concepts (primary)1000
ChildOf Category 722 OWASP Top Ten 2004 Category A1 - Unvalidated Input Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOf Category 738 CERT C Secure Coding Section 04 - Integers (INT) Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOf Category 742 CERT C Secure Coding Section 08 - Memory Management (MEM) Weaknesses Addressed by the CERT C Secure Coding Standard734
ChildOf Category 746 CERT C Secure Coding Section 12 - Error Handling (ERR) Weaknesses Addressed by the CERT C Secure Coding Standard734
ChildOf Category 747 CERT C Secure Coding Section 49 - Miscellaneous (MSC) Weaknesses Addressed by the CERT C Secure Coding Standard734
ChildOf Category 751 Insecure Interaction Between Components Weaknesses in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)750
CanPrecede Weakness Class 22 Path Traversal Research Concepts1000
CanPrecede Weakness Base 41 Failure to Resolve Path Equivalence Research Concepts1000
CanPrecede Weakness Class 74 Failure to Sanitize Data into a Different Plane (aka 'Injection') Research Concepts1000
CanPrecede Weakness Base 15 External Control of System or Configuration Setting Seven Pernicious Kingdoms (primary)700
ParentOf Category 21 Pathname Traversal and Equivalence Errors Development Concepts (primary)699
ParentOf Weakness Class 73 External Control of File Name or Path Development Concepts (primary)699
Seven Pernicious Kingdoms (primary)700
ParentOf Weakness Class 77 Failure to Sanitize Data into a Control Plane (aka 'Command Injection') Seven Pernicious Kingdoms (primary)700
ParentOf Weakness Base 79 Failure to Preserve Web Page Structure (aka 'Cross-site Scripting') Seven Pernicious Kingdoms (primary)700
ParentOf Weakness Base 89 Failure to Preserve SQL Query Structure (aka 'SQL Injection') Seven Pernicious Kingdoms (primary)700
ParentOf Weakness Base 99 Insufficient Control of Resource Identifiers (aka 'Resource Injection') Seven Pernicious Kingdoms (primary)700
ParentOf Weakness Class 100 Technology-Specific Input Validation Problems Development Concepts (primary)699
Research Concepts (primary)1000
ParentOf Weakness Variant 102 Struts: Duplicate Validation Forms Seven Pernicious Kingdoms (primary)700
ParentOf Weakness Variant 103 Struts: Incomplete validate() Method Definition Seven Pernicious Kingdoms (primary)700
ParentOf Weakness Variant 104 Struts: Form Bean Does Not Extend Validation Class Seven Pernicious Kingdoms (primary)700
ParentOf Weakness Variant 105 Struts: Form Bean Does Not Extend Validation Class Seven Pernicious Kingdoms (primary)700
Research Concepts (primary)1000
ParentOf Weakness Variant 106 Struts: Plug-in Framework not in Use Seven Pernicious Kingdoms (primary)700
ParentOf Weakness Variant 107 Struts: Unused Validation Form Seven Pernicious Kingdoms (primary)700
ParentOf Weakness Variant 108 Struts: Unvalidated Action Form Seven Pernicious Kingdoms (primary)700
Research Concepts (primary)1000
ParentOf Weakness Variant 109 Struts: Validator Turned Off Seven Pernicious Kingdoms (primary)700
ParentOf Weakness Variant 110 Struts: Validator Without Form Field Seven Pernicious Kingdoms (primary)700
ParentOf Weakness Base 111 Direct Use of Unsafe JNI Development Concepts (primary)699
Seven Pernicious Kingdoms (primary)700
ParentOf Weakness Base 112 Missing XML Validation Development Concepts (primary)699
Seven Pernicious Kingdoms (primary)700
Research Concepts (primary)1000
ParentOf Weakness Base 113 Failure to Sanitize CRLF Sequences in HTTP Headers (aka 'HTTP Response Splitting') Seven Pernicious Kingdoms (primary)700
ParentOf Weakness Base 114 Process Control Development Concepts (primary)699
Seven Pernicious Kingdoms (primary)700
Research Concepts (primary)1000
ParentOf Weakness Base 117 Incorrect Output Sanitization for Logs Development Concepts (primary)699
Seven Pernicious Kingdoms (primary)700
ParentOf Weakness Class 119 Failure to Constrain Operations within the Bounds of a Memory Buffer Development Concepts (primary)699
Seven Pernicious Kingdoms (primary)700
ParentOf Compound Element: Composite 120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') Seven Pernicious Kingdoms (primary)700
ParentOf Weakness Base 129 Improper Validation of Array Index Development Concepts (primary)699
Research Concepts (primary)1000
ParentOf Weakness Base 134 Uncontrolled Format String Seven Pernicious Kingdoms (primary)700
ParentOf Weakness Base 170 Improper Null Termination Seven Pernicious Kingdoms (primary)700
ParentOf Weakness Base 190 Integer Overflow or Wraparound Seven Pernicious Kingdoms (primary)700
ParentOf Weakness Base 466 Return of Pointer Value Outside of Expected Range Seven Pernicious Kingdoms (primary)700
ParentOf Weakness Base 470 Use of Externally-Controlled Input to Select Classes or Code (aka 'Unsafe Reflection') Development Concepts (primary)699
Seven Pernicious Kingdoms (primary)700
ParentOf Weakness Variant 554 ASP.NET Misconfiguration: Not Using Input Validation Framework Development Concepts (primary)699
Research Concepts (primary)1000
ParentOf Weakness Variant 601 URL Redirection to Untrusted Site (aka 'Open Redirect') Development Concepts (primary)699
ParentOf Weakness Base 606 Unchecked Input for Loop Condition Development Concepts (primary)699
Research Concepts (primary)1000
ParentOf Weakness Base 621 Variable Extraction Error Development Concepts (primary)699
ParentOf Weakness Variant 622 Unvalidated Function Hook Arguments Development Concepts (primary)699
Research Concepts (primary)1000
ParentOf Weakness Variant 626 Null Byte Interaction Error (Poison Null Byte) Development Concepts (primary)699
Research Concepts (primary)1000
ParentOf Compound Element: Chain 680 Integer Overflow to Buffer Overflow Research Concepts (primary)1000
ParentOf Compound Element: Chain 690 Unchecked Return Value to NULL Pointer Dereference Research Concepts (primary)1000
ParentOf Compound Element: Chain 692 Incomplete Blacklist to Cross-Site Scripting Research Concepts (primary)1000
ParentOf Weakness Variant 781 Improper Address Validation in IOCTL with METHOD_NEITHER I/O Control Code Development Concepts (primary)699
Research Concepts (primary)1000
ParentOf Weakness Variant 785 Use of Path Manipulation Function without Maximum-sized Buffer Development Concepts (primary)699
Seven Pernicious Kingdoms (primary)700
ParentOf Weakness Variant 789 Uncontrolled Memory Allocation Research Concepts1000
MemberOf View 635 Weaknesses Used by NVD Weaknesses Used by NVD (primary)635
MemberOf View 700 Seven Pernicious Kingdoms Seven Pernicious Kingdoms (primary)700

 

関係性の補足

構築されるメッセージの特性によっては、適切な入力確認は、特殊文字がメッセージの意味を変化させることを間接的に防ぐため、CWE-116 と近い関係にあります。例えば、数値 ID フィールドは、0-9の文字のみ含まれていることを確認することで、インジェクション攻撃を効果的に防ぐことが可能です。

しかし、自由形式のテキストなど、特にデータの種類を厳しく制限できない場合、入力確認が常に有効であるとは限りません。
クエリに名字を挿入する SQL インジェクションのシナリオを例に挙げます。「O'Reilly」は英語ではよくある名字のため、入力の妥当性の確認を通過するように見えますが、アポストロフィが含まれているため、エスケープ処理や他の処理をする必要があります。この場合、アポストロフィを取り除くことで SQL インジェクションのリスクを減らすことができますが、不正確な名前を登録してしまうため、誤動作を引き起こす可能性があります。.

要調査事項 (CWE の見解)

入力の妥当性チェックの手法や、チェックを行うアプリケーションによる分類の研究はまだ十分ではありません。公表されている脆弱性の多くは、単に「入力の妥当性チェック」の問題とだけ記述され、チェック手法や解消、減少が可能な脆弱性について理解を深められるような詳細情報は提供されていません。妥当性チェックは、フィルタリングや変換による強制等、その他の無効化の手法と対比して、過度に強調されています。vulnerability theory paper を参照してください。

名称補足

「入力の妥当性チェック」という用語は極めて一般的ですが、用語の使い方は様々です。いくつかのケースでは、根本的な脆弱性を曖昧にするためや、関連した複雑な事象を隠すことを目的として使われます。

フィルタリング、正規化やエスケープのような、入力が適切であることを確認する様々な無効化手段をカバーする、総括的な用語としても使用されます。また、もっと狭い文脈において単純に「入力が変化せず、期待される値であることの確認」という意味でも使用されています。CWEではこの狭い文脈の解釈を使用します。

他組織での分類

 

組織名または組織での分類 ノード ID CWEの分類との適合度 分類名
7 Pernicious Kingdoms Input validation and representation
OWASP Top Ten 2004 A1 CWE の方が詳細 Unvalidated Input
CERT C Secure Coding ERR07-C Prefer functions that support error checking over equivalent functions that don't
CERT C Secure Coding INT06-C Use strtol() or a related function to convert a string token to an integer
CERT C Secure Coding MEM10-C Define and use a pointer validation function
CERT C Secure Coding MSC08-C Library functions should validate their parameters
WASC 20 Improper Input Handling

 

関連する攻撃パターン

 

CAPEC-ID 攻撃パターン名 (CAPEC Version 1.5)
3 Using Leading 'Ghost' Character Sequences to Bypass Input Filters
7 Blind SQL Injection
8 Buffer Overflow in an API Call
9 Buffer Overflow in Local Command-Line Utilities
10 Buffer Overflow via Environment Variables
13 Subverting Environment Variable Values
14 Client-side Injection-induced Buffer Overflow
22 Exploiting Trust in Client (aka Make the Client Invisible)
24 Filter Failure through Buffer Overflow
28 Fuzzing
31 Accessing/Intercepting/Modifying HTTP Cookies
42 MIME Conversion
43 Exploiting Multiple Input Interpretation Layers
88 OS Command Injection
45 Buffer Overflow via Symbolic Links
46 Overflow Variables and Tags
47 Buffer Overflow via Parameter Expansion
52 Embedding NULL Bytes
53 Postfix, Null Terminate, and Backslash
101 Server Side Include (SSI) Injection
64 Using Slashes and URL Encoding Combined to Bypass Validation Logic
66 SQL Injection
67 String Format Overflow in syslog()
72 URL Encoding
73 User-Controlled Filename
78 Using Escaped Slashes in Alternate Encoding
79 Using Slashes in Alternate Encoding
99 XML Parser Attack
83 XPath Injection
85 Client Network Footprinting (using AJAX/XSS)
86 Embedding Script (XSS ) in HTTP Headers
32 Embedding Scripts in HTTP Query Strings
18 Embedding Scripts in Nonscript Elements
63 Simple Script Injection
71 Using Unicode Encoding to Bypass Validation Logic
80 Using UTF-8 Encoding to Bypass Validation Logic
81 Web Logs Tampering
91 XSS in IMG Tags
104 Cross Zone Scripting
106 Cross Site Scripting through Log Files
108 Command Line Execution through SQL Injection
109 Object Relational Mapping Injection
110 SQL Injection through SOAP Parameter Tampering
171 Variable Manipulation

 

参照

Jim Manico. "Input Validation with ESAPI - Very Important ". 2008-08-15. <http://manicode.blogspot.com/2008/08/input-validation-with-esapi.html>.
"OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.
Joel Scambray, Mike Shema and Caleb Sima. "Hacking Exposed Web Applications, Second Edition". Input Validation Attacks. McGraw-Hill. 2006-06-05. 
Jeremiah Grossman. "Input validation or output filtering, which is better?". 2007-01-30. <http://jeremiahgrossman.blogspot.com/2007/01/input-validation-or-output-filtering.html>.
Kevin Beaver. "The importance of input validation". 2006-09-06. <http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1214373,00.html>.
[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 10, "All Input Is Evil!" Page 341. 2nd Edition. Microsoft. 2002.

保守補足

入力の妥当性チェックは(欠落あるいは不適切であったとしても)、様々な脆弱性に対するセキュア開発の一部として必要不可欠であり、また広く知られています。伝統的に、バッファオーバーフローや XSS のような問題は、入力の妥当性チェックの問題であるとセキュリティの専門家によって分類されます。しかし、入力の妥当性チェックは、そのような問題において唯一有効な解決策というわけではなく、またある場合には入力の妥当性チェックでは不十分なケースもあります。CWE チームは、ひとまとめにされているこれらの違いを Research Concepts view (CWE-1000) において整理し始めましたが、まだ多くの研究が必要です。

更新履歴

[2021年06月30日]
   2021年06月30日時点のデータを元に、名称補足の掲載位置と内容を変更
[2011年04月21日]
  2010年10月12日時点のデータを元に更新
[2009年06月29日]
  2009年02月02日時点の下記 URL を元に作成
    http://cwe.mitre.org/data/definitions/20.html


登録日 2011/04/21

最終更新日 2023/04/04