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. 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 improperreliance 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
Technical Impact: Modify application
data
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:
(Bad Code)
Example
Language: HTML
< 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: Implementation
Strategy: Input Validation
Assume all input is malicious. Use an "accept known good" input
validation strategy, i.e., use a whitelist 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
(i.e., do not rely on a blacklist). A blacklist 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, blacklists can be useful for detecting potential
attacks or determining which inputs are so malformed that they should be
rejected outright.
Phase: Implementation
Strategy: Input Validation
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 whitelist validation schemes by introducing dangerous inputs after they have been checked.
[REF-17] Michael Howard, David LeBlanc
and John Viega. "24 Deadly Sins of Software Security". "Sin 4: Use of Magic URLs, Predictable Cookies, and Hidden
Form Fields." Page 75. McGraw-Hill. 2010.
[REF-7] Mark Dowd, John McDonald
and Justin Schuh. "The Art of Software Security Assessment". Chapter 17, "Embedding State in HTML and URLs", Page
1032.. 1st Edition. Addison Wesley. 2006.
Description
