When I visit a sub-domain website ex: https://sub2.example.com, from a browser console I can set a cookie for parent domain.
document.cookie = "nameCookie=HelloWorld; domain=.example.com;"
as per Cookie RFC this works! and this cookie should be available to all sub-domains.
ex:
https://example.com
https://sub2.example.com
https://xxx.example.com
But my problem, this concept is not working on some websites.
for ex:
Go to https://square.github.io/
open browser console
document.cookie = "nameCookie=HelloWorld; domain=.github.io;"
console.log(document.cookie)
check that nameCookie is not available.
Why it is not working here? any Http header/rule setup on those websites?
Because github.io is on the list of effective top-level domains (eTLDs) (raw list here), so each github.io subdomain is treated like a subdomain of a top-level domain (that is, _______.github.io is treated just like _______.com or _______.co.uk).
Related
Say I have a website called a.com, and when a specific page of this site is loaded, say page link, I like to set a cookie for another site called b.com, then redirect the user to b.com.
I mean, on load of a.com/link I want to set a cookie for b.com and redirect user to b.com.
I tested it, and browser actually received the cookie from a.com/link, but it didn't send that cookie on the redirection request to b.com. Is it normal?
Can we set cookies for other domains?
You cannot set cookies for another domain. Allowing this would present an enormous security flaw.
You need to get b.com to set the cookie. If a.com redirect the user to b.com/setcookie.php?c=value
The setcookie script could contain the following to set the cookie and redirect to the correct page on b.com
<?php
setcookie('a', $_GET['c']);
header("Location: b.com/landingpage.php");
?>
Similar to the top answer, but instead of redirecting to the page and back again which will cause a bad user experience you can set an image on domain A.
<img src="http://www.example.com/cookie.php?val=123" style="display:none;">
And then on domain B that is example.com in cookie.php you'll have the following code:
<?php
setcookie('a', $_GET['val']);
?>
Hattip to Subin
Probaly you can use Iframe for this. Facebook probably uses this technique. You can read more on this here. Stackoverflow uses similar technique, but with HTML5 local storage, more on this on their blog
In case you have a.my-company.com and b.my-company.com instead of just a.com and b.com you can issue a cookie for .my-company.com domain - it will be accepted and sent to both of the domains.
You can't, at least not directly. That would be a nasty security risk.
While you can specify a Domain attribute, the specification says "The user agent will reject cookies unless the Domain attribute specifies a scope for the cookie that would include the origin server."
Since the origin server is a.com and that does not include b.com, it can't be set.
You would need to get b.com to set the cookie instead. You could do this via (for example) HTTP redirects to b.com and back.
Setting cookies for another domain is not possible.
If you want to pass data to another domain, you can encode this into the url.
a.com -> b.com/redirect?info=some+info (and set cookie) -> b.com/other+page
see RFC6265:
The user agent will reject cookies unless the Domain attribute
specifies a scope for the cookie that would include the origin
server. For example, the user agent will accept a cookie with a
Domain attribute of "example.com" or of "foo.example.com" from
foo.example.com, but the user agent will not accept a cookie with a
Domain attribute of "bar.example.com" or of "baz.foo.example.com".
NOTE: For security reasons, many user agents are configured to reject
Domain attributes that correspond to "public suffixes". For example,
some user agents will reject Domain attributes of "com" or "co.uk".
(See Section 5.3 for more information.)
But the above mentioned workaround with image/iframe works, though it's not recommended due to its insecurity.
You can't, but... If you own both pages then...
1) You can send the data via query params (http://siteB.com/?key=value)
2) You can create an iframe of Site B inside site A and you can send post messages from one place to the other. As Site B is the owner of site B cookies it will be able to set whatever value you need by processing the correct post message. (You should prevent other unwanted senders to send messages to you! that is up to you and the mechanism you decide to use to prevent that from happening)
Send a POST request from A. Post requests are on the serverside only and can't be accessed by the client.
You can send a POST request from a.com to b.com using CURL (recommended, serverside) or a hidden method="POST" form (clientside). If you go for the latter, you might want to obfuscate your JavaScript so that the user won't be able to understand the algorithm and interfere with it.
Make a gateway on b.com to set cookies:
<?php
if (isset($_POST['data']) {
setcookie('a', $_POST['data']);
header("Location: b.com/landingpage");
}
?>
If you want to bring security a step further, implement a function on both sides (a.com and b.com) to encrypt (on a.com) and decrypt (on b.com) data using a cryptographic cypher.
If you're trying to do something that must be absolutely secure (e.g. transfer a login session) try oAuth or take some inspiration from https://api.cloudianos.com/docs#v2/auth
Here is what I've used. Note, this cookie is passed in the open (http) and is therefore insecure. I don't use it for anything which requires security.
Site A generates a token and passes as a URL parameter to site B.
Site B takes the token and sets it as a session cookie.
You could probably add encryption/signatures to make this secure. Do your research on how to do that correctly.
In this link, we will find the solution Link.
setcookie("TestCookie", "", time() - 3600, "/~rasmus/", "b.com", 1);
Due to weird domain/subdomain cookie issues that I'm getting, I'd like to know how browsers handle cookies. If they do it in different ways, it would also be nice to know the differences.
In other words - when a browser receives a cookie, that cookie MAY have a domain and a path attached to it. Or not, in which case the browser probably substitutes some defaults for them. Question 1: what are they?
Later, when the browser is about to make a request, it checks its cookies and filters out the ones it should send for that request. It does so by matching them against the requests path and domain. Question 2: what are the matching rules?
Added:
The reason I'm asking this is because I'm interested in some edge cases. Like:
Will a cookie for .example.com be available for www.example.com?
Will a cookie for .example.com be available for example.com?
Will a cookie for example.com be available for www.example.com?
Will a cookie for example.com be available for anotherexample.com?
Will www.example.com be able to set cookie for example.com?
Will www.example.com be able to set cookie for www2.example.com?
Will www.example.com be able to set cookie for .com?
Etc.
Added 2:
Also, could someone suggest how I should set a cookie so that:
It can be set by either www.example.com or example.com;
It is accessible by both www.example.com and example.com.
Although there is the RFC 2965 (Set-Cookie2, had already obsoleted RFC 2109) that should define the cookie nowadays, most browsers don’t fully support that but just comply to the original specification by Netscape.
There is a distinction between the Domain attribute value and the effective domain: the former is taken from the Set-Cookie header field and the latter is the interpretation of that attribute value. According to the RFC 2965, the following should apply:
If the Set-Cookie header field does not have a Domain attribute, the effective domain is the domain of the request.
If there is a Domain attribute present, its value will be used as effective domain (if the value does not start with a . it will be added by the client).
Having the effective domain it must also domain-match the current requested domain for being set; otherwise the cookie will be revised. The same rule applies for choosing the cookies to be sent in a request.
Mapping this knowledge onto your questions, the following should apply:
Cookie with Domain=.example.com will be available for www.example.com
Cookie with Domain=.example.com will be available for example.com
Cookie with Domain=example.com will be converted to .example.com and thus will also be available for www.example.com
Cookie with Domain=example.com will not be available for anotherexample.com
www.example.com will be able to set cookie for example.com
www.example.com will not be able to set cookie for www2.example.com
www.example.com will not be able to set cookie for .com
And to set and read a cookie for/by www.example.com and example.com, set it for .www.example.com and .example.com respectively. But the first (.www.example.com) will only be accessible for other domains below that domain (e.g. foo.www.example.com or bar.www.example.com) where .example.com can also be accessed by any other domain below example.com (e.g. foo.example.com or bar.example.com).
The previous answers are a little outdated.
RFC 6265 was published in 2011, based on the browser consensus at that time.
Since then, there has been some complication with public suffix domains. I've written an article explaining the current situation - http://bayou.io/draft/cookie.domain.html
To summarize, rules to follow regarding cookie domain:
The origin domain of a cookie is the domain of the originating request.
If the origin domain is an IP, the cookie's domain attribute must not be set.
If a cookie's domain attribute is not set, the cookie is only applicable to its origin domain.
If a cookie's domain attribute is set,
the cookie is applicable to that domain and all its subdomains;
the cookie's domain must be the same as, or a parent of, the origin domain
the cookie's domain must not be a TLD, a public suffix, or a parent of a public suffix.
It can be derived that a cookie is always applicable to its origin domain.
The cookie domain should not have a leading dot, as in .foo.com - simply use foo.com
As an example,
x.y.z.com can set a cookie domain to itself or parents - x.y.z.com, y.z.com, z.com. But not com, which is a public suffix.
a cookie with domain=y.z.com is applicable to y.z.com, x.y.z.com, a.x.y.z.com etc.
Examples of public suffixes - com, edu, uk, co.uk, blogspot.com, compute.amazonaws.com
I tested all the cases in the latest Chrome, Firefox, Safari in 2019.
Response to Added:
Will a cookie for .example.com be available for www.example.com? YES
Will a cookie for .example.com be available for example.com? YES
Will a cookie for example.com be available for www.example.com? NO, Domain without wildcard only matches itself.
Will a cookie for example.com be available for anotherexample.com? NO
Will www.example.com be able to set cookie for example.com? NO, it will be able to set cookie for '.example.com', but not 'example.com'.
Will www.example.com be able to set cookie for www2.example.com? NO. But it can set cookie for .example.com, which www2.example.com can access.
Will www.example.com be able to set cookie for .com? NO
For an extensive coverage review the contents of RFC2965. Of course that doesn't necessarily mean that all browsers behave exactly the same way.
However in general the rule for default Path if none specified in the cookie is the path in the URL from which the Set-Cookie header arrived. Similarly the default for the Domain is the full host name in the URL from which the Set-Cookie arrived.
Matching rules for the domain require the cookie Domain to match the host to which the request is being made. The cookie can specify a wider domain match by include *. in the domain attribute of Set-Cookie (this one area that browsers may vary). Matching the path (assuming the domain matches) is a simple matter that the requested path must be inside the path specified on the cookie. Typically session cookies are set with path=/ or path=/applicationName/ so the cookie is available to all requests into the application.
__Response to Added:__
Will a cookie for .example.com be available for www.example.com? Yes
Will a cookie for .example.com be available for example.com? Don't Know
Will a cookie for example.com be available for www.example.com? Shouldn't but... *
Will a cookie for example.com be available for anotherexample.com? No
Will www.example.com be able to set cookie for example.com? Yes
Will www.example.com be able to set cookie for www2.example.com? No (Except via .example.com)
Will www.example.com be able to set cookie for .com? No (Can't set a cookie this high up the namespace nor can you set one for something like .co.uk).
* I'm unable to test this right now but I have an inkling that at least IE7/6 would treat the path example.com as if it were .example.com.
The last (third to be exactly) RFC for this issue is RFC-6265 (Obsoletes RFC-2965 that in turn obsoletes RFC-2109).
According to it if the server omits the Domain attribute, the user agent will return the cookie only to the origin server (the server on which a given resource resides). But it's also warning that some existing user agents treat an absent Domain attribute as if the Domain attribute were present and contained the current host name (For example, if example.com returns a Set-Cookie header without a Domain attribute, these user agents will erroneously send the cookie to www.example.com as well).
When the Domain attribute have been specified, it will be treated as complete domain name (if there is the leading dot in attribute it will be ignored). Server should match the domain specified in attribute (have exactly the same domain name or to be a subdomain of it) to get this cookie. More accurately it specified here.
So, for example:
cookie attribute Domain=.example.com is equivalent to Domain=example.com
cookies with such Domain attributes will be available for example.com and www.example.com
cookies with such Domain attributes will be not available for another-example.com
specifying cookie attribute like Domain=www.example.com will close the way for www4.example.com
PS: trailing comma in Domain attribute will cause the user agent to ignore the attribute =(
The RFCs are known not to reflect reality.
Better check draft-ietf-httpstate-cookie, work in progress.
There are rules that determine whether a browser will accept the Set-header response header (server-side cookie writing), a slightly different rules/interpretations for cookie set using Javascript (I haven't tested VBScript).
Then there are rules that determine whether the browser will send a cookie along with the page request.
There are differences between the major browser engines how domain matches are handled, and how parameters in path values are interpreted. You can find some empirical evidence in the article How Different Browsers Handle Cookies Differently
Will www.example.com be able to set cookie for .com?
No, but example.com.fr may be able to set a cookie for example2.com.fr. Firefox protects against this by maintaining a list of TLDs: http://securitylabs.websense.com/content/Blogs/3108.aspx
Apparently Internet Explorer doesn't allow two-letter domains to set cookies, which I suppose explains why o2.ie simply redirects to o2online.ie. I'd often wondered that.
I was surprised to read section 3.3.2 about rejecting cookies:
https://www.rfc-editor.org/rfc/rfc2965
That says that a browser should reject a cookie from x.y.z.com with domain .z.com, because 'x.y' contains a dot. So, unless I am misinterpreting the RFC and/or the questions above, there could be questions added:
Will a cookie for .example.com be available for www.yyy.example.com? No.
Will a cookie set by origin server www.yyy.example.com, with domain .example.com, have it's value sent by the user agent to xxx.example.com? No.
I need to set a cookie from my main domain, read then remove the cookie from a subdomain. But I also need to possibly set that cookie again on the domain in the future, and read it later on the subdomain. Basically, a stream of one-way communication. I cannot have the main domain handle unsetting the cookie, because it could be months between users hitting the main domain and the subdomain.
I set a cookie on my domain, like so:
document.cookie = "mycookie=testcookie;domain=example.com;max-age=31536000;";
I access it just fine on another subdomain, as such:
document.cookie.replace(/(?:(?:^|.*;\s*)testcookie\s*\=\s*([^;]*).*$)|^.*$/, "$1");
I then try to kill it from the subdomain:
document.cookie = "mycookie=;domain=example.com;max-age=0;";
That does not work. Cookie is still set.
However, setting it like this clears it:
document.cookie = "mycookie=;domain=example.com;max-age=31536000;";
It now returns "" when asking for it from the subdomain.
But... if I go back to the domain and set it again, and I can see it has been set, the subdomain still returns ""
Is there some sort of... hierarchy of cookies I'm missing? I'm unsure how this behaves or how to overcome this.
In order to enable this you have to place a period . before the root domain, like so: .example.com This is important because of the way the cookie standardization is setup. This format should be compatible with most modern browsers.
In addition, the path must be identical when accessing or modifying the cookie across different subdomains. The easiest way to do this is to just use the root path for the domain, /. For example, if you set the cookie from sub1.example.com/page1 and try to access it from sub2.example.com/page2, even though you set the domain as .example.com you also have to set the path=/ in order to access it and modify it from any path on other subdomains.
Ultimately:
document.cookie = "mycookie=testcookie;domain=.example.com;path=/;max-age=31536000";
will enable you to set it and
document.cookie = "mycookie=;domain=.example.com;path=/;max-age=0";
will let you delete it.
So I have a private CDN (can't access data through S3, only by signed URL & cookies) using CloudFront that holds some files for a web application.
One of the pages on my site displays an image whose source lives on the cdn.
<img src="cdn.example.com/images/file.jpg">
Now when I generate a signed URL on the server I can just pass it to the client and set it as source...Easy
But when I try to do the same thing using signed cookies I run into 2 problems:
After generating the signed cookies server-side, I set them using res.cookie but I'm not sure how to find them in response on the client side.
In the event of actually getting the cookie on the client side (in angular/javascript), how to I "set" it so that when the browser tries to grab the image in the above mentioned html it allows access?
I'm using node, express, and cookie-parser.
I'm fairly new to this stuff so any help is appreciated
Have you checked that the domain for the cookie is the same or a subdomain of the CloudFront CDN?
The cookie will be included in the request to the CloudFront distribution only if it is coming from a related domain. For example, if you are testing locally using "localhost" that won't work as the cookie domain is "localhost" but the signed cookie domain is "cdn.example.com".
To ensure that the domain is correct:
Set up a CNAME for the CloudFront Distribution e.g.
http://cdn.example.com
Make sure the signed cookie has the correct
domain e.g. domain:'*.example.com' will match against the domain.
There's a good article here:
https://www.spacevatican.org/2015/5/1/using-cloudfront-signed-cookies/
There's also a good node module for creating signed cookies:
https://github.com/jasonsims/aws-cloudfront-sign
Using this module you would do something like:
const options = {
keypairId: YOUR_ACCESS_ID,
privateKeyPath: PATH_TO_PEM_FILE
};
const signedCookies = cf.getSignedCookies("http://cdn.example.com/*", options);
for (const cookieId in signedCookies) {
res.cookie(cookieId, signedCookies[cookieId], {domain: ".example.com"});
}
Note the way I set the domain. If not explicitly set it will default to the one that made the request, which is probably not what you want.
Last thing, to test this locally, I set up port-forwarding on my home network and created a CNAME in GoDaddy to point to my home IP e.g. "test.example.com". I then used "http://test.example.com" instead of "http://localhost". This created a cookie with the subdomain "test.example.com". Finally, I created another CNAME in GoDaddy called "cdn.example.com", pointing it to the CloudFront URL. I used the wildcard domain in my signed cookie, ".example.com" and because I now have the signed cookie on the same domain "example.com" it's passed to CloudFront and boom we have liftoff!
For those trying to access a protected resource in CloudFront from a different domain you can not set the cookies cross domain so you're limited to using Signed URLs instead. However you can use javascript on the CloudFront site to use the parameters in the Signed URL to create a Signed Cookie directly in CloudFront. I put together a simple JS script that does just that.
aws-signed-cookie-from-signed-url.js
build signed url in www.mysite.com that points to CloudFront url www.cloudfronturl.com/sample/index.html
included the JS in the CloudFront resource "sample/index.html"
upon the user using the signed URL, index.html will create the SignedCookie which will allow all additional navigation within www.cloudfronturl.com/sample to work based on the cookie
I have www.mysite.com and static-cookieless.mysite.com. My www site seems to be setting cookies on mysite.com thus my static site is no longer cookieless. How do i set cookies to only my www site?
I am using plain javascript (well, jquery.cookie but i know how to edit that easily)
document.cookie = 'cookie_name=' + cookie_value+ ',path=/,domain=mydomain.com';
May be the link below will be useful
http://javascript.about.com/library/blwcookie.htm