Difference between revisions of "File Paths"
From GeeklogWiki
m (Added category) |
|||
| Line 14: | Line 14: | ||
This is very vulnerable. A malicious user could inject ../../../../../etc/passwd for example, or any other file you wouldn't want to make public. Suppose you use this method to include a theme.php file with an include call? Then a user could inject anything they've managed to drop into your error.log file! | This is very vulnerable. A malicious user could inject ../../../../../etc/passwd for example, or any other file you wouldn't want to make public. Suppose you use this method to include a theme.php file with an include call? Then a user could inject anything they've managed to drop into your error.log file! | ||
| + | |||
| + | |||
| + | [[Category:Development]] | ||
Latest revision as of 13:13, 7 March 2008
Beware of Relative Paths
Plugins designed to work with files stored on the system are likely to suffer from security issues if they do not take great care to deal with the paths in question.
For example, suppose your plugin prompts a user to pick a file from a list, then passes that filename through to display (log file browser?):
<?php $filename = $_POST['filename']; readfile( $_CONF['path_system'] . '/plugins/myexploitablefileplugin/files/' . $filename ); ?>
This is very vulnerable. A malicious user could inject ../../../../../etc/passwd for example, or any other file you wouldn't want to make public. Suppose you use this method to include a theme.php file with an include call? Then a user could inject anything they've managed to drop into your error.log file!
