Closed Bug 1011746 Opened 11 years ago Closed 7 years ago

CORS should block cookies for "null" origins

Categories

(Core :: DOM: Security, defect)

Product:
Core
Component:
DOM: Security
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: dmosedale, Unassigned)

Details

(Whiteboard: [domsecurity-backlog])

Since any site can create a data: URI, which gets a "null" origin, this means that if a server sets Access-Control-Allow-Origin to "null" and uses cookies, any other site should be able to CSRF the original server site. As a result, CORS should be treating null like it does * to prevent inadvertent mistakes. Granted, setting up a server this way is an odd thing to do, we stumbled upon it inadvertently, and need to figure out why our server is set up that (one current theory involves a proxy in front it). Also granted is the current behavior appears to actually correspond to the spec, so there's likely a spec bug here too.
This was intentional to allow a sandboxed Google widget to still have search results (say) based on your preferences. Also, to enable cookie sharing you need more than just that header.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Resolution: WONTFIX → INVALID
Anne, I don't understand what you mean by "This was intentional to allow a sandboxed Google widget to still have search results (say) based on your preferences". Saying "access-control-allow-origin: null" basically means, I'm willing to share this information with anyone, as long as I don't know who. This strikes me as a somewhat strange policy.
In other words, if the sandboxed google widget can access some private information, so can anyone else.
Sorry, I flipped the use case. The use case was a sandboxed widget accessing personalized search results.
Group: core-security
This still seems like a terrible footgun. We very intentionally did not allow access-control-allow-origin:* together with cookies because it was so easy to get wrong, but this essentially brings that back.
Is anyone actually building features that rely on this?
How does this bring that back in any way? You'd need to actively echo the Origin header value in Access-Control-Allow-Origin for each request and set Access-Control-Allow-Credentials correctly. So effectively you already need to share with everyone.
access-control-allow-origin: null effectively means the same as access-control-allow-origin: *. It means that anyone can load from that resource. So when combined with access-control-allow-credentials it means that a couple of static header shares private information with the world.
That seems fair. We've had requests for * to be able to do the same, but I can see how that's an argument for disallowing null, given sandboxing. Why was there no bug filed on CORS or now Fetch?
I believe we are working on a service that is relying on this working. As fetches from Gecko chrome will use Origin: null.
I still don't think it's safe enough to enable access-control-allow-origin: null combined with cookies, for the same reason that access-control-allow-origin: * combined with cookies isn't safe. In fact this bug came up because I pointed out that one of the designs being considered for Loop was leaking private data because they were trying to rely on access-control-allow-origin: null. If we are building services that rely on access-control-allow-origin: null combined with cookies then we should change them. I'm much more worried about web compat here than chrome code. Chrome can be changed and has plenty of other options.
I'm still not sure whether I agree that "*" combined with cookies is unsafe, but I have accepted that in the past and I am okay with accepting that "null" is identical per comment 8. Given that, I'd like to know what the next steps should be here.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
We should also bring this up at public-webapps. But given that this is a security bug we shouldn't block on that before moving forward with disabling this in Gecko. The first step for that is likely to add telemetry code to check how commonly access-control-allow-origin: null is used together with cookies.
Anne, did anything happen here?
Yes, I raised this in http://lists.w3.org/Archives/Public/public-webappsec/2014Jun/thread.html#msg3 and added an open issue in https://fetch.spec.whatwg.org/#cors-check but there was not the response that I was hoping for. If we do this and can get odinho to update web-platform-tests I could change the specification and maybe that'll convince Blink to get on board. Or I could make another announcement on a list hoping they'll bite more actively. WDYT?
If you change the spec and Gecko is disabling this (even better if it's in a nightly I can test), do ping me and I will be happy to update the tests. Btw, sof at Opera has also done some work on XHR and CORS in Blink, so if this spec+test change still doesn't ignite any spark we could ask him to do a patch and send it to review. But Mike West seemed positive to me, so you were sad the response was not "YAY let's do this", only "sounds cool"?
I was hoping for buy-in from the others too, but yeah, this is probably good enough. Thanks for volunteering to update the tests.
sof suggested doing an intent-to-break-the-web announcement - so the same thing as you suggested I guess. I thought you were thinking about a W3C list, but I guess the idea was chromium-dev and some other lists with way more visibility. That does sound like a good idea, and might get some more of the people (ab)using this out of the wood work. Though having gecko disable this would probably also turn up breakages if that still doesn't say anything about the realism of changing this.
Component: Security → DOM: Security
Whiteboard: [domsecurity-backlog]
Resolving this as WONTFIX per https://github.com/whatwg/fetch/commit/6e68ce9e06d3a03049922608fb51dae5934def5c as this would break Dropbox.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.