580353 - Asynchronous cross origin XMLHttpRequest doesn't expose 401 response when withCredentials is false

Status: REOPENED

(Core :: XML, defect)

Description

[Alexey Proskuryakov]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; en-us) AppleWebKit/533.17.7 (KHTML, like Gecko) Version/5.0.1 Safari/533.17.7
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; en-US; rv:2.0b2pre) Gecko/20100709 Minefield/4.0b2pre

Related to bug 282547 and to <https://bugs.webkit.org/show_bug.cgi?id=41531>.

If credentials cannot be sent with a cross-origin XMLHttpRequest due to withCredentials being false, the 401 response needs to be reported back to the caller (assuming the 401 had appropriate cross-origin response headers, of course). Currently, Firefox fails the request and dispatches an error event.

This applies to both sync and async requests.

Reproducible: Always

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

This is more or less by design (though the design might be non-ideal). Currently the spec says that any failed request, including any request that results in a 4xx or 5xx result, is supposed to deny access.

Also, even if exposed the fact that there was a 401 response, the spec forbids you from supplying a username/password in order to prevent distributed dictionary attacks.

Comment 2

[Alexey Proskuryakov]

> including any request that results in a 4xx or 5xx result, is supposed to deny access 

I cannot find that in CORS or XHR2 specs. Specifically, <http://dev.w3.org/2006/waf/access-control/#simple-cross-origin-request0>, <http://dev.w3.org/2006/waf/access-control/#cross-origin-request-with-preflight0> and <http://dev.w3.org/2006/waf/access-control/#resource-sharing-check> don't list any such restrictions AFAICT.

> Also, even if exposed the fact that there was a 401 response, the spec forbids
> you from supplying a username/password in order to prevent distributed
> dictionary attacks.

Yes, authors won't be able to provide alternative auth UI for cross-origin XHR.

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

The spec is more vague than I remember. But in [1] it says

"If there is a network error, Apply the network error steps."

But I couldn't find a clear definition of what constitutes a network error. However the http spec says that all 4xx and 5xx codes are error codes.

[1] http://dev.w3.org/2006/waf/access-control/#simple-cross-origin-request0

Comment 4

[Alexey Proskuryakov]

In WebKit, we consistently (I hope) don't treat 4xx and 5xx as network errors. I expect that Firefox also usually doesn't follow network error steps for those, but I didn't analyze that in enough detail to confidently claim so.

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

It depends entirely on what you mean by "network error". The term needs to be defined in the CORS spec. I do know that when we discussed this at the meeting in redmond we talked about making all 4xx and 5xx pages result in denial of access to the resource.

I raised the question on the webapps list.

Comment 6

[Alexey Proskuryakov]

The spec has been updated to say that a network error is:  "A DNS error, TLS negotation failure, or other type of network error occured. This does not include HTTP responses that indicate some type of error, such as HTTP status code 410."

Comment 7

[Gregor]

I can confirm this issue.

Here my example code, which uses an example hosted by mozilla itself (https://developer.mozilla.org/En/Server-Side_Access_Control#section_4):

    xhr = new XMLHttpRequest();
    xhr.onreadystatechange = function(){
      console.log('wtf?', xhr.readyState, xhr.status)
    }

    xhr.open('POST','http://aruner.net/resources/access-control-with-post-preflight/',true);
    data ='<me>is good.</me>'
    xhr.setRequestHeader('Content-Type','application/xml');
    xhr.setRequestHeader('X-PINGARUNER','test');
    xhr.send(data);

     
xhr.status should be 403, but it is 0 instead.
The Server response is:

HTTP/1.1 403 Access Forbidden
Date: Fri, 28 Jan 2011 15:59:42 GMT
Server: Apache
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 48
Content-Type: text/plain

You cannot repeat this request

Comment 8

[Gregor]

I'd like to add that this is not limited to non-credential requests. Same behavior for withCredentials being true

Comment 9

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 580353 - do not set Authentication header for CORS-tainted 401 responses; r?valentin

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c16184c1170a
do not set Authentication header for CORS-tainted 401 responses; r=valentin,necko-reviewers

Comment 11

[Serban Stanca [:SerbanS]]

Backed out for causing wpt failures in audioworklet.https.sub.html.

• Backout link
• Push with failures
• Failure Log
• Failure lines: - TEST-UNEXPECTED-NOTRUN | /fetch/metadata/generated/audioworklet.https.sub.html | sec-fetch-site - Cross-Site -> Same Origin - expected PASS

Comment 12

[Thomas Wisniewski [:twisniewski]]

Ah, so I was too optimistic about the expectations for that test. I'll re-land with more realistic ones.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bbd42656d00d
do not set Authentication header for CORS-tainted 401 responses; r=valentin,necko-reviewers

Comment 14

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/bbd42656d00d

Comment 15

[Valentin Gosu [:valentin]]

Reopened for causing regressions. Backed out in bug 1855650 comment 9

Comment 16

[Auth0]

When will this fix be ported back to FF 118.0.X?

Comment 17

[Zack McCauley]

This issue is also occurring on macOS 13.x and 14.x on 118.0.x.

Comment 18

[Auth0]

https://hg.mozilla.org/releases/mozilla-beta/rev/5828ab7770ea is the revert commit. Can it be backported to 118?

Comment 19

[Mike Kaply [:mkaply]]

The backout should be in the next 118 dot release.