533
CanAlsoBe 390 Detection of Error Condition Without Action 943
Weakness Ordinalities
Resultant :
Applicable Platforms
Language : Not Language-Specific (Prevalence = Undetermined)
Common Consequences
Scope Impact Likelihood
Confidentiality
Integrity
Availability
Read Application Data
Execute Unauthorized Code or Commands
Potential Mitigations
Phase: Implementation
Do not write user-controlled input to error pages.
Phase: Implementation
Carefully check each input parameter against a rigorous positive specification (allowlist) defining
the specific characters and format allowed. All input should be neutralized, not just parameters
that the user is supposed to specify, but all data in the request, including hidden fields,
cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS
vulnerabilities is to validate only fields that are expected to be redisplayed by the site. We often
encounter data from the request that is reflected by the application server or the application that
the development team did not anticipate. Also, a field that is not currently reflected may be used
by a future developer. Therefore, validating ALL parts of the HTTP request is recommended.
Phase: Implementation
Strategy = Output Encoding
Use and specify an output encoding that can be handled by the downstream component that
is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an
encoding is not specified, a downstream component may choose a different encoding, either
CWE Version 4.14
CWE-81: Improper Neutralization of Script in an Error Message Web Page
CWE-81: Improper Neutralization of Script in an Error Message Web Page