Description
This weakness has been deprecated because it was a duplicate of CWE-493. All content has been transferred to CWE-493.
Modes of Introduction:
Related Weaknesses
Consequences
This weakness has been deprecated because it was a duplicate of CWE-493. All content has been transferred to CWE-493.
Modes of Introduction:
The application stores sensitive data under the web document root with insufficient access control, which might make it accessible to untrusted parties.
Besides public-facing web pages and code, applications may store sensitive data, code that is not directly invoked, or other files under the web document root of the web server. If the server is not configured or otherwise used to prevent direct access to those files, then attackers may obtain this sensitive data.
Modes of Introduction:
– Operation
Confidentiality: Read Application Data
Phase: Implementation, System Configuration
Description:
Avoid storing information under the web root directory.
Phase: System Configuration
Description:
Access control permissions should be set to prevent reading/writing of sensitive files inside/outside of the web directory.
The software validates input before applying protection mechanisms that modify the input, which could allow an attacker to bypass the validation via dangerous inputs that only arise after the modification.
Software needs to validate data at the proper time, after data has been canonicalized and cleansed. Early validation is susceptible to various manipulations that result in dangerous inputs that are produced by canonicalization and cleansing.
Modes of Introduction:
– Implementation
Access Control, Integrity: Bypass Protection Mechanism, Execute Unauthorized Code or Commands
An attacker could include dangerous input that bypasses validation protection mechanisms which can be used to launch various attacks including injection attacks, execute arbitrary code or cause other unintended behavior.
Phase: Implementation
Description:
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.
The software validates input before it is canonicalized, which prevents the software from detecting data that becomes invalid after the canonicalization step.
This can be used by an attacker to bypass the validation and launch attacks that expose weaknesses that would otherwise be prevented, such as injection.
Modes of Introduction:
– Implementation
Access Control: Bypass Protection Mechanism
Phase: Implementation
Description:
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.
The software validates data before it has been filtered, which prevents the software from detecting data that becomes invalid after the filtering step.
This can be used by an attacker to bypass the validation and launch attacks that expose weaknesses that would otherwise be prevented, such as injection.
Modes of Introduction:
– Implementation
Access Control: Bypass Protection Mechanism
Phase: Implementation, Architecture and Design
Description:
Inputs should be decoded and canonicalized to the application’s current internal representation before being filtered.
The software filters data in a way that causes it to be reduced or “collapsed” into an unsafe value that violates an expected security property.
Modes of Introduction:
– Implementation
Access Control: Bypass Protection Mechanism
Phase: Architecture and Design
Description:
Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.
Phase: Implementation
Description:
Phase: Implementation
Description:
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.
Phase:
Description:
Canonicalize the name to match that of the file system’s representation of the name. This can sometimes be achieved with an available API (e.g. in Win32 the GetFullPathName function).
The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are explicitly allowed by policy because the inputs are assumed to be safe, but the list is too permissive – that is, it allows an input that is unsafe, leading to resultant weaknesses.
Modes of Introduction:
– Implementation
Access Control: Bypass Protection Mechanism
The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are not allowed by policy or otherwise require other action to neutralize before additional processing takes place, but the list is incomplete, leading to resultant weaknesses.
Developers often try to protect their products against malicious input by performing tests against inputs that are known to be bad, such as special characters that can invoke new commands. However, such lists often only account for the most well-known bad inputs. Attackers may be able to find other malicious inputs that were not expected by the developer, allowing them to bypass the intended protection mechanism.
Modes of Introduction:
– Implementation
CWE-693
CWE-1023
CWE-79
CWE-78
CWE-434
CWE-98
Access Control: Bypass Protection Mechanism
Phase: Implementation
Description:
Do not rely exclusively on detecting disallowed inputs. There are too many variants to encode a character, especially when different environments are used, so there is a high likelihood of missing some variants. Only use detection of disallowed inputs as a mechanism for detecting suspicious activity. Ensure that you are using other protection mechanisms that only identify “good” input – such as lists of allowed inputs – and ensure that you are properly encoding your outputs.
The software specifies a regular expression in a way that causes data to be improperly matched or compared.
When the regular expression is used in protection mechanisms such as filtering or validation, this may allow an attacker to bypass the intended restrictions on the incoming data.
Modes of Introduction:
– Implementation
Other: Unexpected State, Varies by Context
When the regular expression is not correctly specified, data might have a different format or type than the rest of the program expects, producing resultant weaknesses or errors.
Access Control: Bypass Protection Mechanism
In PHP, regular expression checks can sometimes be bypassed with a null byte, leading to any number of weaknesses.
Phase: Architecture and Design
Description:
Regular expressions can become error prone when defining a complex language even for those experienced in writing grammars. Determine if several smaller regular expressions simplify one large regular expression. Also, subject the regular expression to thorough testing techniques such as equivalence partitioning, boundary value analysis, and robustness. After testing and a reasonable confidence level is achieved, a regular expression may not be foolproof. If an exploit is allowed to slip through, then record the exploit and refactor the regular expression.
A regular expression is overly restrictive, which prevents dangerous values from being detected.
This weakness is not about regular expression complexity. Rather, it is about a regular expression that does not match all values that are intended. Consider the use of a regexp to identify acceptable values or to spot unwanted terms. An overly restrictive regexp misses some potentially security-relevant values leading to either false positives *or* false negatives, depending on how the regexp is being used within the code. Consider the expression /[0-8]/ where the intention was /[0-9]/. This expression is not “complex” but the value “9” is not matched when maybe the programmer planned to check for it.
Modes of Introduction:
– Implementation
Access Control: Bypass Protection Mechanism
Phase: Implementation
Description:
Regular expressions can become error prone when defining a complex language even for those experienced in writing grammars. Determine if several smaller regular expressions simplify one large regular expression. Also, subject your regular expression to thorough testing techniques such as equivalence partitioning, boundary value analysis, and robustness. After testing and a reasonable confidence level is achieved, a regular expression may not be foolproof. If an exploit is allowed to slip through, then record the exploit and refactor your regular expression.