Difference between revisions of "Logging"

From GeeklogWiki
Jump to: navigation, search
(This is only a stub, but we'll have to start somewhere ...)
 
m (Added category)
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
== Be careful what you log ==
 
== Be careful what you log ==
  
This may sound odd at first but '''you should be careful what you log''' (in Geeklog's error.log or your own logfile).
+
The PHP interpreter engine will parse PHP out of any file, no matter what the extension, so long as it contains a valid PHP open tag. It doesn't matter what the rest of the content of the file, so long as it has a section of code wrapped in the PHP tags, it will parse and (try to) execute that block of content.
  
The problem is that PHP will happily execute any PHP code it will find in the middle of a text file (''any'' file, actually), as long as it's properly enclosed in the <?php and ?> tags.
+
So, if you have a jpg file, that contains <?php echo('hello!'); ?> in the middle of the binary JPEG content and your PHP interpreter is asked to open that file, that block will be parsed and executed.
  
So while PHP code that gets logged into your error.log file is not an immediate problem, it ''will'' become a problem as soon as someone manages to include the logfile into a PHP script.
+
Geeklog provides several logging methods, including COM_errorLog, allowing you to log data to one of several files for the administrator to review. If someone crafts a cunning attack, they could arrange to have a block of PHP code logged into one of the core Geeklog log files, or your plugins custom log file.
  
 +
This is not an immediate problem, typically these log files are not included in any scripts. However, should the cunning attacker be extra cunning, they may be able to devise a method of tricking Geeklog, or your plugin into doing a require, require_once, include or include_once on the infected log file, resulting in the execution of their injected code.
  
[Okay, I'm suffering from writer's block at this point. Someone more eloquent please rewrite and expand this ... [[User:Dirk|Dirk]] 15:49, 11 March 2006 (EST)]
+
The fact that the web server is able to (and regularly does) write to these log files is the weak point. It gives them a location they can insert their own code to further open up the system to the full gamit of their evil desire.
 +
 
 +
''Careful!'' remember, <?php ... ?> is not the only way of running PHP code. If enable_short_tags is set, <? .. ?> works. PHP can even be configured to use the ASP tags: <% ... %>. Or, the log files could be used to attack ASP scripts, Coldfusion scripts or anything else that is available on the server.
 +
 
 +
 
 +
[[Category:Development]]

Latest revision as of 13:12, 7 March 2008

Be careful what you log

The PHP interpreter engine will parse PHP out of any file, no matter what the extension, so long as it contains a valid PHP open tag. It doesn't matter what the rest of the content of the file, so long as it has a section of code wrapped in the PHP tags, it will parse and (try to) execute that block of content.

So, if you have a jpg file, that contains <?php echo('hello!'); ?> in the middle of the binary JPEG content and your PHP interpreter is asked to open that file, that block will be parsed and executed.

Geeklog provides several logging methods, including COM_errorLog, allowing you to log data to one of several files for the administrator to review. If someone crafts a cunning attack, they could arrange to have a block of PHP code logged into one of the core Geeklog log files, or your plugins custom log file.

This is not an immediate problem, typically these log files are not included in any scripts. However, should the cunning attacker be extra cunning, they may be able to devise a method of tricking Geeklog, or your plugin into doing a require, require_once, include or include_once on the infected log file, resulting in the execution of their injected code.

The fact that the web server is able to (and regularly does) write to these log files is the weak point. It gives them a location they can insert their own code to further open up the system to the full gamit of their evil desire.

Careful! remember, <?php ... ?> is not the only way of running PHP code. If enable_short_tags is set, <? .. ?> works. PHP can even be configured to use the ASP tags: <% ... %>. Or, the log files could be used to attack ASP scripts, Coldfusion scripts or anything else that is available on the server.