MS to stop allowing passwords in URLs

On Mon, 2 Feb 2004 21:01:45 -0700
"Dave Warren" <dave.warren@devilsplayground.net> wrote:
> The safety concerns of http://user:pass@www aren't technical, they're
> user/training issues.. How do you explain to your grandmother that
> http://www.herbank.com:login.asp@session-arhuz.ru/ isn't safe but
> http://www.herbank.com/login.asp?arhuz.ru/ is okay?
>
> The solution, in my opinion, would be to come up with a new notation that
> doesn't break existing RFCs, but that still places the hostname first.

Or, hey, a different on-screen representation? Something like, I dunno,
"http://user:pass@site/" being turned into "http://site/ (user: user,
password: pass)"?

If you're worried about anything *other* than either the URL bar or the
status bar (like, for instance, the descriptive text of the link),
you're out of luck anyways. People who would still fall for that will
also fall for <a
href="http://www.please-crack-me.ru">http://www.microsoft.com</a>

Seriously, KISS. ("Keep It Simple, Stupid" for those who either aren't
familiar with the jargon or aren't native English speakers ;)

McAllister, Andrew wrote:
> I certainly don't consider the "remember my password" functionality
> nor stored cookies any more or less safe than this syntax.
>
> Anyone have any comments regarding legitimate uses of this syntax and
> Microsoft removing it from their browser? (and presumably the OS since
> the browser IS the OS).

The safety concerns of http://user:pass@www aren't technical, they're
user/training issues.. How do you explain to your grandmother that
http://www.herbank.com:login.asp@session-arhuz.ru/ isn't safe but
http://www.herbank.com/login.asp?arhuz.ru/ is okay?

The solution, in my opinion, would be to come up with a new notation that
doesn't break existing RFCs, but that still places the hostname first.

Something like http://www#user:password/path/file.cgi would be safer for the
common user, all they'd have to look at would be the first thing they see
after the http:// to determine if it is trusted. Unfortunately, the next
step will be http://www.herbank.com.naughty-phish-scheme.com/ where
naughty-phish-scheme is something less suspicious. Then we'll be right back
to where we started, and we'd still have broken or lost valuable
functionality.

It's probably too late, but rather then removing user:password support
altogether, maybe Microsoft could replace it with a dialog that informs the
user they are about to visit "session-arhuz.ru" with the username
"www.herbank.com", and an appropriate warning about not revealing sensitive
information, blahblahblah?

--
Dave Warren,
Email Address: dave.warren@devilsplayground.net
Cell: (403) 371-3470 Fax: (403) 371-3471
Toll free: (888) 371-3470 Vonage: (817) 886-0860
ICQ: 17848192 AIM: devilspgd Yahoo!: devilspgd
MSN/PASSPORT: dave.warren@devilsplayground.net

> It's probably too late, but rather then removing user:password support
> altogether, maybe Microsoft could replace it with a dialog that informs=
the
> user they are about to visit "session-arhuz.ru" with the username
> "www.herbank.com", and an appropriate warning about not revealing sensi=
tive
> information, blahblahblah?

As an answer to the question "Are you sure that you want to... bla,bla ..=
=2Eas =

this may reveal sensitive information?", 99% of the users will click "Yes=
" as =

they always do.

Even if the question is phrased "...do you wish to abort this action?", m=
ost =

users will simply try a few times by clicking "yes" and finally actually =
read =

the question and the warning before clicking "no".

The problem is that most people do not cultivate the high-grade paranoia =
that =

most readers of Bugtraq do, and that is what makes security so difficult =
to =

implement, especially if security is to be retrofitted to a protocol or =

product. People make the choices that is most convenient to their daily u=
se; =

allow everything, don't upgrade, don't patch.

In fact, most people don't even know why they should patch. I've even hea=
rd =

the urban legend that running Microsoft Update is dangerous as your compu=
ter =

may get infected by computer viruses that way.

-- =

Gunnar Ostlund Tel: +46 920 492039
Computer Support Centre Email: Gunnar.Ostlund@dc.luth.se
Lulea University of Technology
S-971 87 Lulea
Sweden

-----Original Message-----
From: David B Harris [mailto:dbharris@eelf.ddts.net]

> Or, hey, a different on-screen representation? Something like, I dunno,
> "http://user:pass@site/" being turned into "http://site/ (user: user,
> password: pass)"?

IMO, even this doesn't go far enough. We need to eliminate the use of URLs
as authenticators entirely. Sites are popping up all over the place with
*legitimate* hostnames confusingly similar to real ones. Getting tricky
with URL encoding is only part of the problem. Users need to start
*expecting* to see an SSL- or TLS-validated identity before they trust that
they're seeing content from someone they think they are. You wouldn't walk
into a store front with "Micro Soft" scrawled in crayon and reasonably
expect to receive legitimate Microsoft products in return for your cash, but
this is what people are falling victim to every day on the web.

