Fortify Log Forging Issue

N. Kaufman picture N. Kaufman · Mar 14, 2015 · Viewed 7.6k times · Source

We are scanning our .NET application with Fortify and need to provide some information on why Log Forging issue does not apply to us. In our code we have the following pattern, of course it is not exactly as is, I've captured the essence of what we're doing:

public static void Write(object message, 
            ICollection<string> categories, int priority, 
            int eventId, TraceEventType severity, string title, 
            IDictionary<string, object> properties)
{

        LogEntry log = new LogEntry();
        string MessageToAdd = message.ToString();

        if (message.ToString().Length > MaxLength)
            log.Message = message.ToString().Substring(0, MaxLength);
        else
            log.Message = message.ToString();

        log.Categories = categories;
        log.Priority = priority;
        log.EventId = eventId;
        log.Severity = severity;
        log.Title = title;
        log.ExtendedProperties = properties;
        Logwriter Logger;
        Logger.Write(log);
}

So basically, we control how log entry objects are created. We restrict the message or user input to 100 characters. Hence we think that Log Forging raised by Fortify is a False Positive.

What do you all think?

Answer

Eric picture Eric · Mar 18, 2015

Any message that is created by your code will be safe, but Fortify is flagging this because user input is being logged there. You will want to do more than limit the size of the input if you're allowing user data into the log. At least make sure there are no carriage returns or line feeds in the data so they can't spoof log messages. If the log can be viewed in a browser, you will also want to HTML encode the message. Check this file out:

https://owasp-esapi-dotnet.googlecode.com/svn/trunk/Esapi/Logger.cs

The OWASP ESAPI for .NET is pretty outdated, but this logger can show you a good way to look for the above use cases before putting the data in the log.