Same Origin Policy and HTTP Authentication

[Chirag Shah <[e-mail]>]

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