Preventing http://username:password@path access

This method bypasses the password dialog box

[Jimbo_A]

I understand that anyone with a valid username and password could place a link such as http://username:[e-mail]/protected/mypage.html on a webpage and give the world access to the page which is protected by .htaccess (Basic Authentication).

I'm using Linux Red Hat 7.1 and Apache 1.3 on a remote server. Is there any way to prevent Apache from accepting a valid username/password sent in this particular way (preceding the URL address)? Alternatively, is there a Perl or PHP variable or method which could be used? I've tried the http_referer variable, but that just gives me the calling page. What I would need is the complete hyperlink which was clicked.

Any advice or tips will be much appreciated, evan a URL where the problem is being discussed.

[JasonD]

Interesting question.

Although the RFC doesn't allow username and passwords to be included in a URL the practical implementation of it does. I've done some basic (VERY basic) testing on this as it interests me and this is what I have found.

The browser interprets the inline username and password and sends it as correctly formatted Basic Auth info so the server sees it simply as a standard succesful logon. Because of this there are no environment variables that may assist in stopping inline username passwords that I am aware of.

However, I think you have already got half of a possible solution. By utlising the http_referrer variable you will have available to you the page on which the link was clicked. You can use that information to parse the page for the link using LWP in Perl or CURL in PHP (just 2 options, there are many more)

If there is an anchor tag with an embedded password then you can stop them progressing further or if a standard anchor link is present set a session variable allowing them continued access.

I hope this helps..

Jason

[Jimbo_A]

Thanks, Jason. It's particularly helpful to know that the browser actually sends the username and password in the correct Basic Auth format, and hence there's probably no way that Apache can know how it was done.

I'm familiar with using LWP in Perl and I will do some experimenting to see how quickly the calling page can be examined for an offending hyperlink. I'll come back when I have some results. Maybe other forum members will be interested.

Jimbo

[ProFiler]

It probably sounds to simple and is impossible but can't you just look ath the full URL that was "submitted" by the client and if it contains an @ AND a : then deny the request? That is assuming that what´s in the url bar is also submitted in some sort of way :)

[bakedjake]

Why not change your authentication system to a custom coded one instead of a server-based one?

It will stop that problem dead.

[Jimbo_A]

As JasonD pointed out, "The browser interprets the inline username and password and sends it as correctly formatted Basic Auth info, so the server sees it simply as a standard succesful logon". This means to me that the URL that was submitted by the client, and captured by PHP or Perl in a variable, won't show the problem 'username:password@'.

I now think bakedjake's suggestion is the way to go. It will mean a lot of work for me but it should be watertight.