Incorrect Regular Expression |
Weakness ID: 185 (Weakness Class) | Status: Draft |
Description Summary
Scope | Effect |
---|---|
Integrity | In PHP, regular expression checks can sometimes be bypassed with a null byte, leading to any number of weaknesses. |
Reference | Description |
---|---|
CVE-2002-2109 | Regexp isn't "anchored" to the beginning or end, which allows spoofed values that have trusted values as substrings. |
CVE-2005-1949 | Regexp for IP address isn't anchored at the end, allowing appending of shell metacharacters. |
CVE-2001-1072 | Bypass access restrictions via multiple leading slash, which causes a regular expression to fail. |
CVE-2000-0115 | Local user DoS via invalid regular expressions. |
CVE-2002-1527 | Error infoleak via malformed input that generates a regular expression error. |
CVE-2005-1061 | Certain strings are later used in a regexp, leading to a resultant crash. |
CVE-2005-2169 | MFV. Regular expression intended to protect against directory traversal reduces ".../...//" to "../". |
CVE-2005-0603 | Malformed regexp syntax leads to error infoleak. |
CVE-2005-1820 | Code injection due to improper quoting of regular expression. |
CVE-2005-3153 | Null byte bypasses PHP regexp check. |
CVE-2005-4155 | Null byte bypasses PHP regexp check. |
Regular expressions can become error prone when defining a complex language even for those experienced in writing grammars. Determine if several smaller regular expressions simplifies 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 full proof. If an exploit is allowed to slip through, then record the exploit and refactor your regular expression. |
Keywords: regexp This can seem to overlap whitelist/blacklist problems, but it is intended to deal with improperly written regular expressions, regardless of the values that those regular expressions use. While whitelists and blacklists are often implemented using regular expressions, they can be implemented using other mechanisms as well. |
Nature | Type | ID | Name | View(s) this relationship pertains to![]() |
---|---|---|---|---|
ChildOf | ![]() | 171 | Cleansing, Canonicalization, and Comparison Errors | Development Concepts (primary)699 |
ChildOf | ![]() | 697 | Insufficient Comparison | Research Concepts (primary)1000 |
CanPrecede | ![]() | 182 | Collapse of Data Into Unsafe Value | Research Concepts1000 |
CanPrecede | ![]() | 187 | Partial Comparison | Research Concepts1000 |
ParentOf | ![]() | 186 | Overly Restrictive Regular Expression | Development Concepts (primary)699 Research Concepts (primary)1000 |
ParentOf | ![]() | 625 | Permissive Regular Expression | Development Concepts (primary)699 Research Concepts (primary)1000 |
Regexp errors are likely a primary factor in many MFVs, especially those that require multiple manipulations to exploit. However, they are rarely diagnosed at this level of detail. |
[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 10, "Using Regular Expressions for Checking Input" Page 350. 2nd Edition. Microsoft. 2002. |
Submissions | ||||
---|---|---|---|---|
Submission Date | Submitter | Organization | Source | |
PLOVER | Externally Mined | |||
Modifications | ||||
Modification Date | Modifier | Organization | Source | |
2008-07-01 | Eric Dalci | Cigital | External | |
updated Time of Introduction | ||||
2008-09-08 | CWE Content Team | MITRE | Internal | |
updated Description, Name, Relationships, Observed Example, Other Notes, Taxonomy Mappings | ||||
2009-12-28 | CWE Content Team | MITRE | Internal | |
updated Common Consequences, Other Notes | ||||
Previous Entry Names | ||||
Change Date | Previous Entry Name | |||
2008-09-09 | Regular Expression Error | |||