Subject: Re: Microsoft to Strike IE URL Passwords

From: [email-masked]
Date: Fri, 30 Jan 2004 23:51:12 -0500

Ok, uncle :)

I see what I believed and what is fact are
two different things.  I really should not
have been so lazy about pulling up 2616.

My apologies to one and all.

I guess it's back to the drawing boards 
for my stuff. Whether it currently works
or not is moot (sniff!), if it is non-compliant
then, I guess I gotta suck it up.

Best Regards,

Bob

Paul Leach wrote:
> 
> RFCs 2616 and 2396 (which updates 1738) are clear that username:password is
> NOT legal in HTTP URLs.
> 
> >From 2616:
> 
> 3.2.2 http URL
> 
>    The "http" scheme is used to locate network resources via the HTTP
>    protocol. This section defines the scheme-specific syntax and
>    semantics for http URLs.
> 
>    http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
> 
>    If the port is empty or not given, port 80 is assumed. The semantics
>    are that the identified resource is located at the server listening
>    for TCP connections on that port of that host, and the Request-URI
>    for the resource is abs_path (section 5.1.2). The use of IP addresses
>    in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). If
>    the abs_path is not present in the URL, it MUST be given as "/" when
>    used as a Request-URI for a resource (section 5.1.2). If a proxy
>    receives a host name which is not a fully qualified domain name, it
>    MAY add its domain to the host name it received. If a proxy receives
>    a fully qualified domain name, the proxy MUST NOT change the host
>    name.
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of
> > [email-masked]
> > Sent: Friday, January 30, 2004 5:27 PM
> > To: Michael Howard; [email-masked]; HTTP Working
> > Group; Michael Howard
> > Cc: Dave Kristol
> > Subject: Re: Microsoft to Strike IE URL Passwords
> >
> >
> > Michael,
> >
> > Off the top of my head, so I may be totally off base :)
> >
> > But, username:[email-masked] is a valid uri in the http
> > protocol.  It follows, therefore, that it is a valid HREF
> > value in an <A> tag. If the browser then does something other
> > than is intended when the <A> tag is invoked, then it is
> > arguably non-compliant.
> >
> > That is my argument in a nutshell.  Now, I could get all
> > scholarly and dig out all the references, but this would make
> > the argument much more obtuse and hard to follow. I would not
> > advance anything that I did not feel was supported in the
> > relevant RFC's.
> >
> > Now, as a matter of practicality, IE is a Microsoft product
> > and Microsoft can do as it wishes.  Further, it can be argued
> > that this is not a common usage of a uri.  But, it *is* used
> > and useful.  To break it would be a shame.  Especially if the
> > shortcomings can be solved another way.
> >
> > To reiterate, the two problems that are referenced fall into
> > the category of program bug, and rendering that is suitable
> > for the majority of users.  This is not a failing in the
> > usage of the particular uri format at all.
> >
> > By kicking up a fuss as early as possible, I am hoping that
> > more consideration will be given to a non-intrusive fix that
> > will leave the intended functionality intact.
> >
> > Best Regards,
> >
> > Bob
> >
> >
> > Michael Howard wrote:
> > >
> > > The plan, and it may change, is to nix username:pwd@ in a
> > url. Correct
> > > me if I'm wrong, but this format is only valid for ftp, not http.
> > >
> > > Cheers, Michael
> > >
> > > [Writing Secure Code 2nd Edition]
> > > http://www.microsoft.com/mspress/books/5957.asp
> > > [Protect Your PC] http://www.microsoft.com/protect [Blog]
> > > http://blogs.msdn.com/michael_howard
> > >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Friday, January 30, 2004 1:35 PM
> > > To: [email-masked]; HTTP Working Group; Michael Howard
> > > Cc: Dave Kristol
> > > Subject: Re: Microsoft to Strike IE URL Passwords
> > >
> > > Michael,
> > >
> > > Is this not really a rendering problem?
> > >
> > > This remark includes the "%01" problem, and user perception
> > that the
> > > leading part before the "@" is the web site.
> > >
> > > The first is a problem internal to the browser, and should be fixed.
> > >
> > > The second is a rendering problem, in
> > > that many users do not know the difference.
> > > Therefore, it is more useful to present the url to the user without
> > > the credentials portion.
> > >
> > > If the embedded credentials are permitted in a valid url,
> > and that url
> > > is embedded as, for example, the href of an <a> tag, and
> > the browser
> > > does not retrieve the referenced resource, then the browser
> > is broken.
> > >
> > > Removing this valid behaviour will, in some cases, break
> > many months
> > > of work. I am involved in one such case.
> > >
> > > Bob
> > >
> > > Michael Howard wrote:
> > > >
> > > > Only the form:
> > "http(s)://username:password@server/resource.ext"  is
> > > > being removed; basic auth is untouched.
> > > >
> > > > Cheers, Michael
> > > >
> > > > [Writing Secure Code 2nd Edition]
> > > > http://www.microsoft.com/mspress/books/5957.asp
> > > > [Protect Your PC] http://www.microsoft.com/protect [Blog]
> > > > http://blogs.msdn.com/michael_howard
> > > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]]
> > > > On Behalf Of Dave Kristol
> > > > Sent: Thursday, January 29, 2004 11:38 AM
> > > > To: HTTP Working Group
> > > > Subject: Microsoft to Strike IE URL Passwords
> > > >
> > > > <http://www.internetnews.com/dev-news/article.php/3305741>
> > > >
> > > > If I understand this article correctly, it sounds like MS IE will
> > > > remove support for Basic Authentication.  While we all agree that
> > > > cleartext passwords are evil, this sounds to me like it
> > will create
> > > > a major compatibility problem at sites that use Basic.  And note
> > > > that it
> > >
> > > > covers Basic over SSL, too, where the passwords would *not* be
> > > cleartext.
> > > >
> > > > Dave Kristol
> > >
> > > --
> > >
> > > ------------------------------------------------------------------
> > > FREE DOWNLOADS
> > >
> > > iis bandwidth protection -- http://coldlink.com/
> > >
> > > iis password protection -- http://wanderware.com/
> > >
> > > ------------------------------------------------------------------
> > >
> > > ..
> >
> > --
> >
> >
> > ------------------------------------------------------------------
> > FREE DOWNLOADS
> >
> > iis bandwidth protection -- http://coldlink.com/
> >
> > iis password protection -- http://wanderware.com/
> >
> > ------------------------------------------------------------------
> >
> >
> >
> >
> > ..
> >
> >

