CWE-472: External Control of Assumed-Immutable Web Parameter
External Control of Assumed-Immutable Web Parameter
Weakness ID: 472 (Weakness Base)
Status: Draft
Description
Description Summary
The web application does not sufficiently verify inputs that
are assumed to be immutable but are actually externally controllable, such as
hidden form fields.
Extended Description
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. Failure to validate portions 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.
Alternate Terms
Assumed-Immutable Parameter Tampering
Time of Introduction
Implementation
Applicable Platforms
Languages
All
Common Consequences
Scope
Effect
Integrity
Without appropriate protection mechanisms, the client can easily
tamper with cookies and similar web data. Reliance on the cookies
without detailed validation can lead to problems such as SQL injection.
If you use cookie values for security related decisions on the server
side, manipulating the cookies might lead to violations of security
policies such as authentication bypassing, user impersonation and
privilege escalation. In addition, storing sensitive data in the cookie
without appropriate protection can also lead to disclosure of sensitive
user data, especially data stored in persistent cookies.
Demonstrative Examples
Example 1
Here, a web application uses the value of a hidden form field
(accountID) without having done any input validation because it was assumed
to be immutable.
User user = getUserFromID(Long.parseLong(accountID));
Example 2
Hidden fields should not be trusted as secure parameters. An attacker
can intercept and alter hidden fields in a post to the server as easily
as user input fields. An attacker can simply parse the HTML for the
substring:
< input type "hidden"
or even just "hidden". Hidden field values displayed later in the
session, such as on the following page, can open a site up to cross-site
scripting attacks.
Modification of message number parameter allows
attackers to read other people's messages.
Potential Mitigations
Phase
Description
Architecture and Design
Assume all input is malicious. Use a standard input validation
mechanism to validate all input for length, type, syntax, and business
rules before accepting the data to be displayed or stored. Use an
"accept known good" validation strategy. Input (specifically, unexpected
CRLFs) that is not appropriate should not be processed into HTTP
headers.
Use and specify a strong input/output encoding (such as ISO 8859-1 or
UTF 8).
Do not rely exclusively on blacklist validation to detect malicious
input or to encode output. There are too many variants to encode a
character; you're likely to miss some variants.
Inputs should be decoded and canonicalized to the application's
current internal representation before being validated. Make sure that
your application does not decode the same input twice. Such errors could
be used to bypass whitelist schemes by introducing dangerous inputs
after they have been checked.
Description
