From: Operating system: PHP version: 5.3.6 Package: *URL Functions Bug Type: Bug Bug description:possible parse_url problem
Description: ------------ I've just read this article: http://theharmonyguy.com/2011/04/21/recent-facebook-xss-attacks-show-increasing- sophistication/ there is an interesting part: "According to Facebook, it turned out that some older code was using PHPâs built-in parse_url function to determine allowable URLs. For example, while parse_url(âjavascript:alert(1)â) yields a scheme of âjavascriptâ and a path of âalert(1)â, adding whitespace gives a different result: parse_url(â javascript:alert(1)â) does not return a scheme and has a path of âjavascript:alert(1)â. Other PHP developers should take note of the difference if parse_url is being used in security-related code." I know that the documentation mentions that "This function is not meant to validate the given URL, it only breaks it up into the above listed parts." but maybe we should do something to prevent people to misuse this function. I see 4 option: - we should improve the code to strip whitespaces that would cause the function to return the same output for the forged url's - we should change te code that the function never parse javascript: as scheme, this would prevent the people to use parse_url for this purpose, but judging from the article at least some code on facebook would fail insecurely for this change. - we should add more documentation about this issue, it can help, but I don't think that this would be the best fix. - leave it as is, we documented that one should not use this for validation, we can't save people from their bad code. Personally I'm not supporting this option. What do you think? Test script: --------------- php -r 'var_dump(parse_url("javascript:alert(1)"));' array(2) { ["scheme"]=> string(10) "javascript" ["path"]=> string(8) "alert(1)" } php -r 'var_dump(parse_url(" javascript:alert(1)"));' array(1) { ["path"]=> string(20) " javascript:alert(1)" } -- Edit bug report at http://bugs.php.net/bug.php?id=54600&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54600&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54600&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54600&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54600&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54600&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54600&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54600&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54600&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54600&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54600&r=support Expected behavior: http://bugs.php.net/fix.php?id=54600&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54600&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54600&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54600&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54600&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=54600&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54600&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54600&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54600&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54600&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54600&r=mysqlcfg
