CWE一覧に戻る
CWE-472

想定-不変ウェブ・パラメータの外部制御

External Control of Assumed-Immutable Web Parameter
脆弱性 レビュー中
JA

ウェブアプリケーションは、隠しフォームフィールドのように、不変であると想定されながら実際には外部から制御可能な入力を十分に検証していない。

ウェブ製品が、隠されたフォームフィールド、パラメータ、クッキー、URL において、想定された不変値を改ざんから適切に保護しない場合、重要なデータの改ざんにつながる可能性があります。ウェブ・アプリケーションはしばしば、隠されたフィールドやクッキーでクライアントに渡されたデータは改ざんされにくいと誤解しています。ユーザが制御可能なデータの妥当性確認が不適切だと、アプリケーションは不正な、そしてしばしば悪意のある入力を処理 することになります。

例えば、カスタム・クッキーは一般にセッション・データやセッションをまたがる永続的なデータを保存します。この種のセッションデータは通常、ユーザ認証やアクセス制御のようなサーバ側のセキュリティ関連の決定に関与します。従って、クッキーはユーザ認証情報や 権限のような機密データを含むかもしれません。これは、サーバ側のアプリケーションがクライアントから提供されたクッキーの値に不適切に依存することになりがちなので、危険な慣行です。

EN

The web application does not sufficiently verify inputs that are assumed to be immutable but are actually externally controllable, such as hidden form fields.

If a web product does not properly protect assumed-immutable values from modification in hidden form fields, parameters, cookies, or URLs, this can lead to modification of critical data. Web applications often mistakenly make the assumption that data passed to the client in hidden fields or cookies is not susceptible to tampering. Improper validation of data that are user-controllable can lead to the application processing incorrect, and often malicious, input.

For example, custom cookies commonly store session data or persistent data across sessions. This kind of session data is normally involved in security related decisions on the server side, such as user authentication and access control. Thus, the cookies might contain sensitive data such as user credentials and privileges. This is a dangerous practice, as it can often lead to improper reliance on the value of the client-provided cookie by the server side application.

Scope: Integrity / Impact: Modify Application Data
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."

Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
MITRE公式ページ — CWE-472