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

ID: 16337 Updated by: tmorgan-spam@kavi.com Reported By: tmorgan-spam@kavi.com Status: Verified Bug Type: HTTP related Operating System: Unix based PHP Version: 4.3.0-dev New Comment: 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> Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2002-07-09 19:51:46] sniper@php.net First, try this snapshot: http://snaps.php.net/php4-latest.tar.gz And if this doesn't work like you think it should work, provide a short but complete script which clearly (!) demonstrates the possible bug. ------------------------------------------------------------------------ [2002-05-14 01:42:13] tmorgan-spam@kavi.com We are still having issues with this. If you require any additional explanation, or examples, I can give them. Some indication of whether this is being worked on or not would be nice... ------------------------------------------------------------------------ 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