Every non-authenticated web page needs to be treated as unauthenticated, and
browsers should make this clear up front. Users need to understand that
when they are interacting with a web page at "example.com", they're only
PROBABLY interacting with the "example.com" Internet domain. Instead, they
believe they ARE interacting (in a trustworthy fashion) with "Example
Widgets", even though there's no trusted relationship between "Example
Widgets" and example.com they can see, other than example.com saying they
are.

Eliminate a user's dependence upon the URL as an authenticator (and a search
engine, for that matter, guessing "www.<search term>.com"), and you
eliminate the bulk of the problem here. People can do all of the stupid
encoding tricks they want at that point and it won't matter, since the URL
becomes almost entirely a machine-usable piece of data anyway, and the
computer isn't easily deceived by such tricks.

David

Hello Thor,

Tuesday, February 3, 2004, 9:02:11 AM, you wrote:

TL> This has already been implemented in the out-of-schedule IE patch they
TL> released yesterday, MS04-040. This is also the first time they broke their
TL> promised monthly patch schedule, so far they have released patches in the
TL> second week of the month.

TL> http://www.microsoft.com/technet/sec...n/MS04-004.asp

There was a case of an "escaped" fix last month, wasn't there?

TL> However, if you hover your mouse over such a link you will see the status
TL> bar of the browser still displays the incorrect link. It seems like the
TL> incorrect parsing code is still there, but the current attack vector is
TL> gone - time to look for other pathways.

So this really IS a case of gutting a "feature" to spite a bug,
without actually fully fixing the bug. Or did I misunderstand you?
Were you referring to the %00 FQDN spoofing vulnerability or just the
display of the username:password in the URL bar?

I'll go answer those questions myself. *g*

Ok, I've confirmed that one (status bar showing spoofed domain with
%00) at secunia's test page. Of course, there are many other ways to
manipulate the status bar on a mouseover, but this flaw still applies
to some small extent.

http://www.secunia.com/internet_expl...spoofing_test/

The spoofing flaw does appear to be entirely gone in the URL bar,
though.

In one way or another, at any rate.

URL's spoofed with %00 in them issue an "invalid syntax" error
regardless of the state of the new registry keys mentioned in the KB.
This is done without modifying what is shown in the URL bar.
Everything is shown, including the spoofed string and the real domain.
Maybe people could be fooled into dialing a telephone number or
sending in the information by email "if this website is down due to
high demand". This isn't MS's problem IMO, though.

If the registry keys are set and no unusual characters are present,
the page loads as expected, however the username:password string is
removed from the URL bar (I havn't tested whether a basic
authentication login will still occur).

So, the bug does seem to be fixed except on the status bar when
mousing over a link that is trying to spoof a destination.

--
Best regards,
Sam mailto:sschinke@myrealbox.com

"Dave Warren" <dave.warren@devilsplayground.net> wrote:

<<big snip>>
> It's probably too late, but rather then removing user:password support
> altogether, maybe Microsoft could replace it with a dialog that informs =
the
> user they are about to visit "session-arhuz.ru" with the username
> "www.herbank.com", and an appropriate warning about not revealing sensit=
ive
> information, blahblahblah?

Yeah, just like the "The doument you are opening contains macros or
customizations. Some macros may contain viruses that could harm your
computer. [...]" warnings prevented Word macro viruses...

A user na=EFve enough to click on such a link does, in some important
sense, _want_ to visit that page. Your suggested warning is just
another thing that such users see as "getting in the way of doing what
I want to do". Therefore, if implemented it would become more part of
the problem than the solution (as users will become ever more familiar
with ignoring "warnings" and clicking through them). If you understand
users, you will know that in helping them to not shoot themselves in
the feet, the only useful appraoch is to remove everything capable of
firing the bullets (and quite a few things beside!)...

On the Word macro virus front, things got notably better _NOT_ when MS
implemented the above warning (that the users could blithely ignore and
even _disable_ right there on the warning dialog -- what a travesty of
mis-design that was!) but when it released a version of Word that
defaulted to not running macros unless they were signed with an
acceptable (as configured by the user/admin) key (there are legion
flaws in the design of this feature, but it was strong enough to
significantly impact the Word macro virus problem). In IE, removing
support for this mis-feature (read RFC 2616) will have a much greater
impact than trying to "direct" users who don't want to be directed with
"warnings" and other stuff that "gets in their way".


--
Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3529854