Difference between revisions of "Logging"
(This is only a stub, but we'll have to start somewhere ...) |
(Rewritten, still awful though.) |
||
| Line 1: | Line 1: | ||
== Be careful what you log == | == Be careful what you log == | ||
| − | + | The PHP interpretter 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 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 interpretter 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. | ||
Revision as of 21:14, 11 March 2006
Be careful what you log
The PHP interpretter 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 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 interpretter 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.
