Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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>

...