Re: Validation of class names in the autoload process

From: Date: Thu, 17 Oct 2013 12:59:02 +0000
Subject: Re: Validation of class names in the autoload process
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-69614@lists.php.net to get a copy of this message
On Thu, Oct 17, 2013 at 2:31 PM, Johannes Schlüter <johannes@schlueters.de> wrote: > Are there codepaths where this can be injected from the outside? In the > unserializer this was prevented in > > https://github.com/php/php-src/commit/ff8055fc5c9750482aac7a25a074aae0b1e64706 > and some further commits, i.e. > > https://github.com/php/php-src/commit/7126de4912d9d4c7499deb1f9239980400aa7ec7#diff-d697fc054b607bb0ffd7493daeb6a1afR616 Sorry when I said deserialize I meant this as a generic term not php's unserialize(). I mean say you have two types of something, and the API works taking a type param + some data for it, and you create it with something along those lines: $class = 'Foo\Bar\Type'.$userGivenType; $obj = new $class($userData); In this case, the autoloader would be called with whatever the user passed in unless you validate it, but since autoloader injection isn't a very common vector many devs wouldn't validate this and assume a happy path I guess. > Reasons against moving those in a more central place were > > - Performance. checking always costs time (any autoloader is > way slower, shouldn't matter too much) > - There are more esoteric ways (mostly for extensions) to create > classes with "illegal" names (only illegal class names I know are > OCI-Lob and OCI-Collection from oci8 extension) an autoloader > (inside an extension) might produce them (I think that is unlikely > to exist in reality) > - Autoloader magic (developers sometimes do things I can't imagine) > - Autoloaders still have to verify (i.e. maximum length for the backend > used, some backends might require additional protection (i.e. \ needs > to be escaped)) IMO performance is the only valid concern, but it'll be faster done once in the proper way in C than done in various crappy ways in every userland autoloader, and it will also protect everyone at once. There might be edge cases not covered by invalidating "." and "NUL", but to keep it fast it may be best to only check for known bad chars instead of the full regex? Cheers

« previous php.internals (#69614) next »