What is the difference between local.test.com and .local.test.com ? The screenshot is from Chrome.
The leading dot means that the cookie is valid for subdomains as well; nevertheless recent HTTP specifications (RFC 6265) changed this rule so modern browsers should not care about the leading dot. The dot may be needed by old browser implementing the deprecated RFC 2109.
RFC 6265 section 4.1.2.3
For example, if the value of the Domain attribute is "example.com", the user agent will include the cookie in the Cookie header when making HTTP requests to example.com, www.example.com, and www.corp.example.com. (Note that a leading %x2E ("."), if present, is ignored even though that character is not permitted, but a trailing %x2E ("."), if present, will cause the user agent to ignore the attribute.)
local.test.com will be used for the domain, while .local.test.com will be used for subdomains too.
From the article The definitive guide to cookie domains and why a www-prefix makes your website safer:
Conclusion
Although the definitions are somewhat different, we can simplify it
for any of these implementations as:
When no domain is set in the cookie, the cookie should only match the
exact host name of the request. [NOTE: this is different from returning a Set-Cookie with a domain without a dot!] No sub domains, no partial matches.
This means simply not including the domain attribute – it is not valid
to set an empty domain attribute. Unfortunately, Internet Explorer
appears to treat this as the host name along with any subdomains.
When setting a domain in the cookie, the safe choice is to have it preceded
by a dot, like .erik.io. The cookie will match with all sub domains.
Setting a cookie domain without a preceding dot, like erik.io, is
invalid in RFC 2109 implementations, and will produce the same
behaviour as with a preceding dot on other implementations. There is
no way to restrict a cookie to a specific explicitly set domain,
without sub domains being included.
Other worthwhile observations:
In all RFCs, a specified cookie domain must match the current host
name, per normal matching. Setting a cookie for www.erik.io in a
response from erik.io is not valid, as a cookie with domain
www.erik.io does not match erik.io, the former being more specific.
In RFC 6265, domains are explicitly lower cased when parsing the
Set-Cookie header.
The leading dot in ".local.test.com" is just how chrome views cookies with a "Domain=local.test.com" set (or a "Domain=.local.test.com", which is the same).
Set-Cookie definitions without "Domain=something" views the domain (=host) without a leading dot.
So the leading dot in chrome don't reflect whether or not a leading dot was used from the server, but whether or not that cookie had a "Domain=something" in its definition from the server. (And if it had, the cookie will also be sent to sub-domains).
At least this is what my tests show. Chrome should make this easier to read, for instance view the exact string that defined the cookie and when it was received.
Related
I've been doing some research on cookies in Django for some time now.
However, I don't understand the following.
The default setting in django for the SESSION_COOKIE_DOMAIN is None so the domain attribute will be empty.
Django sets the session cookie in the session middleware:
response.set_cookie(
# ...
domain=settings.SESSION_COOKIE_DOMAIN,
)
The set_cookie function from the response object has the following relevant part if the domain is None which is the default setting in Django:
if domain is not None:
self.cookies[key]['domain'] = domain
Therefore, I assume that the domain in the cookie header is omitted.
I've read this great article about cookies and user2864740 made a nice conclusion about it:
"When no domain is set in the cookie, the cookie should only match the exact host name of the request.
No sub domains, no partial matches.
This means simply not including the domain attribute – it is not valid to set an empty domain attribute."
1.) Why does the cookie still work if it's not valid to leave the domain attribute empty or did I missunderstood something here?
2.) Let's assume I own the domain example.com
I don't modify the default settings from django so SESSION_COOKIE_DOMAIN is None
If I inspect the cookies for the domain example.com I see the following:
Name: sessionid
Value: XXXXXX
Host: example.com
I thought setting a cookie domain without a preceding dot is invalid. Why does Django not use .example.com?
Is it basically the same if the cookie domain is example.com because it will produce the same behaviour as with a preceding dot?
3.) Did I understand it correctly that if I set a cookie on example.com (without www) the cookie will also be available on all subdomains and it's currently not possible to set a cookie only on the main domain that is not available on subdomains.
1.) Why does the cookie still work if it's not valid to leave the domain attribute empty or did I missunderstood something here?
The code you just pointed to makes clear that no domain is set in the response; the key is simply not included. What would be invalid (more precisely, "undefined"), would be including the key Domain but leaving out an attribute value. Django doesn't do that.
2.) I thought setting a cookie domain without a preceding dot is invalid. Why does Django not use .example.com?
First, you have that backwards. RFC 6265 says that a leading dot "is not permitted" (though it will simply be ignored if it's there).
Secondly, the cookie details you've shown don't include a Domain key. "Host" is not a cookie attribute; that's presumably just Chrome telling you where the cookie came from.
3.) Did I understand it correctly that if I set a cookie on example.com (without www) the cookie will also be available on all subdomains and it's currently not possible to set a cookie only on the main domain that is not available on subdomains.
Right.
I need to read a cookie created on https://sub1.domain.com from http://origin.domain.com using ColdFusion. I've seen a lot of info about how to create a cookie in a subdomain using CFCOOKIE, but I don't know how to access a cookie that already exists.
Will the HTTPS make this impossible anyway?
ADDENDUM:
The checked answer below correctly addresses the question as worded above. In my case, it did not work. I should have explained: The cookie on sub1.domain.com is created by a hosted third party product - not written in coldfusion and not under my control.
This is really quite easy. When you create the cookie, give it a domain attribute equal to your domain. The important part to remember is that it MUST have a leading dot.
<cfcookie name="mycookie" value="myvalue" domain=".mydomain.com" path="/" />
The leading dot tells the browser to send the cookie to any subdomain of mydomain.com which would include sub.mydomain.com and blah.mydomain.com.
You would then be able to access the cookie from any of the subdomains just as you would any other cookie:
<cfset thevalue = cookie.mycookie />
You should do this as a best practice to support older browsers.
Here is the statement from RFC2109: HTTP State Management Mechanisms that could affect older browsers
"To prevent possible security or privacy violations, a user agent
rejects a cookie (shall not store its information) if… The value for
the Domain attribute contains no embedded dots or does not start with
a dot."
I believe this is overridden by RFC 2965: HTTP State Management Mechanism which states
"Domain=value OPTIONAL. The value of the Domain attribute specifies
the domain for which the cookie is valid. If an explicitly specified
value does not start with a dot, the user agent supplies a leading
dot."
Which explains why it might be working for you in, presumably, a modern browser. I would still suggest you add it.
Django URLValidator will raise a validation error for this website URL because of the underscore:
http://beauharnois_bupa.tripod.com/
From what I've read some says that it's not a valid domain name, some say it is and the RFCs seems to say that it's legal in the subdomain label but not in the hostname.
My guess is that it is legal in the subdomain label since the website mentioned above works..
Who's right ?
Underscores are not valid characters, even in subdomains, so it will be marked as invalid. However, some sites that dynamically route requests based on a subdomain component do allow underscores, even though they're technically an invalid character. So you might be able to navigate to the URL, even though it's technically not valid.
RFC 1035 discusses the structure of a domain name.
according to Can (hostname) subdomains have an underscore "_" in it? it should be legal.
It is perfectly legal to have an underscore in a domain name. Let me quote the standard, RFC 2181, section 11, "Name syntax":
I've noticed that many sites create cookies named with a leading underscore. I've also seen similar in defaults for various web frameworks.
What is the significance of the leading underscore in cookie names?
Is it simply a convention, or is there a technical reason?
At the time this question was asked, there wasn't a specific technical reason. However, since about 2015 there has been support in browsers for two specific "cookie prefixes":
__Secure- prefix: Cookies with names starting with __Secure- (dash is part of the prefix) must be set with the secure flag from a secure page (HTTPS).
__Host- prefix: Cookies with names starting with __Host- must be set with the secure flag, must be from a secure page (HTTPS), must not have a domain specified (and therefore, are not sent to subdomains), and the path must be /.
These solve some historical security problems with cookies. By default it is possible for subdomains to set cookies on parent domains, which violates some expectations around the Same-Origin Policy. And it's possible for http:// URLs to set and overwrite cookies that were originally set via an https:// URL. By using these cookie prefixes you can opt out of those problems and into a more secure cookie paradigm.
if I have a domain example.com, is there any way to make cookies valid only for that specific domain and not for sub-domains like www.example.com?
I know I can set it to only www.example.com, but can it be without a sub-domain?
Cookies are identified by the combination of their name, domain, and path. So if set correctly, you can limit it's scope to a specific domain/sub-domain and path.
Read Wiki's HTTP Cookie's Attribute Section
or RFC2965
Strictly speaking a cookie carrying the qualifier ";domain=example.com" should not be visible to the "www.domain.com" domain. Whereas ";domain=.example.com" would be visible to the www host.
However I would be very wary of this. I haven't tested this recently but I wouldn't be surprised to see some browsers not conforming properly to this.