Re: [xhr] authorization

On Mon, 14 Jun 2010 20:58:07 +0200, Adam Barth <w3c@adambarth.com> wrote:
> 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.

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/

Received on Tuesday, 15 June 2010 11:58:04 UTC