[thelist] send HTTP authentication from PHP page?

Ken Schaefer ken.schaefer at gmail.com
Wed Oct 6 21:37:04 CDT 2004

On Wed, 06 Oct 2004 21:57:44 -0400, noah <noah at tookish.net> wrote:
> Ken Schaefer wrote (06/10/2004 9:08 PM):
> > On Wed, 06 Oct 2004 16:18:47 -0400, noah <noah at tookish.net> wrote:
> >
> >>It's frustrating that Microsoft, rather than fixing the security problem
> >>that made this sort of URL potentially dangerous, just disabled it
> >>altogether.
> >
> > Well, it was never RFC compliant, so I suppose there was no reason why
> > it /had/ to be there. Perhaps the cost of fixing the problem properly
> > would have been too prohibitive?
> Microsoft obviously has the right to do whatever they want with their
> product, and since it's the most widely used browser in the world, if
> they choose to do something that breaks my site that's clearly my
> problem. However, since every other major browser maker has managed to
> deal with this without removing the functionality, I don't think it's
> unreasonable for me to wish that Microsoft had too.

Well, we don't /know/ that every other browser manufacturer has
managed to develop a safe implementation. The Microsoft implementation
was considered "safe" for how many years? Until someone managed to
work out a way of exploiting it.

> >>It's something that I've run into a number of times.
> >
> > Actually, what you have described below appears to be completely
> > /unrelated/ to what you are talking about above, so I don't understand
> > the "number of times" comment.
> I don't see why it's unrelated.

Well, your first point was about Microsoft removing some functionality
rather than fixing it.

Your second point was a complaint that your application based
authentication system had no easy/automatic way of forcing the browser
(or somehow invoking the browser) to utilise HTTP based authentication
for a static resource not handled by your application's authentication

The first is something that Microsoft has chosen to do (withdraw
functionality as a "fix" rather than provide a secure implementation),
and the second is a complaint about an underlying technical limitation
of the technologies we are using. So, I don't see how they are

Now, I can see how you can write out a <a> tag that includes OS
credentials as part of the href attribute. And "yes" your custom auth
system could match those OS user credentials in its user database. But
you could accomplish exactly the same thing by simply denying
anonymous access to your PHP/ASP/whatever pages, and requiring the
user to authenticate for those. Your code would then look at the
Logon_User value (since that would be the authenticated value) to
determine whether the action is authorised or not.

> The original poster wanted to provide
> HTTP authentication information from PHP. I have wanted to do the same
> thing on several occasions. I used to be able to do it by embedding the
> username and password in the URL. Now I can't do that.

IMHO That's got nothing to do with PHP. Everything you are doing is
plain HTML. The extent of the PHP involement is (possibly) dynamically
generating the HTML. The PHP itself does no authentication - the
browser and server perform the authentication.

In any case, this was not the issue that I wanted to take up with you.
The issue was the use of custom session based authentication systems
and Windows based NTFS authentication for resources not handled by
your application's session based auth system.

>From a security standpoint, the "better" way to handle all of this is
not to have the username/password in the URL at all. Just add the
website to the local Intranet security zone on the client (eg via a
Group Policy Object)


More information about the thelist mailing list