Today I gave PHP's function parse_url a spin. Armed with nulls, carriage returns and line feeds, I obviously could not resist into bypassing the query parsing. While parse_url doesn't do security checks, I think this is still somewhat notable to mention.
It seems that PHP replaces nulls, carriage returns and line feeds with an underscore. I am not sure why they chose to do this, but somehow I don't like it. The reason is that it could be used to trick an IDS or bypass a IPS/webapplication firewall this way. This is because of the parsing of the url is done after we submitted our vector, so only the PHP script that processes it could choke on it, depending the situation of course.
Now I think it important to understand that you can never rely solely on an IDS, IPS/ webapplication firewall, because if the data is being modified after it has passed a protection mechanism, it can result in a security problem like race conditions, PHP injection, GLOBALS tampering and probably more depending on a programming error c.q. PHP version.
Below a testcase:
<?php
$var = "$\0REQUEST['xyz']"; # embedded null
$url = "http://username:password@hostname/path?arg=".$var."#anchor";
echo "<pre>";
print_r(parse_url($url));
echo parse_url($url, PHP_URL_PATH);
echo "</pre>";
?>
and the output generated by PHP:
Array
(
[scheme] => http
[host] => hostname
[user] => username
[pass] => password
[path] => /path
[query] => arg=$_REQUEST['xyz']#anchor
)
This again concludes that you cannot rely on a server side language. Basically you have to check everything even if PHP is processing your data. Given the notion how many functions exist in PHP, it is easy to imagine a possible security impact this way.
