Message-ID: <4020D3B9.18819.D1B1D6@localhost>
Date: Wed, 04 Feb 2004 11:12:57 +1300
From: Nick FitzGerald <nick@...us-l.demon.co.uk>
To: bugtraq@...urityfocus.com
Subject: Re: MS to stop allowing passwords in URLs


"McAllister, Andrew" <McAllisterA@...ystem.edu> wrote:

> I just read that Microsoft will stop allowing IDs and passwords to be
> embedded in URLs used by Internet Explorer. So you will no longer be
> able to use a URL like https://user:password@....somehost.com/
> 
> See http://support.microsoft.com/default.aspx?scid=kb;en-us;834489

And a good thing too...

You see, rather sadly, MS failed to note in that KB article that this 
change _finally_ makes IE's HTTP URL-handling more or less standards-
conforming.  How many years is that now since IE 3.0 introduced this 
non-standard behaviour?

> Their reasoning is that this will mitigate status bar spoofing as has
> recently been discussed here and in other forums. The article even goes
> so far as to admit that recent versions of IE show only the URL before
> the @ sign while older versions do not.
> 
> Apparently MS has decided that this RFC URL syntax is simply too
> dangerous to allow in their products. 

It seems you misread the KB article and related RFCs.  Admittedly the 
KB article seems to have been written be portray MS as the victim of 
harrassment by those nasty scammers, but in reality -- whatever MS' 
actual or professed reasons for making these changes -- MS has removed 
a _mis-feature_ that was not compliant with the agreed industry 
standards that IE is supposed to measure up against.

Although that KB article refers the reader to RFC 2616 for further 
explanation, it also rather misleadingly refers to RFC 1738 and 2396.  
As RFC 2616 specifically covers the HTTP URL syntax in its section 
3.2.2, the others are irrelevant to the issue of "What is the proper 
syntax of an HTTP URL?".  RFC 2616 clearly _does not allow_ the 
"userid" component of the generic URI syntax _which is OPTIONAL _AND_ 
scheme dependent_.  Go on, read all three RFCs and see for yourself...  

> Their suggested workarounds include among others:
>   1) Having users click the "Remember my password" checkbox in IE.
>   2) Using cookies.
> 
> I personally use this syntax in only one production application, BBTray
> - a windows tray applet that watches my bigbrother monitoring server.

Then you should stop because it is not standards compliant.  Do you 
really want to be part of the problem?  (And a problem, that no matter it
is not publicy admitting it is largely responsible for, MS itself is now
trying to distance itself from?)

> Click the applet and it opens a browser window with the
> id:passowrd@...ver.com syntax. The ID and password is specific to our
> bigbrother application, my workstation sits behind two firewalls and I
> am the only admin on the box. So, I consider this use to be legit and
> relatively safe given the convenience it provides.

You're welcome to your opinion, but as a few moments reading the RFCs,
rather than the documention of the devil-spawn of all browsers would have
shown you way back when, it is a poor opinion.

> I certainly don't consider the "remember my password" functionality nor
> stored cookies any more or less safe than this syntax.

Indeed, but at least they cooform to the standards that are supposed to
make the WWW work and interoperate between dozens upon dozens of otherwise
largely incompatible systems.

> Anyone have any comments regarding legitimate uses of this syntax and

No, because there is no legitimate use of that syntax.  If MS had 
implemented a scheme of its own -- say, "scamsRus" -- and allowed the
userid component of the generic URI as a valid part of that scheme, then
you would certainly be entitled to use a URL of the form:

  scamsRus://user:password@....somehost.com/

but HTTP is defined without such support so you aren't entitled to use it as MS should not have supported it.  

> Microsoft removing it from their browser? (and presumably the OS since
> the browser IS the OS).

This is a good thing.

The inconvenience to your relatively few users of their loss of this
non-standard "feature" is worth the reduction in credible-seeming scams
the removal of the feature will see in ensuing years.

And perhaps MS removing this will pressure other browser developers to 
follow suit -- after all, who would want their product to be known as 
"the browser lagging IE in security features"?   8-)


Regards,

Nick FitzGerald

Powered by blists - more mailing lists