php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #54600 possible parse_url problem
Submitted: 2011-04-25 11:19 UTC Modified: 2011-05-29 11:02 UTC
Votes:3
Avg. Score:4.3 ± 0.9
Reproduced:3 of 3 (100.0%)
Same Version:3 (100.0%)
Same OS:3 (100.0%)
From: tyra3l at gmail dot com Assigned:
Status: Not a bug Package: *URL Functions
PHP Version: 5.3.6 OS:
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: tyra3l at gmail dot com
New email:
PHP Version: OS:

 

 [2011-04-25 11:19 UTC] tyra3l at gmail dot com
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)"
}



Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-05-29 11:02 UTC] iliaa@php.net
-Status: Open +Status: Bogus
 [2011-05-29 11:02 UTC] iliaa@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php


 [2011-05-29 12:26 UTC] tyra3l at gmail dot com
so it seems we are going with the last option: leave this as is.

Tyrael
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Oct 06 04:01:26 2024 UTC