Bug #16337 Updated: include() does not decode % correctly

ID: 16337 Updated by: sniper@php.net Reported By: tmorgan-spam@kavi.com -Status: Verified +Status: Closed Bug Type: HTTP related Operating System: Unix based PHP Version: 4.3.0-dev New Comment: This bug has been fixed in CVS. You can grab a snapshot of the CVS version at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites. Thank you for the report, and for helping us make PHP better. Any username/password are now urldecoded before passing them on. Previous Comments: ------------------------------------------------------------------------ [2002-07-10 02:18:41] tmorgan-spam@kavi.com In response to sniper's post: As I said in my previous post, re: b64, it only makes sense to encode your user data in a format meant for escaping characters for *that* format. would you run mysql_escape_string() on a string that you wanted to quote to avoid cross-site-scripting (XSS)? Well, MAYBE that function will escape the necessary characters properly (which in this example it doesn't), but if mysql changes its set of special characters, or its method of escaping them, then the code might break later. So, what I am saying, is don't escape oranges with something that is meant to escape apples. urlencode/urldecode are meant for URL special characters. Base 64 is just a general purpose method for escaping odd characters, and yes, it might work, but it is nearly impossible for humans to read, even if no special characters existed in the username:password pair. Thanks for looking into this guys. ------------------------------------------------------------------------ [2002-07-10 02:10:02] tmorgan-spam@kavi.com Regarding base64 encoding: Yes, the HTTP spec does use b64 for wrapping up username:password pairs. However, you must remember that A: the URL syntax is you see in a browser is much different from the data that is passed to a webserver in HTTP. B: the http://USERNAME:PASSWORD@domain.tld/ syntax is more of a defacto-standard-made-legit, and the parsing of it really has nothing to do with HTTP. Let me explain more by example. Say my username was the literal USERNAME, and my password was the literal PASSWORD. then the encoded pair is: VVNFUk5BTUU6UEFTU1dPUkQ= that would make my request URL look like: http://VVNFUk5BTUU6UEFTU1dPUkQ=@www.example.org/ Isn't that a little weird? Does the parser handle '=' before the @? maybe, but I don't think this syntax is what is originally intended... So, if instead you mean to encode each of the two tokens seperately, then the parser would have to unencode b64 and re-encode them again with the ':' in the middle. Therefore, does it really matter what encoding is used the first time through? It is undone anyway. To me, it only makes sense to use URL encoding, since that is what we are talking about here. We need to escape characters that would otherwise be considered special in a URL. <rant> Every syntax has a set of special characters. When embedding user data that uses those characters, those characters must be escaped or quoted. This is a simple principle that 90% of web developers haven't caught onto yet, and that is why the internet is plagued with cross site scripting vulnerabilities. (And SQL injection, and shell injection, and...) </rant> ------------------------------------------------------------------------ [2002-07-09 23:46:35] sniper@php.net The bug can be found here: It's partly php_url_parse's fault. It uses regexps to separate the url parts..but will fail if you pass it a url like this: http://username:pass@word@www.example.org/ This will end up as having username 'username' and password 'pass'. (host being word@www.example.org) Now, if the username and password are urlencoded (or base64 encoded) the above mentioned regexp will work..but this will fail: ext/standard/http_fopen_wrapper.c:150-165 As it goes and base64-encodes the user/password pair. So, which should be fixed? Let user pass the username/password without modifying them first (fix the regexps) or require them to be urlencoded and decode them before base64 encoding ?? ------------------------------------------------------------------------ [2002-07-09 20:59:06] eru@php.net Judging from the RFC, I'd say you're not using the appropriate encoding scheme. The RFC says: base64-user-pass = <base64 encoding of user-pass> user-pass = userid ":" password userid = *<TEXT excluding ":"> password = *TEXT So in your case this would be $user_pass64 = base64_encode( $username.":".$password ); include("http://".$user_pass64."@www.example.com/"); ------------------------------------------------------------------------ [2002-07-09 20:34:34] tmorgan-spam@kavi.com You know, I would really like this bug fixed, but I am really frustrated by the attitude I am getting here. Three and a half months have passed, and yet not a single developer at PHP has taken 10 minutes to attempt to replicate it themselves. I know there are a lot of bugs in PHP that need fixing, but cmon, at least an assessment of when it is going to be fixed. And if it IS fixed in the new release, then why don't you tell me that? As for example code, well, I have already given the one line that is necessary, but I will try to make it plainer: // GIVEN: user provided $username & $password // What SHOULD work: $clean_username = urlencode($username); $clean_password = urlencode($password); include("http://$clean_username:$clean_password@www.example.com/"); The url parser in include() needs to parse, then decode, those two strings before passing them to the HTTP session. If you want to know why this should be this way, read my previous comments. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/16337 -- Edit this bug report at http://bugs.php.net/?id=16337&edit=1