I wonder if doing "$cast = (string) $input" prior to the rest will avoid it? I do things like that, as well as making sure all methods use type hinting, which would hopefully make this harder?
I'm pretty sure the error is when they later take the input and eval it, and the author's managed to dodge their filtering rather than execute arbitrary code in the context of an array-to-string cast (which I was lead to believe when reading that post, at least). Otherwise it implies that some permutation of:
This phrase "internally php strings are byte arrays. As a result accessing or modifying a string using array brackets will trick the parser into evaluating arbitrary php code in the scope of the variable if the prior mentioned requirements are met." doesn't seem to be present in the linked documentation (http://www.php.net/manual/en/language.types.string.php), however. Does anyone know what these "prior mentioned requirements" might be?
The actual quote from the manual, that they appear to be referencing, is:
Internally, PHP strings are byte arrays. As a result, accessing or modifying a string using array brackets is not multi-byte safe, and should only be done with strings that are in a single-byte encoding such as ISO-8859-1.
It seems like they just replaced:
is not multi-byte safe, and should only be done with strings that are in a single-byte encoding such as ISO-8859-1.
...with...
will trick the parser into evaluating arbitrary php code in the scope of the variable if the prior mentioned requirements are met.
Any links to other blogs/sites where the hacker talks through their thought process like this?
There are plenty of online databases which list exploits but I feel like you can learn a lot more from the process they used to come up with the exploit, as given here.
16 comments
[ 3.1 ms ] story [ 52.1 ms ] threadI wonder if doing "$cast = (string) $input" prior to the rest will avoid it? I do things like that, as well as making sure all methods use type hinting, which would hopefully make this harder?
Presumably the bounty was distributed without incident which is worth noting the recent threads of bounties being forfeited.
$a = '{${phpinfo()}}'; $b = [$a]; $c = "$b";
Will execute phpinfo()... which it won't.
Learned something though.
This phrase "internally php strings are byte arrays. As a result accessing or modifying a string using array brackets will trick the parser into evaluating arbitrary php code in the scope of the variable if the prior mentioned requirements are met." doesn't seem to be present in the linked documentation (http://www.php.net/manual/en/language.types.string.php), however. Does anyone know what these "prior mentioned requirements" might be?
Internally, PHP strings are byte arrays. As a result, accessing or modifying a string using array brackets is not multi-byte safe, and should only be done with strings that are in a single-byte encoding such as ISO-8859-1.
It seems like they just replaced:
is not multi-byte safe, and should only be done with strings that are in a single-byte encoding such as ISO-8859-1.
...with...
will trick the parser into evaluating arbitrary php code in the scope of the variable if the prior mentioned requirements are met.
It's still not an explanation of how you go from injecting a deformed string to executing code.
There are plenty of online databases which list exploits but I feel like you can learn a lot more from the process they used to come up with the exploit, as given here.