MS to stop allowing passwords in URLs

[McAllister, Andrew]

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@www.somehost.com/

See http://support.microsoft.com/default.aspx?scid=3Dkb;en-us;834489

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.=20

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.
Click the applet and it opens a browser window with the
id:passowrd@server.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.

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).

Andrew McAllister
University of Missouri

[Vinny Abello]

Interestingly, I've already found that this patch doesn't fix this problem
when using IE as an object in VB6. You can still programmatically call an
instance of IE as a browser object and use that format to login to a web site.

At 05:54 PM 1/28/2004, McAllister, Andrew 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@www.somehost.com/
>
>See http://support.microsoft.com/default.aspx?scid=kb;en-us;834489
>
>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.
>
>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.
>Click the applet and it opens a browser window with the
>id:passowrd@server.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.
>
>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).
>
>Andrew McAllister
>University of Missouri


Vinny Abello
Network Engineer
Server Management
vinny@tellurian.com
(973)300-9211 x 125
(973)940-6125 (Direct)
PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A

Tellurian Networks - The Ultimate Internet Connection
http://www.tellurian.com (888)TELLURIAN

There are 10 kinds of people in the world. Those who understand binary and
those that don't.

[Fergus Brooks]

Andrew - I agree entirely about "Remember my password" and cookies being
no safer. Password saving on shared machines is a nightmare - especially
as machines built with XP by default allow you to have a passwordless
generic login to the machine.

Seeing some of the passwords that come up on machines in cafes etc makes
me understand why there is so much shared-machine related fraud and
misuse of people's webmail accounts.

Also I have found that often to get to an FTP server on the Internet
(depending on the proxy, connection, firewall etc) that you need to use
this format. Taking this functionality away will certainly make it
harder for a lot of support people and consultants to do their jobs.

Back to having *every imaginable tool* in the CD case when visiting
client sites. Or maybe we should just starting putting all our good
stuff up on anonymous FTP sites?

Rgds...


-----Original Message-----
From: McAllister, Andrew [mailto:McAllisterA@umsystem.edu]
Sent: Thursday, 29 January 2004 6:54 AM
To: bugtraq@securityfocus.com
Subject: MS to stop allowing passwords in URLs


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@www.somehost.com/

See http://support.microsoft.com/default.aspx?scid=kb;en-us;834489

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.

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.
Click the applet and it opens a browser window with the
id:passowrd@server.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.

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).

Andrew McAllister
University of Missouri
--
This message has been scanned by AVMail

[N407ER]

McAllister, Andrew 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@www.somehost.com/
>
> See http://support.microsoft.com/default.aspx?scid=kb;en-us;834489
>
> 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.
>
> 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.
> Click the applet and it opens a browser window with the
> id:passowrd@server.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.
>
> 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).
>
> Andrew McAllister
> University of Missouri
>

Despite what MS's notice says, presumably the primary motive for this
was to avoid the URL spoofing detailed here
(http://www.microsoft.com/technet/treeview/?url=/technet/security/bulletin/MS04-004.asp).
In fact, that webpage specifically states that it is to fix ``three
newly-discovered vulnerabilities'' (``newly=discovered'' apparently
being a relative term), including ``a misrepresentation of the URL in
the address bar of an Internet Explorer window''.

So the security reasons they cite on the page you link to probably
aren't that they consider that syntax to be insecure relative to cookies
or ``Remember My Password'', but that the best way to avoid URL spoofing
they could come up with (after, apparently, months of effort) was to
eliminate the feature alltogether.

I can think of another great way to fix the vulnerabilities in Windows.
It's called fdisk.

Hope that helps!

[Francis Favorini]

Vinny Abello [mailto:vinny@tellurian.com] wrote...
> Interestingly, I've already found that this patch doesn't fix
> this problem when using IE as an object in VB6.

From the KB article:
http://support.microsoft.com/default.aspx?scid=kb;en-us;834489
"After you install the 832894 security update, you can set registry values
to use this new behavior in other programs that host the Web browser control
or to disable this new behavior for Windows Explorer and Internet Explorer."

The specifics of the registry values are also documented therein.

-FF

[Andrew Harwood]

RFC 1738 (http://www.ietf.org/rfc/rfc1738.txt) states is section 3.3
(Note the last sentence):

-------------------
-- begin excerpt --
-------------------
An HTTP URL takes the form:

http://<host>:<port>/<path>?<searchpart>

where <host> and <port> are as described in Section 3.1. If :<port>
is omitted, the port defaults to 80. No user name or password is
allowed.
-----------------
-- end excerpt --
-----------------

So Microsoft has finally just adopted the RFC standard, not broken it.

Anyway, you can always re-enable the old system, as documented in the
Microsoft document you link, viz:

-------------------
-- begin excerpt --
-------------------
How to disable the new default behavior for handling user information in
HTTP or HTTPS URLs
To disable the new default behavior in Windows Explorer and Internet
Explorer, create iexplore.exe and explorer.exe DWORD values in one of
the following registry keys and set their value data to 0:

For all users:
HKEY_LOCAL_MACHINE\Software\Microsoft\Internet
Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME _PASSWORD_DISABLE

For the current user only:

HKEY_CURRENT_USER\Software\Microsoft\Internet
Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME _PASSWORD_DISABLE
-------------------
-- end excerpt --
-------------------

The other options are more secure in some ways, most specifically if the
address is visible anywhere on screen, there is no reference to the
username/password for anyone who passes by. I have this problem with our
help desk at work - they have a PC which has the username/password of
our network monitoring system visible in the URL, which any client who
visits can see. Which is one reason why I will only give them read
access :-)

Further, the other options (at least yet) have no ways of breaking them
that will hide the real URL you are visiting, since they only handle the
username/password, and have no linkage to the actual web address.

That's my 2c anyway.

--
Andrew Harwood
aaharwood@bigpond.com

-----Original Message-----
From: McAllister, Andrew [mailto:McAllisterA@umsystem.edu]
Sent: Thursday, 29 January 2004 09:24
To: bugtraq@securityfocus.com
Subject: MS to stop allowing passwords in URLs


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@www.somehost.com/

See http://support.microsoft.com/default.aspx?scid=kb;en-us;834489

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.

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.
Click the applet and it opens a browser window with the
id:passowrd@server.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.

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).

