1

I have generated a Fortify report for my application. In a Fortify report it is showing Log forging issues in the below code:

holDate = ((MaintainHolidayCalenderForm) form).getCALENDER_DATE();
logger.info("This is some description" + holDate + holName );

and as per some people's suggestions I have replaced the "/n" with "" and "/r" with "" but still the issue is not resolved.

Can any one tell me how to resolve this?

Thanks in advance.

Svetlin Zarev
  • 14,713
  • 4
  • 53
  • 82
navi1401
  • 21
  • 1
  • 4

1 Answers1

3

A blacklist fix, e.g. stripping out the log clearing characters (/n /r), still leaves an opportunity for an attacker to do malicious things with your application. If the holDate and holName are submitted from the browser they are UTF-8 strings, which can be very long and have any characters in the rather large UTF-8 unicode character set. If the log is usually viewed with an HTML viewer (common) an example attack might go like this: the attacker could forge a record that shows that they logged out, do their bad stuff, then write a log message that overwrites that activity using any of the unicode characters that cause backspaces or dels back to the 'friendly attacker logged out - nothing to see here' message. (Note: you should never try to predict how an attacker might affect bad things so don't try to blacklist all of the ways to get backspace characters in unicode.)

Rather than blacklisting, you should ensure that the data you're writing to the log is the type you expect, also known as whitelist validation, and of a reasonable length.

So the fix (in the code that you posted): 1. Make sure holDate is a Date object (java.util.Date) if it isn't already.
2. HolName is probably an alphanumeric string of a relatively small length. Choose a small length (like 30 characters) and make sure that only alphanumeric characters are accepted in the holName.
You can use a regex String.matches("^[a-zA-Z0-9]*$") after checking length to ensure that you're only accepting alphanumeric characters.

You should probably do this whitelist input validation in the setters for the form pojos.

David Harvey CISSP
  • 134
  • 4