note 85036 deleted from language.oop5.patterns by danbrown
| From: | danbrown@php.net | Date: | Sun, 23 Jan 2011 16:37:28 +0000 |
| Subject: | note 85036 deleted from language.oop5.patterns by danbrown | ||
| References: | 1 | Groups: | php.notes |
| Request: | Send a blank email to php-notes+get-176099@lists.php.net to get a copy of this message | ||
Note Submitter: Anonymous
----
Tedmasterweb's point is a good one, though sanitizing inputs is often even more subtle than you
would expect. For instance, his sanitizing solution would fail if the supplied driver name were
"../../../../../../../../etc/passwd\0" (which, as you'll note, is
null-byte-terminated). The underlying C-functions that run most modern POSIX-compliant and
POSIX-based operating system filesystem operations will treat the ASCII null byte as a string
termination character, and so will ignore the ".php" he appended to the path. Thus, this
attack would still succeed. This attack is described in further detail here (the link is too long
for the word wrapping, but it will still work):
http://us3.php.net/manual/en/security.filesystem.php
#security.filesystem.nullbytes
In my own __autoload functions, I tend to provide a validating regex for class or interface names to
only allow characters I know are safe (though this code might have to be adjusted once namespace
support is fully functional in PHP). For anyone who prefers to attempt to remove unsafe characters
instead, I suggest the following list at a minimum:
period (for the ".." pseudo-directory), slash and backslash (for directory separators;
both work on Windows systems), the explicit DIRECTORY_SEPARATOR constant, and the ASCII null byte
(which can be typed in code as "\0").
Usage of the PHP functions escshellcmd or escshellarg might also be advisable, depending on how your
code is written (particularly depending on whether it is executing a shell command or including a
file).