ID: 16337 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Open Bug Type: HTTP related Operating System: Unix based PHP Version: 4.1.0 New Comment:
Feedback was given, but status not changed. Reopening. Previous Comments: ------------------------------------------------------------------------ [2002-05-14 00:00:04] [EMAIL PROTECTED] 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] [EMAIL PROTECTED] 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:$[EMAIL PROTECTED]/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. ------------------------------------------------------------------------ [2002-04-13 19:11:18] [EMAIL PROTECTED] RFC 2068 is obsoleted by RFC 2616, so your assumption that RFC 2068 is still adhered to is incorrect. The username:password string is base-64 encoded for Basic Authentication, which I'm going to assume you're using, since you didn't mention what type of authentication the server demands for access to http://www.example.org/. It is not URL encoded. Now, as for your bug report, why in the world would the include function *decode* the username:password string? The content coming back from the server doesn't specify the username and password to be used; that's what *you* sent. See RFC 2617 for more information about both Basic and Digest Authentication over HTTP. http://ietf.org/rfc/rfc2617.txt will point you there. I think a better understanding of this might help you solve your problem on your own. However, if this does not help, it should at least allow you to better explain what the problem is, because your reports have too many holes for me to understand what problem you are having, whether a bug in PHP or not. ------------------------------------------------------------------------ [2002-04-10 20:01:07] [EMAIL PROTECTED] in case anyone wondered, the HTTP spec I am refering to, is at: http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2068.html (Section 11.1) Since RFC 2616 doesn't specify user-pass strings, I assume this older RFC still applies. ------------------------------------------------------------------------ [2002-04-10 19:57:48] [EMAIL PROTECTED] Correction: PHP's fopen url wrapper doesn't appear to unencode ANY encodings at all. Since the HTTP spec only excludes ':' from the username (and nothing at all from the password), this bug makes many username:password pairs unusable. ------------------------------------------------------------------------ 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
