12

What is the best way to protect against Log Injection attacks in PHP ? Of course, we should sanitize input, but the question is how, and what has to be sanitized ?

For example, if I am logging something that can come from the user, first step would be to make sure that what he enters, do not cause some problems in the OS, or strange behaviours of the application. Then, if we display log entries somewhere in the application, we need to make sure that XSS and similar attacks are not possible.

I am looking at PHP sanitize filters as a possible solution, but I do not really know what should I filter out. What characters can be dangerous ?

offline
  • 1,589
  • 1
  • 21
  • 42
  • 1
    have you tried going through `https://www.loggly.com/docs/php-logging-php-syslog-management/` this url – dhpratik Mar 14 '19 at 13:20
  • @dhpratik I did not, but I got the idea to see what Monolog does. But I can not find the place where they write to log file, and if they sanitize the input somehow :( – offline Mar 14 '19 at 18:28
  • I have debugged the Monolog in searching for answers, and it seems like they are not doing any real protection / sanitization... Interesting... – offline Mar 14 '19 at 19:34
  • What potential problems do you anticipate? How do you think your logs could be exploited to for malicious purposes? – Dharman Mar 14 '19 at 20:44
  • Like this: https://affinity-it-security.com/what-is-log-injection/ – offline Mar 14 '19 at 20:47

3 Answers3

12

This is my opinion on the matter, I like keeping my logs as unfiltered as possible, I never filter the input except for new lines to make sure there's one line per log entry.

You need to make sure of the following:

  • Never use include, require or eval to display your log file contents; read the file(s) using fopen or file & print out the contents.
  • filter the output before displaying it, something like htmlentites that changes quotes & html open/closing tags would be good.
  • if you can display the output in a text area, the browser will display the data without executing the scripts if there's any xss or otherwise malicious code present.
  • make sure you store your log file in a folder that's not publicly/web accessible & remove the execute permissions for user/group and all permissions for 'others'.
  • Final suggestion: try to hack your logs to make sure you covered all bases and while you are at it use a fuzzer to test for automated attacks.
ahmad
  • 2,709
  • 1
  • 23
  • 27
2

The log file alone is not the problem. Just having a file, and be it a binary with a virus in it, is not dangerous at all as long as it is not executed! The same is true for log files: As long as its contents does not trigger any code and misuse it in a way, it is no problem.

As @ahmad already mentioned it becomes a problem if you use something like eval to display your log file, because that can very well execute code and some dollar sign may allow an attacker to do much more than cross site scripting alone.

But is fopen necessarily any better? No! Because examples from the past have impressively shown it. One may think that cat is a safe way to display text on the console, but even that turned out to be wrong and if even the simplest tool to print some text out is broken, you should not trust in anything, right?

In most cases it is not your software alone, which makes something dangerous. It is often the combination with other software, which may be out of your control. Consider for example, that you are not able to inspect every line of code in your newest system updates for potential side effects with your software.

Or let us assume, that you do not have your own server, but you are customer of a web service provider, who takes care for the system configuration as well. Let us further assume, that this service provider cares for security and has some kind of intrusion detection installed, like for example fail2ban. This may all work really well until you introduce your program into the service providers environment (the other way round) and potentially allows an attacker to break fail2ban with something very regex unfriendly to occupy the system as part of a denial of service attack (just guessing here, but the point gets clear, I hope).

MaxC
  • 540
  • 5
  • 14
1

While storing or displaying user input always insure to filter HTML tags like <script> which may execute external javascript code on your site may lead to session/cookie stealing.

Also filter tags like <style> which might not cause any harm but can disturb your website layout.

Use regular expressions to validate input where there is no inbuilt functions for validation.

SachinPatil4991
  • 774
  • 6
  • 13