778548 - CORS preflight fails with Basic Authentication

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect, P5)

Description

[ewolfman]

Attachment: FF_authentication_error.png

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
Build ID: 20120713134347

Steps to reproduce:

Attempted to call a web service with Basic Authentication, with preflight. 

Steps to reproduce:
            var invocation = new XMLHttpRequest();
            var url = 'http://OtherServer/MyService.asmx/HelloWorld';
            var params = JSON.stringify({'name':'Joe'});
            invocation.open('POST', url, true);
            invocation.setRequestHeader('Authorization', 'Basic <base 64 credentials>');
            invocation.setRequestHeader('Content-Type', 'application/json');
            invocation.setRequestHeader("Content-length", params.length);
            invocation.withCredentials = true; 
            invocation.onreadystatechange = function () {
                if (invocation.readyState == 4) {
                    alert(invocation.responseText);
                }
            };
            invocation.send(params);

The IIS server is configured to return the following headers:
        <add name="Access-Control-Allow-Methods" value="POST,GET,OPTIONS" />
        <add name="Access-Control-Allow-Origin" value="http://origin-name" />
        <add name="Access-Control-Allow-Headers" value="Content-Type,Authorization" />
        <add name="Access-Control-Allow-Credentials" value="true" />




Actual results:

The web server returns a 401 for the preflight because the Authorization header is not being sent at that point, and as a result FF does not proceed to make the original request (with the Authorization header). BTW Chrome ignores the 401 on the OPTIONS and proceeds as expected to the original request.

withCredentials doesn't seem to have any effect whatsoever in this case, so omitting the client and server credentials is meaning-less


Expected results:

Obviously the server will return a 401 for the preflight because the Authorization header is not sent. Therefore I expect OPTIONS with a return code of 401 to be ignored in order to allow the original request to be processed with the Basic Authentication 'Authorization' header, just like in Chrome.

Comment 1

[ewolfman]

BTW this resembles a conversation in #597301

Comment 2

[Boris Zbarsky [:bzbarsky]]

> Obviously the server will return a 401 for the preflight because the Authorization header
> is not sent.

That would be a bug in the server, if so, if it actually wants to make the data accessible.

Per spec, an error response to the Options request requires that the original request not be made.  In particular, see http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html#preflight-request which clearly says:

  
  If the response has an HTTP status code that is not 200
    Apply the network error steps.

I'm surprised that you say Chrome does something different.  Adam, do you know what that's about?

Comment 3

[Boris Zbarsky [:bzbarsky]]

And yes, this is somewhat like bug 597301 except the spec has been clarified since then.

Comment 4

[ewolfman]

Even if the spec says that, it does not make sense. Obviously the server would fail the authentication because no authorization header is sent at that stage. So all requests that perform a preflight to a non-anonymous web server would fail at this point - where's the logic in that?

Moreover, in IIS 6 or IIS7 with a classic App Pool one cannot configure the server to return a return code other than 401 in such a case.

And yes - this works in Chrome (v. 20)

Comment 5

[ewolfman]

Attachment: Chrome ignores 401 on the OPTIONS result

Attached is a screenshot from Chrome. Chrome ignores 401 on the OPTIONS request, thus allowing the original request to be authenticated using the Authorization header - as expected.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> Even if the spec says that, it does not make sense.

Sure it does.  The point of the preflight is to avoid making the actual request unless the server opts in.  Any browser that ignores failures on the preflight and goes on to make the actual request is a security hole allowing cross-site attacks.

> Obviously the server would fail the authentication because no authorization header is
> sent at that stage.

Only if the server tries to authenticate preflights.  Which it shouldn't, since those never send any authentication information!

> Moreover, in IIS 6 or IIS7 with a classic App Pool one cannot configure the server

That's a problem for people using those servers, but doesn't mean that everyone else should be insecure as a result.

I reported http://code.google.com/p/chromium/issues/detail?id=139566

Comment 7

[Boris Zbarsky [:bzbarsky]]

Note, by the way, that if you really think the spec should change you should raise that on [e-mail]

Comment 8

[ewolfman]

It will be interesting to see how Chrome will reply here...
I have emailed to w3 as you suggested.

I think that although you have a point with regards to the current spec, there is a real issue here. If the preflight is supposed to negotiate headers and origins and OK the requests, either it should be determined that it does not authenticate (and therefore should ignore 401), or it should pass the credentials to negotiate them as well. 

Although you claim that "this is a problem for people using those servers", there are quite a few of those people... and they can't be ignored...

Comment 9

[Boris Zbarsky [:bzbarsky]]

Passing credentials with the preflight is a security risk; that's why it doesn't do that....

I realize that a lot of people use the servers in question; the question is whether their setup can be made to work in spite of their servers' limitations without making _other_ server setups vulnerable in the process.

Comment 10

[ewolfman]

I'll try to see whether I can configure IIS Classic App Pool to override the default 401 and will report back if successful. I don't think it's possible, but I'll give it (another) shot. Naturally it's possible to set the security to anonymous and then manually return 401 when needed, but that's even a greater risk IMHO.

BTW: for IIS Integrated App Pool this is very easy to overcome.

Comment 11

[Boris Zbarsky [:bzbarsky]]

ewolfman, does http://nightly.webkit.org/ show the same behavior for you as Chrome does?

Comment 12

[ewolfman]

Yes, it does.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Thank you for checking that!

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

(In reply to ewolfman from comment #8)
> It will be interesting to see how Chrome will reply here...
> I have emailed to w3 as you suggested.

Could you post a link to the email thread?
I can't see it http://lists.w3.org/Archives/Public/public-webapps/

Comment 15

[ewolfman]

I don't see it either. I got the following notice (also when trying to resend):

"Thank you, your message has now been marked as approved for archiving on our site. It may be subject to further delays before being distributed to the list; for example, it will be checked for viruses and spam, and tested against various list-specific posting restrictions."

Comment 16

[Olli Pettay [:smaug][[e-mail]]]

You may need to subscribe to that list. Search for public-webapps in http://lists.w3.org/Archives/Public/

Comment 17

[ewolfman]

Here goes: http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0252.html

Comment 18

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.