-- 

------------------------------------------------------------------
FREE DOWNLOADS

iis bandwidth protection -- http://coldlink.com/

iis password protection -- http://wanderware.com/

------------------------------------------------------------------

..

---

From: [email-masked]
Date: Sat, 31 Jan 2004 07:02:48 -0500

Well, I've had second thoughts.

It has occurred to me that we are really looking at
two different things, both being referred to as
URL's.

3.2.2 is really more akin to a formal specification
of what the request-uri of 5.1.2 should look like
in the HTTP protocol. Certainly, it specifies that
the host is mandatory, yet hosts are often omitted
in HTML documents.

Howver, there is nothing inherently wrong with
username:password appearing in an *HTML* document,
and the browser subsquently interpreting that
information to form a Authorization: header
in response to a WWW-Authenticate: challenge. 

As we all know, http://username:[email-masked] is not
sent literally over the wire.  And neither is
http://www.example.com:8080/index.html?var=something,
but rather 

GET /index.html?var=something HTTP/1.1
Host: www.example.com

and the client *knows* automagically to 
connect to port 8080.

To make a long story short, as long as the
over the wire protocol is respected, is there
really anything proscriptive in 2616 with regard
to the appearance in an *HTML* document? The only
thing that username:password@ causes in *HTTP*
when the browser finally gets around to it,
is the addition of:

