Think Before You Log: Best Practices for Preventing Log Forging Vulnerabilities

Don’t just dump every random thought into the logs. Keep it tidier than a hedgehog’s home! Unless it’s a hedgehog party—then all bets are off.

If there's a bustle in your hedgerow, don't be alarmed now. It's just a spring clean for the May queen...to prevent log forging.

Log forging, not log foraging-though the hedgehog is awfully cute, is a type of log injection (man-in-the-middle) vulnerability.  It can occur when an attacker manipulates a log file by creating a new entry with malicious input into the application log. 

What’s the rationale?  To hide their tracks of unauthorized access or create a false audit trail, for starters.  The data in the log is typically unsanitized user-supplied data, making it easy to access.  You may think our logs don’t contain personally identifiable information (PII), so this is a non-issue, right?  Wrong!  We still have best practices to follow regarding input validation and data sanitization to prevent logging modifications.  These log modifications can involve adding false entries, corrupting existing logs, using existing logs to trigger remote code execution, and even leading to security breaches.  Let’s learn more about log forging. 

What happens during a log forging attack? 

Log-forging attacks are brutal to detect because they appear to be unaltered logs.  An attacker can successfully forge a log entry, which can then escalate the user's application privileges.  There are a few ways they can forge log entries, such as SQL injection, file injection, brute-force password guessing, and session fixation.  They take advantage of the fact that logs are not routinely monitored and applications that do not properly sanitize user input before logging.   

• They’ll insert malicious data into log entries 

• This data can corrupt the log file format 

• They’ll cover their tracks, modifying or deleting their log entry 

Some of the main reasons they are just plain nefarious:  

• Identity theft 

• Security breaches 

• Financial loss 

• Information leakage 

• Lead users to fake login pages (gaining credentials and then having access to your applications) 

• Point the blame at others for the tampering of data 

• Data integrity/tampering (might not be able to analyze the log if it was corrupted) 

• System performance/instability/unavailability 

• System takeover! (Log4Shell, Log4j) 

• Injection of XSS attacks, hoping that the malicious log event is viewed in a vulnerable web application 

How do we prevent a log injection/forging attack?   

• Use a secure logging library/framework 

• Limit access to the logs 

• Back up the logs! 

• Review log files regularly (you can do this manually or with an automated tool) 

• Input validation and data sanitization (more on that below) on all input before logging  

• Implement server-side validation 

• Parameterized queries 

• Use of prepared statements or parameterized queries for database interactions can prevent SQL injections 

• Output encoding 

• Prevent XSS attacks by encoding special characters in user-generated content before display 

• Limit Logged Data 

• Avoid logging sensitive information in the first place! (Just say no to logging passwords, credit card numbers, account numbers, or personally identifiable information (PII) or a series of that information that equals PII

• Keep all software and logging libraries up to date with the latest and greatest security patches  

As promised, here’s more information on input validation and data sanitization.   

• Sanitization before validation: 

  • Removing or replacing potentially malicious characters from user input before it’s added to a log entry 

• Ensuring sensitive data has been properly escaped or encrypted 

• Allowlisting for validation and data type validation: 

  • Defining expected characters, data types, or patterns for input fields in the application 

• Ensure that the input matches the expected data type and length 

• Validate!  Validation checks; sanitize modifies 

  • To validate is to make sure that the input matches your business rules.  If it doesn’t, you reject the input.   

  • For example, you might expect the user to provide a number, but if you receive something that’s not a number, that is a validation error. 

• Checks for things like required fields, data types, length restrictions, and valid formats.  (e.g., email, date, age) 

  • Example, check if the user’s email address allows standard format

    (example@example.com or the age is limited to no more than three integers) 

• Sanitize!  Sanitize modifies; validation checks 

  • Meanwhile, sanitizing ensures the input format doesn’t break its container.  This could be a semicolon (;) mistakenly added by the user, so you remove/escape it for the user when it's sent.   

• Sanitization is also used to prevent attempts to cause data corruption when dealing with a database that relies on user input. 

• Clean data and prepare user input for use, removing or escaping potentially harmful elements. 

• Removes unwanted characters, escapes special characters (e.g., < to &lt;, > to &gt;), or converts data to a safer format. 

So there you have it.  Log foraging, I mean log forging.  Cute, little hedgehogs.  Not so cute vulnerabilities. 

Bonus fun fact about Jen, I used to raise hedgehogs and run a rescue shelter in the late 90’s/ early 00’s.  Below is a picture of a professional photo shoot for my show Hog and Her Winning Ribbon.  Very cool pets!