I'm trying to figure out a way to make cookie-based authentication work, when the frontend and the backend are two different subdomains, without exposing myself to the CSRF threat.
Currently, i'm resorting to setting the cookie attribute sameSite to "None". Problem is, that this totally exposes the site to CSRF attacks.
For example,this is my cookie with the sameSite set to "lax":
cookieName=cookieValue; expires=Thu, 01 Jan 1970 00:00:00 GMT; Path=/; httponly; SameSite=Lax; Secure; Domain=some-sub-domain.localhost;
If my React app runs on locahost:3000, which is the same domain but different subdomain(and port..), this works only with sameSite=None. If sameSite is changed to "lax" or "strict", i get the following error, in the network tab, next to the set-cookie header:
This attempt to set a cookie via Set-Cookie header was blocked because it had the "SameSite=Lax" attribute but came from a cross-site response which was not the response to a top-level navigation.
I tried every possible configuration(including ".localhost"), and the only thing that seems to work is setting the SameSite to "None", but this would totally expose my site to CSRF attacks(assuming i do not incorporate some CSRF token, which is a different story).
My idea is to simply allow cookies to travel between subdomains, while blocking them on different domains. I mean, any subdomain would eventually be under my control.
Can it be done?
If anybody is interested, i found the "problem":
It was "localhost". It's not a "normal" domain. It's not localhost.com, or localhost.net- it's just plain localhost.
Therefore, setting up "subdomains" like frontend.localhost and backend.localhost doesn't work(unless you use sameSite=none), because those are actually totally different domains, not subdomains
To overcome this issue locally, you should set up virtual hosts in your operating system's hosts file. Something like frontend.local.xyz and backend.local.xyz. "local.xyz" is the actual domain in this case, and the others are subdomains. This solves the "problem", and allows a "strict" cookie to travel between them.
Note that this would still NOT work, if your domain is in this list:
https://publicsuffix.org/list/public_suffix_list.dat
I am running WordPress 5.3.2 on Apache/2.4.29 (Ubuntu) 18.04 on a Digital Ocean droplet.
My client requested the following:
All cookies transferred over an encrypted session, in particular session cookies, should be marked as 'Secure' and all session information should be transmitted over HTTPS.
The HttpOnly flag should also be set within the cookie
So, I defined the following in the virtual host:
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure;SameSite=Strict
I then tested the header response and could see my Set-Cookie defined.
The problem is, I now can't login to WordPress. WordPress says:
ERROR: cookies are blocked or not supported by your browser. You must
enable cookies to use WordPress.
What am I doing wrong?
Strict is probably more restrictive than you want, as this will prevent cookies from being sent on initial cross-site navigations, e.g. if I emailed you a link to a page on your blog, when you first followed that link, the SameSite=Strict cookies would not be sent and it might appear as if you were not logged in.
SameSite=Lax is a better default here. Then I would explicitly look at setting SameSite=Strict or SameSite=None on individual cookies where you know the level of access required.
The HttpOnly attribute is also blanket preventing all of your server-side set cookies from being read by JavaScript. You may well have functionality on your page that requires this.
Finally, a blanket approach here is probably overkill - as it looks as if you will be appending this snippet to every outgoing cookie header, even the ones that already include those attributes. This is likely to cause some unpredictable behaviour. I would either do this on a specific allow-list basis by checking for explicit cookie names or I would alter the regex to only set this if those attributes are missing.
A late answer. But if it helps someone:
Put these values in php.ini
session.cookie_httponly = 1
session.cookie_secure = 1
Of course you should have a valid https certificate.
I have a question related to Share cookie between subdomain and domain - what would happen if I set the domain while setting cookie as .com? Would the cookie be available to all .com websites?
Well-configured user-agents should reject such cookies, as explained in RFC 6265 section 5.3:
If the user agent is configured to reject "public suffixes" and the domain-attribute is a public suffix:
If the domain-attribute is identical to the canonicalized request-host:
Let the domain-attribute be the empty string.
Otherwise:
Ignore the cookie entirely and abort these steps.
NOTE: A "public suffix" is a domain that is controlled by a
public registry, such as "com", "co.uk", and "pvt.k12.wy.us".
This step is essential for preventing attacker.com from
disrupting the integrity of example.com by setting a cookie
with a Domain attribute of "com". Unfortunately, the set of
public suffixes (also known as "registry controlled domains")
changes over time. If feasible, user agents SHOULD use an
up-to-date public suffix list, such as the one maintained by
the Mozilla project at http://publicsuffix.org/.
Is it possible to set a cookie for http://www.example.com from a PHP file located at https://secure.example.com? I have some code that was given to me, that appears to try and fails at this. I was wondering if this is possible at all.
Webpages can only set cookies for the second (or higher) level domain that they belong to.
This means that secure.example.com can read and set cookies for secure.example.com or .example.com, the latter of which can also be read and set by www.example.com
One last note: If the secure flag is set on a cookie, it can only be read and set over an https connection.
If you set the cookie domain to ".example.com", the cookie will work for all subdomains.
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.