- Rules
- Risk Assessment Summary
- IDS00-J. Sanitize untrusted data passed across a trust boundary
- IDS01-J. Normalize strings before validating them
- IDS02-J. Canonicalize path names before validating them
- IDS03-J. Do not log unsanitized user input
- IDS04-J. Limit the size of files passed to ZipInputStream
- IDS05-J. Use a subset of ASCII for file and path names
- IDS06-J. Exclude user input from format strings
- IDS07-J. Do not pass untrusted, unsanitized data to the Runtime.exec() method
- IDS08-J. Sanitize untrusted data passed to a regex
- IDS09-J. Do not use locale-dependent methods on locale-dependent data without specifying the appropriate locale
- IDS10-J. Do not split characters between two data structures
- IDS11-J. Eliminate noncharacter code points before validation
- IDS12-J. Perform lossless conversion of String data between differing character encodings
- IDS13-J. Use compatible encodings on both sides of file or network I/O
This chapter is from the book
This chapter is from the book
This chapter is from the book
IDS06-J. Exclude user input from format strings
Interpretation of Java format strings is stricter than in languages such as C [Seacord 2005]. The standard library implementations throw appropriate exceptions when any conversion argument fails to match the corresponding format specifier. 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 should 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 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, GregorianCalendar.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 ("%s did not match! "
+ " HINT: It was issued on %1$terd of some month", args[0], 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 |
|
IDS06-J |
medium |
unlikely |
medium |
P4 |
L3 |
Automated Detection
Static analysis tools that perform taint analysis can diagnose some violations of this rule.
Related Guidelines
|
CERT C Secure Coding Standard |
FIO30-C. Exclude user input from format strings |
|
CERT C++ Secure Coding Standard |
FIO30-CPP. Exclude user input from format strings |
|
ISO/IEC TR 24772:2010 |
Injection [RST] |
|
MITRE CWE |
CWE-134. Uncontrolled format string |
Bibliography
|
[API 2006] |
Class Formatter |
|
[Seacord 2005] |
Chapter 6, Formatted Output |