Path Traversal from URI on "/favicon.ico" page

[sourabhkatti]

Trace UUID: 6C4D-0RJJ-PXU1-U8CO

https://apptwo.contrastsecurity.com/Contrast/static/ng/index.html#/f7ea7169-d4eb-42c4-b32e-5c0ea0ca9733/vulns/6C4D-0RJJ-PXU1-U8CO/overview

Description

We tracked the following data from URI:

GET /favicon.ico

...which was accessed within the following code:

com.comcast.xsp.logging.core.filter.LoggingFilter#doFilterInternal(), line 54

...and ended up being used as part of the path in the following file being opened:

favicon.ico

Risk

Because there is untrusted data being used as part of the file path, it may be possible for an attacker to read sensitive data or write malicious data to the container's file system.

Recommendation to fix this finding

The application opens up a java.io.File or file I/O stream based on user input. Although it's not directly clear how that file is being used, this functionality could be an avenue for path traversal abuse.

Here's an example of a typical path traversal vulnerability:

String statement = request.getParameter("statement");
if(!statement.endsWith(".xml")) { // Validate (weakly) this file is an xml file
   logger.error("Bad filename sent");
   return;
}
// Read the specified file
File file = new File(STATEMENT_DIR, statement);
FileInputStream fis = new FileInputStream(file);
byte[] fileBytes = new byte[file.length()];
fis.read(fileBytes);
response.getOutputStream().write(fileBytes);

Often, there is no filename validation at all. Either way, an attacker could abuse this functionality to view the /etc/passwd file on a UNIX system by passing the following value for the statement parameter:

http://yoursite.com/app/pathTraversal?statement=../../../../../../../../etc/passwd%00.xml

The NULL byte (%00) is just another char to Java, so the malicious value passes the endsWith() check. However, when the value is passed to the operating system's native API, the NULL byte will represent an end-of-string character, and open the attacker's intended file.
Note that Null byte injection in Java was fixed in Java 7 Update 45. So, make sure you are using at least this version of Java, in addition to validating the user's input to this File accessor code.

To prevent attacks like this, any of the following steps could help:

• Use maps to filter out invalid values. Instead of accepting input like file=string, accept file=int. That int can be a key in a Map that points to an allowed file. If the map has no corresponding value for the key given, then throw an error.`
• Strongly validate the file value. Validate the file using a whitelist or regular expression:

Pattern p = Pattern.compile("^[A-Za-z0-9]+\\.xml$");
String statement = request.getParameter("statement");
/* Validate the statement to prevent access to anything but XML files */
if( !p.matcher(statement).matches() ) {
    response.sendError(404);
    return;
}
// Read the file here as normal

`