On Mon, 14 Jun 2010 20:58:07 +0200, Adam Barth <[email protected]> wrote:
On Tue, Feb 16, 2010 at 6:28 AM, Anne van Kesteren <[email protected]>
wrote:
On Sun, 06 Dec 2009 17:19:59 +0100, [email protected] <[email protected]> wrote:
What about redirects that require different Authentication methods?
How would that work?
Testing shows that Firefox, Chrome, and Safari show an HTTP Auth
dialog when making an XHR from a non-authenticated page to a URL that
requires basic authentication.
If an page with basic auth makes an XHR to a URL that requires digest
auth, the user is prompted again for their user name and password:
Username: ggg
Password: ttt
http://webblaze.org/abarth/tests/xhrauth/basic/todigest.html
In the reverse situation, behavior differs by browser.
http://webblaze.org/abarth/tests/xhrauth/digest/tobasic.html
Here, Firefox allows the downgrade silently, but Safari and Chrome
show the auth dialog again.
I can test redirects too, if you like.
If the user is now under (for example) a digest auth session, but the
page/redirected page responds with Authentication: Basic, does the UA
should prompt the user for user/password again? This is a dangerous
downgrade attack (think active network attackers).
Not sure. I would appreciate advice here. Also based on what we need
with
respect to legacy content.
I'd recommend the Safari behavior, which is to re-prompt in these
cases rather than the Firefox behavior, which is to silently allow the
downgrade.
If the session already has a username/password HTTP auth session and
open() has user/pass? it should be replaced by the new one? Are you
sure?
Are you really sure?
It would be good to get advice here too.
This is slightly harder to test without a network sniffer, but here's
a test case:
http://webblaze.org/abarth/tests/xhrauth/basic/withotheruser.html
When you visit that page, you need to type in your ggg/ttt
username/password combination. In Firefox, Chrome, and Safari, the
page prompts you again for a username/password because the page tries
to make an XHR as hhh/qqq (this username doesn't exist on the server),
which suggests that XHR should use the arguments to open instead of
the ambient authentication. Notice that in Safari, the prompt is
pre-filled with the username hhh, making it clear that the hhh/qqq
authentication failed.
Your text here makes is sound like you think there is some danger in
this behavior. Would you care to elaborate?
There are several attack scenarios there.. and unless I missed
something
in my opinion the specification is not specific enough =/
I can fix it if someone helps me out with the details.
Let me know if there are other scenarios you'd like to test. The
tests are pretty easy to run once you have a testbed working.
I don't know too much about HTTP auth, so let me know if I've screwed
up the test cases.
Thanks a lot Adam! Thinking about it some more it seems that most of this
is not really in scope of the XMLHttpRequest specification. XMLHttpRequest
just indicates when the open() provided arguments are to be used. When
authentication is considered to be a failure (e.g. downgrade) is not
really up to XMLHttpRequest.
I'd be open to making clarifications here but I cannot really think of
anything that would help.
--
Anne van Kesteren
http://annevankesteren.nl/