Andrew McAllister
University of Missouri

[Ansgar -59cobalt- Wiechers]

On 2004-01-28 McAllister, Andrew wrote:

[ MS about to invalidate usage of http://<user>:<pass>@<host> in IE ]

> 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).

There is no legitimate use of this syntax and never was. Although
RFC 2396 does specify a generic URI syntax allowing

<user>:<pass>@<host>:<port>

it expressly excludes those URLs whose syntax is specified in RFC 1738:

| This document updates and merges "Uniform Resource Locators" [RFC1738]
| and "Relative Uniform Resource Locators" [RFC1808] in order to define
| a single, generic syntax for all URI. It excludes those portions of
| RFC 1738 that defined the specific syntax of individual URL schemes;
| those portions will be updated as separate documents, as will the
| process for registration of new URI schemes.

RFC 1738 clearly says:

| An HTTP URL takes the form:
|
| http://<host>:<port>/<path>?<searchpart>

So do RFCs 1945 and 2616.

Regards
Ansgar Wiechers

[3APA3A]

Dear McAllister, Andrew,


--Thursday, January 29, 2004, 1:54:00 AM, you wrote to bugtraq@securityfocus.com:



MA> Anyone have any comments regarding legitimate uses of this syntax and
MA> Microsoft removing it from their browser? (and presumably the OS since
MA> the browser IS the OS).

ftp://user:pass@site

is _only_ way to authenticate FTP through HTTP proxy (if not given,
proxy always use anonymous).

--
~/ZARAZA
Âñåãäà áóäåì ðàäû ïîñëóøàòü âàøå ÷èðèêàíüå (Òâåí)

[Dave McCormick]

Andrew,

You said:
<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@www.somehost.com/

I wanted to point out the option to make a reg key change that will
maintain the user@ functionality instead of utilizing the new default
behavior that occurs by applying the patch.

<snipped from MS article>
How to disable the new default behavior for handling user information in
HTTP or HTTPS URLs To disable the new default behavior in Windows Explorer
and Internet Explorer, create iexplore.exe and explorer.exe DWORD values
in one of the following registry keys and set their value data to 0:

For all users:
HKEY_LOCAL_MACHINE\Software\Microsoft\Internet
Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME _PASSWORD_DISABLE

For the current user only:

HKEY_CURRENT_USER\Software\Microsoft\Internet
Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME _PASSWORD_DISABLE


Overall, I think that MS is doing the right thing with this. I cannot
count how many html email's I've received that are supposedly from PayPal,
or Visa or <insert your favorite finacial organization here> wherein a
kiddie wannabe with minimal english skills asks "please verafy your
accoont information". That information is piped to a cgi on a hacked box
somewhere that snarfs the info then redirects you to the real site that is
supposedly asking for the info.

*yawn*

I guarantee that there are people out there (although probably not on this
list) that have swallowed the bait and forwarded their credit card #, SSN
#, all their pin numbers to every bank account they own as well as their
grandmothers bra size because they were presented with an official looking
html email that asked for the info. Why else do so many of these types of
con jobs flood the net?

This is getting to be as bad as the Nigerian email scam. You know the one
that starts out, "Dear Sir, <insert impressive title of some 3rd world
country here> left me 10 million dollars and I need your help."

Overall I think it's the right thing to do and I'm glad that MS is doing
it.

just my .02 so please, flames > /dev/null

Regards,

Dave McCormick
dave@fred.net_nospam.com
mccormic@xecu.net_nospam.com

"Kool-Aid anyone?" - Bill Gates

[Thor Larholm]

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

http://www.microsoft.com/technet/security/bulletin/MS04-004.asp

