Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to retrieve attempted $_SERVER['REMOTE_USER'] from URL when no authentication is required

Normally when a publicly-accessible directory requires basic HTTP authentication, the value of $_SERVER['HTTP_AUTHORIZATION'] and/or $_SERVER['REMOTE_USER'] (or $_SERVER['PHP_AUTH_USER'], etc) will be set and accessible to PHP once a valid username/password combination have been provided to the server.

For example, if http://www.example.com/members requires basic authentication, and a user successfully authenticates using the credentials myusername and mypassword by manually typing http://myusername:[email protected]/members into their browser, the value of $_SERVER['HTTP_AUTHORIZATION'] would be something like:

Basic bXl1c2VybmFtZTpteXBhc3N3b3Jk

... and the value of $_SERVER['REMOTE_USER'] would simply be:

myusername

However if authentication is not required in the same directory, but the URL is still visited with the username/password inside of it, the values of the username/password don't seem to be set anywhere (running PHP 5.3.10 as CGI/FastCGI on Apache/2.2.22).

From within PHP (and/or .htaccess if necessary), when no authentication is required, is there a way to retrieve the values of the username (and/or password) that have been provided by a visitor who manually added them to the URL?

like image 889
jerdiggity Avatar asked Jul 31 '15 02:07

jerdiggity


2 Answers

TLDR; As far as I can see that information is never sent to server so I claim it's not possible.

The way http authentication works if you have it set is that server sends a request for user/pass if it's not already set, and browser then adds that information in encoded form to a Authorization header and sends it to the server along with the request.

As specified in RFC 2617, describing Basic and Digest authentication mechanisms For basic authentication, server sends HTTP 401 Not Authorized status and WWW-Authenticate header fields to request this information. (RFC 2617, Access Authentication Framework)

With tests one can see that if authentication is never configured on the server to be required, server won't request authentication information from browser, and browser won't add user/pass information into the request. RFC does not mandate browser (user agent) to not pass that information, but says instead

A user agent that wishes to authenticate itself with an origin server--usually, but not necessarily, after receiving a 401 (Unauthorized)--MAY do so by including an Authorization header field with the request.

In practice, if you watch the sent headers you can see that if this information is requested by the server, it's sent in encoded form using Authorization header like specified by the RFC. However, if you're not using any authentication the request you send just doesn't seem to contain that information in any form. I've confirmed this with IE, Firefox and Chrome browsers myself.


If you want to test this yourself for your setup, this can be done for example using netcat like this:

First, run netcat on your server:

nc -l 8888

Then issue a request from your browser to http://testvalue:testvalue@yourdomain:8888/

As a result, observe from netcat output all the information that get sent to server, something like this:

GET / HTTP/1.1
Host: yourdomain:8888
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive

There is no information about user or password anywhere. I claim that unless the server requests it, it won't be there.

like image 73
eis Avatar answered Sep 28 '22 16:09

eis


The addition of user and password in a url using http(s)://user:[email protected] has been disabled by at least Internet Explorer for several years now, as far as i know.

https://support.microsoft.com/en-us/kb/834489

So I am not sure if what you are trying to reach is even usefull. I think the browsers dont even pass that part of the url on anymore.

like image 41
HappyMe Avatar answered Sep 28 '22 17:09

HappyMe