Difference between revisions of "Logging"
(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 == | ||
| − | + | 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. | ||
| + | |||
| + | |||
| + | [[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.
