Let's say I have a website (https://example.com), if I have an image on that website that is from my second website (https://example2.com), will Chrome store the cookies that it got from that image?
Like on the image, if I set the Set-Cookie header to store a cookie saying that the image was fetched, will chrome save the cookie in the browser and if I were to visit https://example2.com, I would be able to see that my browser had fetched an image from my servers before.
Yes, these are third-party cookies and work just as you describe. The browser will save them under the domain of the specific resource they were sent under, and re-send them on future requests to that domain, whether they are top-level page requests or sub-resource requests (e.g., an image).
The server must authorize a cookie to be sent as a third-party cookie via the SameSite=None cookie attribute. This also requires use of the Secure attribute, meaning in practice that third-party cookies can only be sent over HTTPS.
Third-party cookies currently work (as of July 2021) in modern browsers, but are blocked by default in Chrome's Incognito mode:
Third-party cookies are a major part of how cross-site tracking works: when any site embeds an advertisement or tracking image as a cross-site <img>, the foreign site serving the embedded image may send and read cookies for their domain, allowing them to know who they're serving ads for. (Have we seen this user before on any other partner sites? Do we have ads relevant to our understanding of this user's browsing habits?)
However, Google is trying to cease use of third-party cookies in advertising, so their future is somewhat uncertain.
I have a simple use of third-party cookies on my Arqade profile, which embeds a remote image from repl.co. The image is served with a unique cookie (and thereafter requested with that same unique cookie) to persistently control the same character in a game. There is no other communication with repl.co needed to establish this cookie relationship besides the embedded image.
Related
I'm making a website which loads images from various sources, without knowing which these sources can be.
Some of these image hosts do set cookies when requesting an image (e.g. Imgur) even though this cookie is not necessary.
Is it possible (using a HTML header or some javascript) to add a whitelist to my website which states which domains are trusted and are allowed to set cookies, blocking all other third-party cookies?
I am learning the basic knowledge of Same-Origin-Policy and cross-site-request.
The question is can I get cookies for current domain and send them to another domain by jsonp ?
For example, there are two websites. www.A.com and www.B.com.
If user login to A, there are some cookies in user's browser for A. We know that we cannot send XHR to B with cookies because of the restriction of Same-Origin-Policy. But can we get the cookies using js and send them as parameters using jsonp.
such as:
<script>http://www.B.com/xxx?cookies=REALCOOKIES ?
If I am reading this right, this is essentially how Google Analytics cross-domain tracking works. When a user clicks on a link to another domain, the cookie values are appended onto the querystring for the link which are then picked up on the other end and then turned back into a cookie (or whatever it is you want to do with it).
If you are talking about reading cookies from one domain to the other, you can do this server-side IF you have some sort of asset request that is available to both domains e.g. an image. This is (in essence) how affiliate, media banner, facebook tracking works, i.e. the concept of ads "following" you around while you are surfing (do people still surf?) the internet.
If you are the developer for both domains you could also write an api (server-side) that makes a request to domain www.A.com and retrieves the required cookies.
I have clients(A, B) and they use my service.
They have domains and they include same javascript to their websites.
The javascript communicates with my server and saves cookies to the domain.
The cookies are the infomation about a connected user and cookies are different by user.
I assume they use same browser.
So if a user connect to A website and connect to B website, I want to save same key information to their cookies.
Is their way to do this?
You cannot access cookies for other domains, but you can set up a third domain tracking.example, and then request any resource (e.g. a 1pixel image) from that domain.
To read the cookie from one of the websites, either use a CORS-enabled endpoint, e.g. https://tracking.example/getuserid, that allows client-side code on the website to read out the cookie or an ID that is associated with it, or embed an iframe from tracking.example and use inter-frame-communication.
Note that for privacy reasons, third-party cookies are being restricted, or even totally blocked by some browsers and configurations. There is no replacement for third-party cookies, while there are ways to identify users without cookies, they are nowhere near 100% accurate, may violate local laws, and are intended to be by browsers.
If both websites manage logins, you can of course use the logged-in email address as an ID.
If I have an HTML page served over HTTP at http://example.com:123, and another served over HTTPS at https://example.com:456/some_app, is there any risk to the HTTPS app? Note that the following mitigations are assumed to be in place:
The HTTP page is entirely unauthenticated and contains public information
The cookies for the HTTPS page are marked secure
The HTTPS page uses a standard anti-CSRF patter such as double submit
The main risk that I see is that an attacker could intercept the HTTP request and send back a page with malicious Javascript. While this is undesirable, I can't see any way that the attack could escalate. Despite the the overly permissive access controls on cookies, the attacker should not be able to steal the HTTPS page's cookies, because they are marked secure. As far as cross origin requests go, requests made by the HTTP page are considered as coming from a different origin, so the CSRF protections work there.
Are there any attack venues that I'm missing? Or is the HTTPS app reasonably safe?
The "secure" attribute of cookies prevents the cookies being sent with a http request so they are only sent with https. However there is nothing to prevent javascript on the http page reading the cookie if, for example, it has been tampered with either in transit to include extra javascript or was vulnerable to a XSS flaw.
This could be remediated by setting the HttpOnly flag as well as the secure flag but that will may not work for your Double protection CSRF implementation if JavaScript is needed to read the cookie.
EDIT: Comments below state that Chrome (at least) prevents this when Secure flag is set but I cannot see this explicitly called out in the RFC and in fact section 8.5 states that cookies do not always follow the same restrictions for scheme and path when accessed through document.cookie. It also gives the example of path restrictions being ignored when accessed locally using document.cookie - though admittedly doesn't explicitly mention whether Secure cookies can be read from javascript on non-https pages. I would err on the cautious side and so assume they are not secure from javascript on http pages unless HttpOnly flag is set.
The other issue is that there is nothing to stop the Http page setting the cookie, and overwriting the existing one. Again this could be achieved by intercepting the http page response and adding a Set-Cookie header, or by using javascript on the page of vulnerable to XSS. While you might think overwriting a cookie wouldn't cause too many problems it could log you in as someone else for example without the person realising at which point they might enter other private data under this incorrect login.
Of course your https page could also be vulnerable to XSS too but the interception attacks mention are only an issue on unsecured http (and I'm including poorly configured https in that btw). Additionally http pages are typically handled with less care by users and developers alike and also load insecure third party content without error. So could be more vulnerable to XSS or other issues.
This is not to mention the fact that, with only a port number difference, your http site could be intercepted and made to look like your https site as a phishing site in the hope your visitors are happy with the server name and don't notice the incorrect port.
And those are just a few issues I can think of.
I would strongly advise not allowing http and https on the same server name, would suggest https everywhere and even go as far as recommending HSTS to ensure this.
If I have a SITEA writing a cookie to my browser, can SITEB write code to access the cookie or are cookies hidden from websites that didn't create them ?
My answer to that was that YES, SITEB can read the document.cookie and if he knows what's the cookie name, it can access it. Was I right ?
Regarding the second questions, I don't think there are Server Side cookies other than SESSIONS. Am I right?
Cookies are usable by both the server and the client. Cookies can only be read by the website the domain that creates them; you can use sub-domains domains, url paths. Cookies are generally considered insecure if used from the client side, and should not be used to hold sensitive data if accessed from the client side. The server can encrypt information and store it in the cookie as long as the encryption is done on safe manner on the server. Using cookies are a good way of avoiding the use of a session server, and if you do not save sensitive data they are a good way to store state in a web application. Although they can be more challenging than other session mechanisms, the do work on both the client and the server.
Advertising products like double click use cookies to track a monitor user activity, which is how ads follow you from site to site.
Third-party and first-party cookies
Cookies are categorized as third-party or first-party depending on whether they are associated with the domain of the site a user visits. Note that this doesn’t change the name or content of the actual cookie. The difference between a third-party cookie and a first-party cookie is only a matter of which domain a browser is pointed toward. The exact same kind of cookie might be sent in either scenario.
https://support.google.com/adsense/answer/2839090
Cookies are accessible on the basis of domain. This is the basic inherent feature of any browser otherwise it would have been very easy for companies to snoop on each other's users.
If Site A has domain .xyz.com then any website having the same domain can access the cookies. But if any site has domain xyz.com (dot missing) it cant access any other domain's cookies.
Also the http request send to server will contain cookies of the domain from which it is sent.