...
Untrusted input shall be sanitized before use to prevent regex injection. When the user must specify a regex as input, care must be taken to ensure that the original regex cannot be modified without restriction. Whitelisting characters (such as letters and digits) before delivering the user supplied string to the regex parser is a good input sanitization strategy. A programmer must provide only a very limited subset of regular expression functionality to the user to minimize any chance of misuse.
Regex Injection Example
Suppose a system log file contains messages output by various system processes. Some processes produce public messages and some processes produce sensitive messages marked 'private'. Here is an example log file:
...
This regex will match any line in the log file, including the private ones.
Noncompliant Code Example
This noncompliant code example periodically loads the log file into memory and allows clients to obtain keyword search suggestions by passing the keyword as an argument to suggestSearches()
.
...
This code permits a trusted user to search for public log messages such as "error". However, it also allows a malicious attacker to perform the regex injection outlined above.
Compliant Solution (Whitelisting)
This compliant solution filters out non-alphanumeric characters (except space and single quote) from the search string, which prevents regex injection.
...
This solution also limits the set of valid search terms. For instance, a user may no longer search for "name ="
because the =
character would be sanitized out of the regex.
Compliant Solution
Another method of mitigating this vulnerability is to filter out the sensitive information prior to matching. Such a solution would require the filtering to be done every time the log file is periodically refreshed, incurring extra complexity and a performance penalty. Sensitive information may be still exposed if the log format changes but the class is not also refactored to accommodate these changes.
Risk Assessment
Violating this rule may result in the disclosure of sensitive information.
Rule | Severity | Liklihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
IDS19-J | medium | unlikely | medium | P4 | L3 |
Related Guidelines
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="c412d1c217d32e1b-5b3dd89d-4bfd4262-bee9a86b-fb9818e36ba09005282c7bb7"><ac:plain-text-body><![CDATA[ | [[MITRE 09 | AA. Bibliography#MITRE 09]] | [CWE ID 625 | http://cwe.mitre.org/data/definitions/625.html] "Permissive Regular Expression" | ]]></ac:plain-text-body></ac:structured-macro> |
Bibliography
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="4a08adaa31d00be9-47020b42-48754f36-b6a391a7-9d56c9812fbc2362727bec24"><ac:plain-text-body><![CDATA[ | [[Tutorials 08 | AA. Bibliography#Tutorials 08]] | [Regular Expressions | http://java.sun.com/docs/books/tutorial/essential/regex/index.html] | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="e524ab519076bd0f-50a3ce8e-46bf40e5-9e0f9514-0097c779368cb3f5a4a88d77"><ac:plain-text-body><![CDATA[ | [[CVE 05 | AA. Bibliography#CVE]] | [CVE-2005-1949 | http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1949] | ]]></ac:plain-text-body></ac:structured-macro> |
...