解説

解説要約

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

詳細な解説

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

脆弱性の発生時期

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

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

言語

言語に依存

プラットフォームの補足

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

一般的な影響

 

影響を受ける範囲	影響
可用性	予期しない値の入力により、プログラムがクラッシュ、あるいはメモリや 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