Authorization: blahblahblah

in response to WWW-Authenticate.

To go really far out in left field, there is
nothing in 2616 to stop an html author from
displaying the username/password on the page
and asking the user to key it in when challenged.
Nor does it say that IE cannot store a username
and password for the "remember password function".

If the argument is that 3.2.2 prescribes the
semantics of the href attribute of the HTML <A>
tag, then there is a lot of broken HMTL code
out there because it quite common to use
either root relative, or relative URL's in
href attributes.  The fact that common browsers
know what to do about this would be due to
their interpretative abilities.  By extension,
username:password@ is also an interpretive
ability.

And it's all in the HTML, it's got nothing to
do with HTTP over the wire.  At least in
practical terms.

BTW, it was mentioned in a forum elsewhere
that this change would break a lot of
Paypal payment links. I don't know myself
because I do not have a Paypal vendor account.

What I am really asking is that the distinction
be made between what HTTP is, and running 
HTTP from HTML documents.  A minor distinction,
but perhaps a useful one.

Respectfully,

Bob

-- 

..

---

From: Julian Reschke <[email-masked]>
Date: Sat, 31 Jan 2004 13:55:37 +0100

[email-masked] wrote:

> ...
 > ...

As a matter of fact, RFC2396 and the HTML spec describe what can go into 
an HTML href. The URL format used in HTTP messages is completely 
irrelevant here. And yes, of course relative URIs are allowed here.

 > ...

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: "Paul Leach" <[email-masked]>
Date: Fri, 30 Jan 2004 20:36:32 -0500 (EST)

3.2.2 http URL

---

From: Peter Watkins <[email-masked]>
Date: Sat, 31 Jan 2004 13:49:59 -0500

Paul,

In brief:
  1) we use ftp://user@host/path at work; will the update break this?
  2) the "0x01" Location display bug seems to provide an attack vector 
for ftp: URLs

KB 834489 makes no mention of ftp:// URLs. At work we have a number of 
users who have bookmarked internal FTP servers as ftp://user@host/path 
in IE. Will this upcoming patch also break user[:pass]@ within ftp: 
URLs? How about other schemes that use the Common Internet Scheme Syntax 
[CISS] outlined in RFC 1738?

As you might guess, I believe it would be nice if KB 834489 were updated 
to explicitly address ftp: and other schemes handled by IE.

And I wonder about the potential for attacks based on ftp: URLs; if the 
IE team's response to the 0x01 is eliminating CISS, then I'd expect them 
to eliminate it throughout IE, affecting more than just http(s) schemes.

It looks like 0x01/CISS is a concern in IE6/XP for ftp: URLs. Some quick 
testing shows that clicking on a link coded as
   <a 
href="ftp://anonymous:[email-masked]/pub/">go</a>
displays in the IE Location bar as "ftp://anonymous:www.microsoft.com" 
-- so presumably if an attacker made their FTP server ignore both 
username and password contents, the attacker could use HTML like
   <a href="ftp://www.microsoft.com%01:[email-masked]/pub/">go</a>
or perhaps set up "www" as the anonymous account, ignore the password 
contents, and use an attack URL like
   <a href="ftp://www:[email-masked]/pub/">go</a>
to trick the intended victim. Sure, "ftp://www.microsoft.com" and 
"ftp://www:microsoft.com" don't look quite right to those of us who are 
RFC-literate (neither has a URI/path), but they might look good enough 
to fool a good number of users (hey, we're dealing with users who still 
double-click any attachment that comes their way).

Thanks & happy new year,

Peter

---

From: Peter Watkins <[email-masked]>
Date: Sat, 31 Jan 2004 14:34:00 -0500

> In brief:

<snip>

My apologies to all; that message had nothing to do with this WG's 
business, and I only intended it for Paul. I'm sorry for the waste of 
bandwidth and mailbox space.

-Peter