Re: [xhr] authorization (was: Re: call for reviewers: XMLHttpRequest Last Call)

Sorry to resurrect this old thread, but Anne asked me to comment.

On Tue, Feb 16, 2010 at 6:28 AM, Anne van Kesteren <annevk@opera.com> wrote:
> On Sun, 06 Dec 2009 17:19:59 +0100, sird@rckc.at <sird@rckc.at> 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.

Adam

Received on Monday, 14 June 2010 18:58:59 UTC