844622 - CORS-authorized requests should implement limit_third_party cookie policy

Status: NEW

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

Description

[Sid Stamm [:geekboy or :sstamm]]

XHRs authorized by CORS and with withCredentials=true can't use third party cookies when LIMIT_THIRD_PARTY is the default web-wide cookie policy.  We need to update it so they do have cookie capabilities when the target of the request already has cookies set.

Comment 1

[David E. Ross]

One financial service that I use online is Western Federal Credit Union.  As I use that site, it requires cookies that are NOT session-only for the following domains:  www.western.org, .western.org, and ebankingwestern.org.  I would expect the first to be part of the second.  However, would ebankingwestern.org be considered a third-party cookie?

Comment 2

[Jonathan Mayer]

I think there may be two separate suggestions that have been floated about how to handle CORS-authorized XHRs that have withCredentials set.

1) We should allow the response to set cookies if the eTLD already has at least one cookie (i.e. follow the bug 818340 policy). I'm totally onboard with this.

2) We should always allow the response to set cookies. I'm less cool with this approach. First, I'm uncertain of the need. The point of withCredentials, as I understand it, is to allow the user to present credentials that have already been established. The only cases where the new policy could be problematic are where credentials are presented in non-cookie form (i.e. HTTP auth or client-side SSL cert), there are no other cookies, and the response wants to set cookies. Second, this would open a loophole for surreptitiously setting third-party cookies. Safari had a somewhat similar loophole for JS-initiated form submissions, and several websites abused it.

Comment 3

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

(In reply to Jonathan Mayer from comment #2)
> I think there may be two separate suggestions that have been floated about
> how to handle CORS-authorized XHRs that have withCredentials set.
> 
> 1) We should allow the response to set cookies if the eTLD already has at
> least one cookie (i.e. follow the bug 818340 policy). I'm totally onboard
> with this.

I agree. I don't understand why this is broken. CORS requests should with withCredentials=true should look no different to Necko than any other requests.

Are you sure it doesn't work?

> 2) We should always allow the response to set cookies. I'm less cool with
> this approach. First, I'm uncertain of the need. The point of
> withCredentials, as I understand it, is to allow the user to present
> credentials that have already been established. The only cases where the new
> policy could be problematic are where credentials are presented in
> non-cookie form (i.e. HTTP auth or client-side SSL cert), there are no other
> cookies, and the response wants to set cookies. Second, this would open a
> loophole for surreptitiously setting third-party cookies. Safari had a
> somewhat similar loophole for JS-initiated form submissions, and several
> websites abused it.

I completely agree. Allowing cookies is a "nice feature" from the websites point of view since it would mean that it could let the browser do the session management. But it opens exactly the loopholes that bug 818340 has attempted to fix.

As far as I can tell comment #2 is unrelated to this bug and is a general complaint about the new 3rd party cookie policy implemented in bug 818340. Such complaints are better raised there.

Comment 4

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

Err... I meant to say that:

As far as I can tell comment #1 is unrelated to this bug and is a general complaint about the new 3rd party cookie policy implemented in bug 818340. Such complaints are better raised in bug 818340.

Comment 5

[Jonathan Mayer]

(In reply to Jonas Sicking (:sicking) from comment #3)

> I agree. I don't understand why this is broken. CORS requests should with
> withCredentials=true should look no different to Necko than any other
> requests.
> 
> Are you sure it doesn't work?

The new policy should apply to XHRs. Proposal: we verify that it does, then close this bug.

Comment 6

[Brendan Eich [:brendan]]

(In reply to Jonathan Mayer from comment #2)
> 2) We should always allow the response to set cookies. I'm less cool with
> this approach. First, I'm uncertain of the need.

The point of this bug is to become certain, ahead of a bad event for Firefox's main user base.

> The point of
> withCredentials, as I understand it, is to allow the user to present
> credentials that have already been established. The only cases where the new
> policy could be problematic are where credentials are presented in
> non-cookie form (i.e. HTTP auth or client-side SSL cert), there are no other
> cookies, and the response wants to set cookies.

Sounds right to me. Is this just too unlikely to care, and we risk breakage? I honestly don't know. Client-side certs are rare outside of "enterprise", but we have lots of dark matter users there.

HTTP auth is less rare and could be a problem. We should look at, e.g., Mozilla's own sites that use it.

> Second, this would open a
> loophole for surreptitiously setting third-party cookies.

Does not CORS require reciprocity? I can't make a.com and b.com cooperate via CORS unless I have admin control of both.

Do advertising consumers (sites using ads) really have the budget for anything like CORS? Never mind the ad nets themselves, who are dumb as a box of rocks in my experience.

> Safari had a
> somewhat similar loophole for JS-initiated form submissions, and several
> websites abused it.

That's a much different case from CORS, if I'm right about the reciprocity requirement.

/be

Comment 7

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

Using CORS and withCredentials is in and of itself pretty rare. The majority of deployments instead pass explicit credentials as part of the URL or in headers.

You can definitely use CORS between a.com and b.com without having admin control over both. Business agreements between the two admins is a common way to make it work.

Such business agreements are often in place where tracking is done using cookies, so I think we generally want to prevent tracking even when such agreements exist.

I don't think that almost any ad networks use CORS today. But I would absolutely think that they'd start if it enabled them to work around the new cookie policy.

Comment 8

[Jonathan Mayer]

I see two special-case design options for handling CORS withCredentials requests.

First, we could make a wholesale exception from the new cookie policy. This would allow even iframed third-party content to trivially circumvent the new policy. Just buy another domain and make a request.

Second, we could provide a narrower exception, e.g. only covering requests initiated from the first-party eTLD. As Jonas notes, there's the problem of potential business deals between first parties and third parties. Moreover, in practice, many third-party websites get script embeds into a first-party context. It would still be trivial to circumvent the cookie policy, then.

I share Jonas's skepticism about breakage risk. We can't prove that negative, of course. I think we should feel comfortable closing this bug and circling back if necessary. Handling known unknowns is one of the very reasons to let the new cookie policy percolate through the various release channels.

Comment 9

[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.