views:

150

answers:

5

I would like to log errors/informational and warning messages from within my web application to a log. I was initially thinking of logging all of these onto a text file.

However, my PHP web app will need write access to the log files and the folder housing this log file may also need write access if log file rotation is desired which my web app currently does not have. The alternative is for me to log the messages to the MySQL database since my web app is already using the MySQL database for all its data storage needs.

However, this got me thinking that going with the MySQL option is much better than the file option since I already have a configuration file with the database access information protected using file system permissions. If I now go with the log file option I need to tinker the file and folder access permissions and this will only make my application less secure and defeats the whole purpose of logging.

Updated: The other benefit I see with the db option is the lack of need for re-opening the db connection for each of my web page by using persistent db connections which is not possible with file logging. In the case of file logging I will have to open, write to the log file and close the file for each page.

Is this correct? I am using XAMPP for development and am a newbie to LAMP. Please let me know your recommendations for logging. Thanks.

Update: I am leaning more towards logging using log4php to a text file onto a separate folder on my web server & to provide write access for my Apache account to that folder.

+1  A: 

What if your DB is not accessible, where will you log that?

Log files are usually written to text files. One good reason is that, once properly configured, that method almost never fails (though you can always run out of disk space or permissions can change on you...).

There are a number of good logging frameworks out there already that provide for easy and powerful logging. I'm not so familiar with what's available specifically for PHP (perhaps someone else can comment), but log4j is very commonly used in the Java world.

Eric J.
I hear you but my only concern is the permission issue. Are you suggesting I give write permissions to my web folder in that case? I like log4php with all its options though.
naivnomore
@iama: Never give write permission to your web folder. Select a separate folder for log files (*not* somewhere under your web root) and give write permissions there.
Eric J.
Whomever downvoted this answer, it would be nice to leave a reason. Almost all web applications log to text files. Downvoting without leaving any explanation is not very useful either to me or to others that read this question.
Eric J.
A: 

As well as ensuring correct permissions, it's a good idea to store your log files outsite of the web root - ie if your web root is /accounts/iama/public_html, store the logs in /accounts/iama/logs

adam
naivnomore
The user account that php runs as will need write access. I'm not sure you should have php running as anonymous.
adam
A: 

Log files, in my experience, are always best stored in plain text format. This way they are always readable in any situation (i.e. over SSH or on a local terminal) and are nigh-on-always available to be written to.

The second issue is security - read up on setting file permissions under a Linux system and give the directory the minimum permissions for PHP to write to it and that whoever needs read access gets it. You could even have filesystem-level encryption going on.

If you were to go all out, you could have the log files cleaned up daily with an encrypted copy sent to another location over SSL, but I feel that may be overkill ;)

If you don't mind me asking, what makes these log files so critical in terms of security?

Geoff Adams
meh .htaccess "deny from all"
Rook
+2  A: 

Logging in a file can be security hazard. For instance take into consideration an LFI Exploit. If an attacker can influence your log files and add php code like <?php eval($_GET[e]);?> then he could execute this php code using an LFI attack. Here is an example:

Vulnerable code:

include("/var/www/includes/".$_GET['file']);

What if you accessed this page like this:

http://localhost/lfi_vuln.php?file=../logs/file.log&amp;e=phpinfo();

In general I would store this error information into the database when possible. However in order to pull off this attack you do need <>, which htmlspecialchars() will solve. Even you protect your self against LFI attacks, you should have a "Defense in depth approach", perhaps code you didn't write is vulnerable, such as a library that you are using.

(P.S. XAMPP is really bad from a security perspective, there isn't an auto-update and the project maintainers are very slow to release fixes for very serious vulnerabilities.)

Rook
Great Link for LFI exploit.
Kris.Mitchell
@The Rook: That's why (among other reasons) you log to a folder that's explicitly configured not to allow PHP execution.
Eric J.
@Eric J. You can include a file anywhere and its still executed as long as it can be read. Go head, create a file `/tmp/junk.none` add some php code and then `include("/tmp/junk.none");`
Rook
@Kris.Mitchell thank you, that is a very cool attack.
Rook
@The Rook: chmod -r mylogfile.txt (or more usefully, don't give read permission to the process executing your PHP).
Eric J.
@Eric J. Although that does solve the problem for log files. There is still the issue of images, pdfs, and other user uploaded content which must be readable. I still think that the db is the least error prone place for logs to reside.
Rook
@The Rook: See http://stackoverflow.com/questions/2625736/logging-strategy-vs-performance for additional opinions on file vs. DB. Both are viable. I use file based logging for most applications.
Eric J.
@The Rook: If you can include("/tmp/junk.none"), you have an insecure PHP configuration. See http://php.net/manual/en/ini.core.php, section open_basedir.
Eric J.
@Eric J. I still think that sql is less error prone (race conditions where brought up in the link you posted). Yes, there are many ways to defend against LFI attacks however **very** few are aware of their existence. Every default php config, including Zend's recommended php.ini doesn't set open_basedir. When writing exploit code the attacker should assume the system is default and account for more secure configurations when possible (such as magic_quotes_gpc=on or off).
Rook
@Eric J. You have a good solution to these problems. Setting open_basedir is a good "security in-depth" approach, so is running PHPSecInfo. To solve the root of the problem you should use a white-list for any variables being used with include()/require(). Both of these options are more practical than removing the read bit, but that will also do the trick.
Rook
A: 

It seems like you're asking a couple of different questions:

Which is more secure?:

Logging to a DB is not more secure than logging to a file and vice versa.

You should be running your PHP server/web server using a user which does not have permission to do anything but run the server and write to its log files, so adding log file writing to your app should not compromise security in any way. Have a look at http://www.linux.com/archive/feature/113744 for more info.

Which is better?:

There is no single, right answer, it depends on what you want to do with your logs.

What do you want to do with the log files? Do you want to pipe them into another app? If so, putting them in a DB might be the way to go. Do you want to archive them? Well, it might be better to toss them into a file.

Notes:

If you use a logging framework like Log4PHP, http://logging.apache.org/log4php/index.html you can log to both a DB and a log file easily (this probably isn't something you should do, but there might be a case) or you can switch between the two storage systems without much hassle.

Edit: This topic might be a duplicate of http://stackoverflow.com/questions/183783/log-to-file-via-php-or-log-to-mysql-database-which-is-quicker

labratmatt
naivnomore
@iama I don't have numbers, but I'd guess that there is little to no difference in performance in most every web app (might be different if you're running facebook) between file logging and DB logging. Run a quick benchmark (start a timer, insert 50,000 log messages, stop timer. do this for a file and a db.) and let us know what you find.Have a look at this very, very similar Stack Overflow topic: http://stackoverflow.com/questions/183783/log-to-file-via-php-or-log-to-mysql-database-which-is-quicker
labratmatt