Do LAMP log files sometimes contain sensitive information?

Question

I will have a LAMP web server with CentOS and cPanel. With this setup, is it possible for any server log files, whether regular or error logs, to contain sensitive information in them, such as passwords or url variables (GET data)?

What I'm trying to avoid is having sensitive information stored in a plain text log file.

If the server does do this, how do I stop this? Is it a good idea to do so for security?

Answer 1

Yes, it's possible it may contain sensitive information. A lot depends on what you consider 'sensitive'. That the IP address 123.123.123.123 access www.hotpron.xxx at 7pm on Sunday contains no user identifiable information but might be extremely sensitive to someone.

The normal logging provided by Apache will only record

• GET variables
• any cookies you explicitly include in the log format

It will also record usernames used for authentication by the webserver (rather than the code itself) via the mod_auth add ons. Again this is configurable.

And the error log will contain anything your application chooses to write to it.

It's possible to get it to log POST variables as well using (e.g.) mod_security - but this is more involved.

Generally most people would consider it very bad practice to pass authentication tokens (usernames, passwords, session identifiers) via GET variables.

Answer 2

First, I would do my best to try to not log sensitive information outside of the (protected/encrypted) database. This can typically be accomplished by

• Not using http GET to send passwords/other sensitive information (e.g., credit card #s) to your site. E.g., by clicking a button that goes to a URL like https://www.example.com/login?user=admin&password=dumb_password that then forwards you to the site as a logged in user. Most web servers (apache) default configuration will log this GET request with the parameters in cleartext. Use POST (so its not plaintext logged) and do it over HTTPS (to prevent network eavesdropping) with properly signed certificates (to prevent Man in the Middle attacks).

• Not logging the contents of http POST (unless you are debugging something during development). This is usually not done by default.

• Not logging the contents of session cookies or allow reuse of one-time tokens (e.g., from password resets) that may be logged.

Still sensitive information can inadvertantly get into your log files. A common example is user authentication via ssh. Every now and then a user will be in a rush to login and type their password in the (logged) username field press enter, and their password will be logged in the user field secure.log (or auth.log in some linux flavors). So its best to prevent non-root users from being able to read these log files in the standard way. (That is standard file access controls with chmod, chown, chgrp, and with full disk encryption if you are worried about someone removing the hard disk or booting into single user mode).

Finally, have a look at your log files and see what you are logging. Search (grep) through them and make sure nothing shows up in plaintext that shouldn't be logged (e.g., create a fake account with fake confidential information go through the full process and see if you can find any part of the fake information). I say a fake account, because searching for real confidential information may put that information in a different log file (e.g., shell's ~/.history file).