839917 - CORS requests don't cache authentication

Status: RESOLVED INVALID

(Core :: Networking: HTTP, defect)

Description

[Paul Eipper]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:21.0) Gecko/20130201 Firefox/21.0
Build ID: 20130201030927

Steps to reproduce:

1. Construct and open a xhr GET to a CORS (allow-credentials enabled) basic auth endpoint, setting the Authorization header.

2. Open a new xhr with the same parameters, this time without setting the Authorization header.


Actual results:

Second request fails with 401.


Expected results:

Firefox should have cached the authentication for the domain, as it does for non-CORS requests.

Comment 1

[Ioana (away)]

Can you reproduce this issue in safe mode? What about with a clean profile?
http://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode
http://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

Comment 2

[Paul Eipper]

I can confirm it occurs on a clean profile and in safe mode.

I created a minimal test website for the issue. Should be set as the url in the bug report.

Comment 3

[Boris Zbarsky [:bzbarsky]]

> Firefox should have cached the authentication for the domain,

The caching is in the user-facing UI, to avoid multiple prompts.  It doesn't sound to me like that was ever invoked in the case described in comment 0, so I wouldn't expect anything to be cached here...

Over to networking to verify, but afaict everything is behaving as it should.

Comment 4

[Paul Eipper]

The original report is actually regarding the difference in handling of authentication for a same-origin request vs a cross-origin one.

Notice also a difference between those requests is that for the same-origin request the credentials are passed through `XMLHttpRequest.open` function, while for CORS that doesn't work, and requires the Authorization header to be set in the code manually.

Maybe that is the bug which causes the browser to bypass caching and present different behaviour?

Comment 5

[Boris Zbarsky [:bzbarsky]]

If you pass the credentials via arguments, then the code that would normally set up the Authorization header caches the credentials.

But if you manually set up Authorization yourself, that code is never invoked, hence can never cache anything...

Comment 6

[Paul Eipper]

Thank you, so the bug is indeed in that the `XMLHttpRequest.open` with username and password parameters does not setup the Authorization header when performing a CORS request.

Actually, passing the extra parameters causes the request to fail with `NS_ERROR_DOM_BAD_URI: Access to restricted URI denied`.

Comment 7

[Boris Zbarsky [:bzbarsky]]

When performing a CORS request via XHR, the username and password are not passed per spec.  See http://www.w3.org/TR/XMLHttpRequest2/#cross-origin-request-steps (esp. the "Note:" bit).

No idea offhand why you're seeing NS_ERROR_DOM_BAD_URI...

Comment 8

[Paul Eipper]

I see. So that means in practice credentials cannot be cached on the browser without showing the regular UI?

Take the use case of a website that uses a REST API which requires BasicAuth (everything goes over HTTPS):

1. website presents a form login, which is used to auth user against API;
2. JS performs XHR on API to verify auth;
3. Auth is cached by the browser, which allows the website to perform other requests during that session.

While this works for same-domain, step 3 evidently does not work with CORS, since not `open` nor setting the headers will do the caching.

Is this just not a valid use case for CORS?

Only possible workaround I can see is to store form input in a session cookie to send on all CORS requests.
Pros: lifetime is the same as regular browser auth caching
Cons: credentials are easily readable on the machine

I would appreciate any advice regarding this.

Comment 9

[Paul Eipper]

(In reply to Boris Zbarsky (:bz) from comment #7)
> When performing a CORS request via XHR, the username and password are not
> passed per spec.  See
> http://www.w3.org/TR/XMLHttpRequest2/#cross-origin-request-steps (esp. the
> "Note:" bit).
> 
> No idea offhand why you're seeing NS_ERROR_DOM_BAD_URI...

Actually, I don't understand rationale in the note. How setting the header manually is different from using the open method? (btw, I have no idea how such an attack would be put into practice).

Comment 10

[Boris Zbarsky [:bzbarsky]]

Jonas, see comment 8?

Comment 11

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

Is CORS really an issue here?

Isn't the same thing happening if you do a same-origin request and include an Authentication header? I wouldn't expect the browser to remember that Authentication value for subsequent requests.

Can you clarify that it does indeed work for same-origin requests that use XMLHttpRequest?


Like Boris said, the remembering of passwords is a UI feature. I don't think we want to automatically remember a password sent though authentication headers. That seems like that is the wrong thing to do just as often as it would be the right thing to do.

I.e. I could see developers getting just as annoyed, if not even more so, if we automatically remembered an Authentication header just because they one made a request using one. Especially since there is no clear way to cause the header to be "forgotten".

I don't actually think we want to allow website A inject and remember a password for website B. Doing that would be allowing "session pinning" attacks. Potentially we could allow things like remembering a password for website B when website A is interacting with it. But that's a pretty narrow feature. I suggest simply using any of the storage mechanisms that we have (cookies, indexedDB, etc) to remember the password.