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.
Related
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.
I'm developing a page/form for a campaign inside my company. However, the first step is to check if the person is logged in. This is easily checked against a cookie - CUSTOMER - that is set once they're logged in.
However:
1) I'm developing locally, not on the same domain, and, as a result can't see that cookie
2) The final campaign may or may not end up residing on the actual domain. They may end up using a vanity URL or something.
For purposes of this, let's assume I do NOT have access to the main domain where the cookie was set.
How can I read that cookie from off the domain? Oh, and since IT folks don't let us touch the back-end grumble, it has to be a JS solution.
Thanks!
You can't.
The only cookies you can read with client side JavaScript are those belonging to the host of the HTML document in which the <script> is embedded.
By setting withCredentials you can support cookies in cross-origin requests, but they are handled transparently by the browser and JS has no direct access to them (the XHR spec goes to far as to explicitly ban getAllResponseHeaders from reading cookie related headers). The only way for a cross-origin request to get access to cookies is for the server (which you say you don't have access to) to copy the data into the body or a different response header).
You can if you can install server side components.
You can use a dedicated domain to host your cookie and then share it using XSS technics
When dom1.foo.com logs in then you register a cookie on cookie.foo.com using an Ajax XSS call then when you go on dom2.foo.com you have to query cookie.foo.com with your XSS api
I' ve played with it some time ago
https://github.com/quazardous/mudoco/blob/master/mudoco/README.txt
It's just some sort of POC..
This is a question about cross-domain API security. The best way to ask this so it could be useful for others is through a hypothetical example.
Domain APIHOST.COM wishes to allow access to its resources to FRIENDLYSITE1.COM and FRIENDLYSITE2.COM (but no other domains)
The FRIENDLYSITEs are owned by others, and APIHOST has no direct server access to them. They may be running any server technology. They are willing to host additional content, but nothing too complicated.
When Bob visits FRIENDLYSITE1.COM using his web browser, his credentials for FRIENDLYSITE1.COM (or APIHOST.COM) are irrelevant. Security should be handled between APIHOST.COM and FRIENDLYSITE1.COM.
I have looked into all of the cross-domain request technologies (CORS, iFrames, JSONP), but all of them assume that the security should come from Bob the browser, and not from the FRIENDLYSITE1.COM domain that Bob is visiting.
Is there a way to do cross-domain API access where the security is handled between the two servers, without involving Bob and his browser?
If you want to secure communication between two servers, then you are going to need to use a secure transport (like https) and use some credentials that are only provided to sites that you wish to allow access.
Those credentials can be as simple as a username and password if you want. In that case, you would provide FRIENDLYSITE1.COM some credentials and whenever it wants to make a connection to APIHOST.COM, it will include those credentials with each API request (or perhaps your API supports a login that creates a cookie that can then be used for subsequent API calls).
If, on the other hand, what you really mean by your question is that there are web pages hosted by FRIENDLYSITE1.COM that contain Javascript in them and that Javascript in those web pages wants to access APIHOST.COM, then that is a different situation. Since this situation is actually connected from the browser on the user's computer (an insecure environment), you using credentials like in the previous example exposes those credentials to anyone and thus they are no longer secret.
About the best you can do in this case is to enable APIHOST.COM for CORS and only allow sites FRIENDLYSITE1.COM and FRIENDLYSITE2.COM for CORs access. This will keep any web pages from any other sites from accessing APIHOST.COM from a browser, but it will not prevent any server or any server proxy from accessing APIHOST.COM. It's basically impossible to allow access from a specific web page, but not from anywhere else. This is because web pages are completely insecure so you can't use credentials from a web page, but keep them secret.
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.
I am developing a web app that is served from domain.ext. This web app uses cookie–based sessions and provides users with the ability to host a web pages containing custom JavaScript on a subdomain, ex. sub1.domain.ext, sub2.domain.ext. The subdomains do not use cookie–backed sessions.
Given this setup, is it possible to ensure the following?:
users at sub1.domain.ext cannot read or write a cookie for domain.ext (i.e. domain.ext sessions cannot be stolen or hijacked by JavaScript embedded in a page at sub1.domain.ext).
JavaScript embedded in a page at sub1.domain.ext cannot read or write cookies at sub2.domain.ext, and vice versa.
I’ve tested out a few things, for example it appears to be possible to interact with domain.ext’s cookies from sub1.domain.ext by running document.domain = 'domain.ext' inside the sub1.domain.ext’s window. Is there some way to prevent this, for example by specifying some kind of policy when setting the domain from domain.ext?
You can't specify that a cookie should only be valid for example.com by setting the domain parameter. If you set domain=example.com, it will be valid for *.example.com.
Setting a cookie on example.com without a domain parameter sets a cookie for only example.com in most browsers. But not IE.
So, if you ever want to have subdomains with separate cookie contexts, you should serve your site from www.example.com only. As Gaby said, naturally you can still support access through example.com by giving a 301 redirect to the www version.