Navigating to a link with Basic Authentication details embedded
(user:password@host) now yields an "invalid syntax error". Embedding HTTP
authentication details as part of the URL is not part of the HTTP RFC in the
first place, but is allowed in a generic URI. RFC 1738 has no mention of
authentication in the syntax of an HTTP URL (see page 8) and its
implementation in browsers has been an exception - much like the
Content-Disposition MIME header that is widely implemented in the HTTP
handling of browsers.

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



Regards

Thor Larholm
PGP: 0x5A276569
6BB1 B77F CB62 0D3D 5A82 C65D E1A4 157C 5A27 6569

PivX defines "Proactive Threat Mitigation". Get a FREE Beta Version of
Qwik-Fix <http://www.qwik-fix.net>


-----Original Message-----
From: McAllister, Andrew [mailto:McAllisterA@umsystem.edu]
Sent: Wed 1/28/2004 2:54 PM
To: bugtraq@securityfocus.com
Cc:
Subject: MS to stop allowing passwords in URLs


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@www.somehost.com/

See http://support.microsoft.com/default.aspx?scid=kb;en-us;834489

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.

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.
Click the applet and it opens a browser window with the
id:passowrd@server.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.

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).

Andrew McAllister
University of Missouri

[Sam Schinke]

Hello Andrew,

Wednesday, January 28, 2004, 2:54:00 PM, you wrote:

MA> I just read that Microsoft will stop allowing IDs and passwords to be
MA> embedded in URLs used by Internet Explorer. So you will no longer be
MA> able to use a URL like https://user:password@www.somehost.com/

MA> See http://support.microsoft.com/default.aspx?scid=kb;en-us;834489

MA> Their reasoning is that this will mitigate status bar spoofing as has
MA> recently been discussed here and in other forums.

That reasoning is also in the KB article and the bug in this portion
of IE is obliquely acknowledged.

MA> The article even goes
MA> so far as to admit that recent versions of IE show only the URL before
MA> the @ sign while older versions do not.

The article states the opposite. It states that earlier versions
displayed the entire URL (including authentication parts) whereas IE6
conceals the authentication portion and displays starting with the
hostname. This is, of course, excluding cases that use known flaws in
the URL parsing and is also unique to windows 2003.

MA> Apparently MS has decided that this RFC URL syntax is simply too
MA> dangerous to allow in their products.

If you read the HTTP 1.1 specs closely (RFC 2616) you will find that a
HTTP URL does NOT include the username:password in the syntax.

RFC 1738 and RFC 2396 specify the format of "generic" URL's but RFC
1738 specifically refers to RFC 2616 for the format of HTTP URL's.

RFC's 1738 and RFC 2396 both discourage the use of username:password
information in URLs as well.

That said, I liked the ability to source-specify login information as
well. I think we may all be just a little shocked to see MS removing
functionality in the interests of security. I wonder if this is
because they were unable to fix the %00 spoofing or had too many other
issues with this syntax.

Another plus is that this change may see an upsurge in the use of
Mozilla, which still supports this syntax.

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

[Nick FitzGerald]

"McAllister, Andrew" <McAllisterA@umsystem.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@www.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@server.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@www.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

[Paul Smith]

At 22:54 28/01/2004, McAllister, Andrew 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@www.somehost.com/
>
>See http://support.microsoft.com/default.aspx?scid=kb;en-us;834489

>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).

Personally, I think it's a reasonable step - these spoofed URLs are a big
problem for many people.

You can disable the functionality in IE if you wish (the above link has
details)

I think I'd prefer it if you could override it on a site by site basis (eg
using the 'trusted sites' functions, or by having the username:password@url
in your IE 'favourites')

(Although, having said that, having spammers use http://username@url is
quite a good trigger to put in email anti-spam rules, as I've never seen
anyone use that format in an email link legitimately..)
Paul VPOP3 - Internet Email Server/Gateway
support@pscs.co.uk http://www.pscs.co.uk/

[Richard M. Smith]

>>> 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).

It always was a bad idea to put plaintext passwords in URLs because it
encouraged users to give away passwords in links on public Web pages. The
spoofing games were the second big problem with them that showed up later.
Glad to see Microsoft getting rid of the feature.

Richard

[Joe Weisenberger]

On Tue, 3 Feb 2004, Fergus Brooks wrote:

snipped ...
> Also I have found that often to get to an FTP server on the Internet
> (depending on the proxy, connection, firewall etc) that you need to use
> this format. Taking this functionality away will certainly make it
> harder for a lot of support people and consultants to do their jobs.
>
snipped ...

I just applied this patch (KB832894 MS-04-004) to IE 6.0 on W2K to check
handling of ftp url's. After the patch, ftp://username:password@site still
works. I think the change only applies to http, https.

[David B Harris]

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 ;)

[Dave Warren]

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

[Gunnar Östlund]

> 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

[NESTING, DAVID M]

-----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

[Sam Schinke]

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/security/bulletin/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_explorer_address_bar_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

[Nick FitzGerald]

"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