Subject: Same Origin Policy and HTTP Authentication

From: Chirag Shah <[email-masked]>
Date: Sun, 05 Dec 2010 18:43:27 +0000

Hey httpbis,

Cross Site HTTP Authentication seems is an obscure phishing vector
that’s often overlooked across the web and sometimes difficult to
workaround. When the WWW-Authenticate header is presented to a
user-agent, it will prompt the user for a user name and password .

This is a problem because when a webpage is loaded, any external
resource requested by that page can request HTTP Authentication and
trigger this dialog. At this point, it isn't entirely obvious that the
user name/password is being sent to the external resource.

One way to address this issue is by disallowing HTTP Authentication
for external resources loaded by a webpage by following a variant of
the same-origin-policy.

Proposed change in user agent behavior:
When the page http://good.com/resource is rendered, the following
table outlines how external resources (requiring Authentication) could
be treated.

http://evil.com/auth.png           -      Auth Failure - Different domain
http://good.com/auth.png        -      Auth Success - Same domain
ws://good.com/secure.htm     -     Auth Failure Different protocol
http://good.com:99/auth.png   -      Auth Failure - Different port
http://1.good.com/auth.png     -      Auth Failure - Different host

Does it make sense to update RFC 2617 to account for this issue?

References:
Cross Site HTTP Authentication:
http://code.google.com/p/google-caja/wiki/PhishingViaCrossSiteHttpAuth
HTTP Authentication: http://www.ietf.org/rfc/rfc2617.txt
The Web Origin Concept: http://tools.ietf.org/html/draft-abarth-origin-06

Thank you,
Chirag Shah - http://chiarg.com

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Dec 2010 10:53:35 +1100

Chirag,

Changing how HTTP authentication works is explicitly out of scope for this WG, although you will likely find people willing to discuss it here.

Although there are a number of places that might be appropriate for this discussion, it might actually be most helpful for you to give this as feedback to the W3C CORS specification:

  http://www.w3.org/TR/cors/

... as they're discussing what is effectively a policy mechanism for cross-site requests.

Kind regards,

--
Mark Nottingham   http://www.mnot.net/

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 07 Dec 2010 11:09:03 +0100

On Tue, 07 Dec 2010 00:53:35 +0100, Mark Nottingham <[email-masked]> wrote:
> Although there are a number of places that might be appropriate for this  
> discussion, it might actually be most helpful for you to give this as  
> feedback to the W3C CORS specification:
>

Actually, no. It is for new types of cross-origin requests that are not  
possible today.

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 09 Dec 2010 03:12:51 +0100

* Mark Nottingham wrote:
>Changing how HTTP authentication works is explicitly out of scope for
>this WG, although you will likely find people willing to discuss it
>here.

Well, "It will also incorporate the generic authentication framework
from RFC 2617, without obsoleting or updating that specification's
definition of the Basic and Digest schemes." is part of the charter,
and the concern raised by Chirag Shah falls into that in that it's a
security concern if you have a resource that transcludes other re-
sources where one or more of them require authentication, you get a
popup, and aren't actually sure who is requesting the password.

I've run into this myself a couple of times, say on W3C pages where
the access control has been misconfigured, so you get, say, team-only
images on a member-only page, or member-only images on a public page,
or even attachments in the list archive referencing member-only things
on the main site, sometimes caused by W3C mirrors being out of sync
with the main site.

While we are not in the business of saying "If a HTML page does this,
then don't prompt the user for a password" or anything like that, it
is something we need to mention in the security considerations if we
include the "generic authentication framework", given how very common
resources transcluding other resources are in the context of HTTP.

(That could be as simple as reminding readers that such situations
may confuse users so interactive user agents need to pay special
attention to that.)
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/