Interpretation of Java format strings is stricter than that in languages such as C. The implementations in the standard libraries throw appropriate exceptions when any conversion argument fails to match the corresponding flag. This approach reduces opportunities for malicious exploits. Nevertheless, malicious user input can exploit format strings and can cause information leaks or denial of service. As a result, strings from an untrusted source shall not be incorporated into format strings.
Noncompliant Code Example
This noncompliant code example demonstrates an information leak issue. It accepts a credit card expiration date as an input argument and uses it within the format string.
class Format { static Calendar c = new GregorianCalendar(1995, GregorianCalendar.MAY, 23); public static void main(String[] args) { // args[0] is the credit card expiration date // args[0] can contain either %1$tm, %1$te or %1$tY as malicious arguments // First argument prints 05 (May), second prints 23 (day) and third prints 1995 (year) // Perform comparison with c, if it doesn't match print the following line System.out.printf(args[0] + " did not match! HINT: It was issued on %1$terd of some month", c); } }
In the absence of proper input validation, an attacker can determine the date against which the input is being verified, perhaps by supplying an input that includes one of the format string arguments %1$tm
, %1$te
, or %1$tY
.
Compliant Solution
This compliant solution ensures that user generated input is excluded from format strings.
class Format { static Calendar c = new GregorianCalendar(1995, MAY, 23); public static void main(String[] args) { // args[0] is the credit card expiration date // Perform comparison with c, if it doesn't match print the following line System.out.printf("The input did not match! HINT: It was issued on %1$terd of some month", c); } }
Risk Assessment
Allowing user input to taint a format string may cause information leaks or denial of service.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
IDS09-J |
medium |
unlikely |
medium |
P4 |
L3 |
Automated Detection
Static analysis tools that perform taint analysis can diagnose some violations of this rule.
Other Languages
This rule appears in the C Secure Coding Standard as FIO30-C. Exclude user input from format strings.
This rule appears in the C++ Secure Coding Standard as FIO30-CPP. Exclude user input from format strings.
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="897045f2-466a-4e8e-bd9a-36766c28da4e"><ac:plain-text-body><![CDATA[ |
[[MITRE 2009 |
AA. Bibliography#MITRE 09]] |
[CWE-134 |
http://cwe.mitre.org/data/definitions/134.html] "Uncontrolled Format String" |
]]></ac:plain-text-body></ac:structured-macro> |
Bibliography
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="2e87ea21-ac3e-44d0-9d82-6b8cc7eb69e6"><ac:plain-text-body><![CDATA[ |
[[API 2006 |
AA. Bibliography#API 06]] |
[Class Formatter |
http://java.sun.com/javase/6/docs/api/java/util/Formatter.html] |
]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="d8ea8762-eb16-4009-a548-53fa268cc80d"><ac:plain-text-body><![CDATA[ |
[[Seacord 2005 |
AA. Bibliography#Seacord 05]] |
Chapter 6, Formatted Output |
]]></ac:plain-text-body></ac:structured-macro> |
IDS08-J. Sanitize untrusted data passed to a regex IDS10-J. Do not assume every character in a string is the same size