Last Comment Bug 724182 - Gecko sends cookies and HTTP auth credentials in cross-domain requests to an unrelated domain for images and scripts that haven't been approved by CORS
: Gecko sends cookies and HTTP auth credentials in cross-domain requests to an ...
Status: NEW
[domsecurity-backlog]
: privacy
Product: Core
Classification: Components
Component: DOM: Security (show other bugs)
: Trunk
: All All
P3 normal with 3 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Christoph Kerschbaumer [:ckerschb]
Mentors:
Depends on:
Blocks: uplift_tor_fingerprinting
  Show dependency treegraph
 
Reported: 2012-02-03 17:56 PST by Brian Smith (:briansmith, :bsmith, use NEEDINFO?)
Modified: 2018-06-22 10:48 PDT (History)
20 users (show)
ethan: needinfo? (briansmith)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description User image Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2012-02-03 17:56:11 PST
+++ This bug was initially created as a clone of Bug #724179 +++

In the case where a page embeds content from an unrelated domain (different TLD+1), including <img src=''>, <script src=''>, etc., we should attempt to enforce CORS; if the subresource's domain doesn't allow the load, but it is a cross-domain load that we would normally do without enforcing CORS (e.g. <image src="" hotlinking), then we should load the cross-domain resource without sending any cookies or HTTP auth credentials, and without allowing any cookies (or HTTP auth credentials) to be set (or requested) by the response.

AFAICT, most of our motivation for continuing to support these cross-domain embeddings without enforcing CORS is to allow hotlinking of images. I bet it is rare that the user ever benefits from sending cookies and HTTP auth credentials in those requests.

Note that this proposal wouldn't stop image-based trackers (tracking pixels, banner ads) from working; it would only push them to supporting CORS.

See also bug 647010.
Comment 1 User image Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2012-02-03 18:16:14 PST
(In reply to Brian Smith (:bsmith) from comment #0)
> AFAICT, most of our motivation for continuing to support these cross-domain
> embeddings without enforcing CORS is to allow hotlinking of images.

... and CDNs, of course.
Comment 2 User image Boris Zbarsky [:bzbarsky, bz on IRC] 2012-02-03 19:11:13 PST
This would incidentally solve the "check whether you're logged into Facebook using image onload" problem... if we can get away with it.  The possible compat issues here worry me.
Comment 3 User image Jonas Sicking (:sicking) No longer reading bugmail consistently 2012-02-04 21:23:51 PST
Images might be ok here, but with all the JSONP loading going around I'm almost certain that disabling cookies would "break the web".

I have heard something about microsoft doing something like this, but that they added smarts to figure out when to send cookies and when not to. I never understood how that logic worked though, and if it was successful.
Comment 4 User image [Baboo] 2012-02-05 02:21:10 PST
(In reply to Jonas Sicking (:sicking) from comment #3)
> I have heard something about microsoft doing something like this, but that
> they added smarts to figure out when to send cookies and when not to. I
> never understood how that logic worked though, and if it was successful.

Sounds interesting, do you remember where do you heard/read about this? MSDN, EricLaw's IEInternals blog, …?
Comment 5 User image Jonas Sicking (:sicking) No longer reading bugmail consistently 2012-02-05 11:40:21 PST
It was in a direct conversation with Eric iirc. So we can probably ask him.
Comment 6 User image Ethan Tseng [:ethan] 2017-01-24 17:01:54 PST
Brian, why this is tagged as fingerprinting?
Comment 7 User image Tom Ritter [:tjr] 2017-05-04 13:43:58 PDT
Could the IE thing possibly be:

> Q7: My site is not receiving cookies when it is running in an IFRAME and the parent page is from a different domain. Why?
> 
> A: Internet Explorer has restrictions on “3rd party” cookies. 3rd party cookies are cookies which are set or sent for resources from a different domain than the top-level browsing context. You can easily confirm P3P/Cookie restrictions as the root cause of such issues by temporarily changing IE’s Tools / Options / Privacy setting to “Accept All Cookies”.
> 
> In order to allow such cookies to be sent reliably, you should send a P3P header when setting the cookie.

https://blogs.msdn.microsoft.com/ieinternals/2009/08/20/internet-explorer-cookie-internals-faq/

Note You need to log in before you can comment on or make changes to this bug.