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

ID: 16337 Updated by: tmorgan-spam@kavi.com Reported By: tmorgan-spam@kavi.com Status: Feedback Bug Type: HTTP related Operating System: Unix based PHP Version: 4.1.0 New Comment: 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. 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... ------------------------------------------------------------------------ [2002-05-14 00:46:32] mfischer@php.net Feedback was given, but status not changed. Reopening. ------------------------------------------------------------------------ [2002-05-14 00:00:04] php-bugs@lists.php.net No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". ------------------------------------------------------------------------ [2002-04-15 14:04:07] tmorgan-spam@kavi.com Ok, so I think maybe I shouldn't have brought up the HTTP spec. The *only* reason I did that, was that HTTP has one small limitation on username:password pairs. As far as I could find, in all of new and old RFCs (including 2617) was that ':' is disallowed from the username. I have read of no limitations on what the password can contain. Based on the above, I am going to make the conjecture that if the 'http://USERNAME:PASSWORD@...' syntax in PHP can't handle certain 'special' characters, then it is broken. The way I was trying to use this feature was like the following: I was trying to include some headers and footers from my *local* webserver into my PHP script when it is displayed. Why am I using an URL for this?? Well, because the script that dynamically generates those headers and footers is written in a different language. It is a temporary fix for me while I port code. In any case, the authentication realm that my PHP script lives in, is the same realm as the headers and footers. So, when a user hits the PHP script, the username and password variables are stuck together into a URL like: "http://$username:$password@www.example.org/header.cgi" Then I use an include() call to grab the header. Make sense so far? The problem is, PHP bombs when the user's password contains any special characters. More specifically, if it contains characters that are normally considered special in URL terms. Just suppose for a minute, that my password contains an '@'. How is PHP to parse this? Should it assume that the first or last @ found is the delimiter? What if the username was equal to 'www.example.org/evilscript.cgi?var='? Then we have a Cross-Site Scripting Vulnerability on our hands. So, my reasoning for the urlencoding was that if the user was responsible, they would urlencode the username and password individually, thus making the URL actually parseable in any situation. The only way this would work though, is if PHP unencoded those tokens after parsing them out of the URL. Currently it does not. Once again, this escaping problem is between the caller and the include() function, not between the PHP internals and HTTP. ------------------------------------------------------------------------ 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