Can't resolve Log Forging Fortify issue

Question

I am having trouble fixing a Log Forging issue in Fortify. The issue, "writes unvalidated user input to the log", is being raised from both of the logging calls in the getLongFromTimestamp() method.

public long getLongFromTimestamp(final String value) {
    LOGGER.info("getLongFromTimestamp(" + cleanLogString(value) + ")");

    long longVal = 0;
    Date tempDate = null;
    try {            
        tempDate = new SimpleDateFormat(FORMAT_YYYYMMDDHHMMSS, Locale.US).parse(value);
    } catch (ParseException e) {
        LOGGER.warn("Failed to convert to Date: " + cleanLogString(value) + " Exception: " + cleanLogString(e.getMessage()));
        throw new Exception(e);
    }

    if (tempDate != null) {
        longVal = tempDate.getTime();
    }
    return longVal;
}

private cleanLogString(String logString) {
    String clean = logString.replaceAll("[^A-Za-z0-9]", "");

    if(!logString.equals(clean)) {
        clean += " (CLEANED)";
    }

    return clean;
}

The cleanLogString() method has fixed other Log Forging Fortify issues in my project, however it has no effect on the 2 above.

Any help would be appreciated!

Solution 1

Originally when this question was written our team was using log4j v1.2.8, however we noticed that all the log forging issues disappeared after upgrading to log4j v2.6.2.

Once the log4j version is upgraded the Fortify log forging issues should go away. The cleanLogString() method form the question above is also unnecessary. For example:

LOGGER.info("getLongFromTimestamp(" + value + ")");

Solution 2

It is possible to use fortify Java annotations to tell Fortify that the data returned from a sanitizing function is now safe.

When looking at my log forging problems I had strings coming in through a web API and thus had the flags XSS and WEB on my strings. I tried to find annotations that would only remove these flags, but couldn't find any way to remove the WEB flag. The only documentation I've found is the Samples/advanced/javaAnnotation directory.

Since my sanitation method does sanitize strings, I choose to remove all flags. This could be a problem though, as it could hide privacy violations.

@FortifyValidate("return")
private String sanitizeString(String taintedString) {
    return doSomethingWithTheString(taintedString);
}

Solution 3

I know I have run into situations where the complexity of my application would stop any malicious input from working as intended; Fortify does not consider this to be secure. I bet you are running into the same thing.

You are stripping any really useful characters out of the log message, but see what happens if you do some encoding on the output prior to writing to the log.

http://www.jtmelton.com/2010/09/21/preventing-log-forging-in-java/

// ensure no CRLF injection into logs for forging records
String clean = message.replace( '\n', '_' ).replace( '\r', '_' );
if ( ESAPI.securityConfiguration().getLogEncodingRequired() ) {
    clean = ESAPI.encoder().encodeForHTML(message);
    if (!message.equals(clean)) {
        clean += " (Encoded)";
    }
}