I've got a ColdFusion 9 application set up on a certain domain example.com,
and another one set up on a subdomain of it, subdomain.example.com.
On Application.cfc, both apps have session management enabled and host-specific (not domain-specific) cookies:
SessionManagement = true;
SetDomainCookies = false;
When using IE, the first visit to example.com will set a pair CFID;CFTOKEN. But it is a known behaviour that IE will send these cookies to all nested subdomains if the DOMAIN attribute of the cookie is not specified (Internet Explorer Cookie FAQ, Q3).
Unfortunately, this is the case with the SESSION scope. The following screenshot proves how the cookies sent to/from IE have no domain attribute set:
This is causing unexpected behaviour, as the application on subdomain.example.com will receive two different pairs of CFID and CFTOKEN (from both example.com and subdomain.example.com). ColdFusion will interpret this as an invalid answer from the browser and will generate a new pair of tokens, thus finishing the previous session.
One solution I can think of is replacing the functionality of SESSION with CFCOOKIE, always specifying the domain, eg. <cfcookie name="foo" value="bar" domain="#CGI.SERVER_NAME#" />
Any other solutions?
Or a way of specifying the domain for the cookies that the SESSION scope sets?
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.
As the owner of domain example.com with many content what security risks arising from providing subdomain to third party company. We don't want to share any of the content and the third company would have complete control over the application and machine hosting the subdomain site.
I'm concerned mainly about:
Shared cookies
We have cookies .example.com, so there will be sent also in the requests to subdomain. Is it possible for us to point A record to reverse proxy where we strip the cookies and send the request to third party provider without them?
Content loading from main domain
Is it possible to set document.domain to example.com and do XMLHttpRequest to the example.com?
Cross site scripting
I guess that it would be no problem because of the same origin policy. Subdomain is treated as separate domain?
Any other security issues?
We have cookies .example.com, so there will be sent also in the
requests to subdomain. Is it possible for us to point A record to
reverse proxy where we strip the cookies and send the request to third
party provider without them?
Great idea, you could do this yes, however you will also need to set the HttpOnly flag, otherwise they would be able to retrieve them with JavaScript.
Is it possible to set document.domain to example.com and do
XMLHttpRequest to the example.com?
No, subdomains for Ajax are treated as a different Origin. See this answer.
I guess that it would be no problem because of the same origin policy.
Subdomain is treated as separate domain?
JavaScript code could interact with each other subdomains - but only with the cooperation of your site. You would also need to also set document.domain = 'example.com'; If you do not do this, you are secure against this threat.
See here:
When using document.domain to allow a subdomain to access its parent
securely, you need to set document.domain to the same value in both
the parent domain and the subdomain. This is necessary even if doing
so is simply setting the parent domain back to its original value.
Failure to do this may result in permission errors.
Any other security issues?
You need to be aware of cookie poisoning. If evil.example.com sets a non host-only cookie at .example.com that your domain believes it has set itself, then the evil cookie may be used for your site.
For example, if you display the contents of the cookie as HTML, then this may introduce XSS. Also, if you're using the double submit cookies CSRF prevention method an evil domain may be able to set their own cookie value to achieve CSRF. See this answer.
We are developing a Kohana Framework-based website with multiple subdomains, using the subdomain prefix value as the key for content and configuration filters...
This works great until a user with an active session to one of the subdomains visits a parent domain... Then they get a combination of BOTH cookies from each domain, which can lead to undesireable effects (parent domain settings inherited by subdomains).
For instance, I go to https://test.ourdomain.com and get a cookie with a session ID in it. All further requests to this URL or folders/files under this host have that cookie sent with the request in the headers. When I then go to https://sub.test.ourdomain.com, BOTH the cookie generated for that URL, PLUS the cookie generated for the parent url (test.ourdomain.com) is propogated. These cookies contain identically keyed information with varying values, and sometimes the values for the parent override the one for the child, producing undesireable effects on the child.
Preferably using Kohana's cookie settings, what can I do to limit the cookie propogation from parent domains to children?
You can set cookie settings in your bootstrap.php file.
By the looks of the documentation, you should be able to append Cookie::$domain = "test.ourdomain.com"; or Cookie::$domain = "sub.test.ourdomain.com"; to the end of your bootstrap.php file.
This should apply globally where ever cookies are used (including native and cookie-based sessions). You might have to clear your current cookies when making this change before noticing its effects.
Edit: Just realized how old the question is, hopefully this can solve any future questions.
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.
I have a setup with the following domains:
mydomain.com
www.mydomain.com
There is one problem (tested on Internet Explorer):
if some cookie is set for mydomain.com, this cookie is also effective for www.mydomain.com even if I set a cookie with the same name for www.mydomain.com.
More specific examople:
1) the user chooses his prefered language on website mydomain.com and I set the cookie usrlng=en
2) next day someone else uses the same computer, naviagtes to www.mydomain.com and chooses his language, and I set the usrlng=de. But Internet Explorer keeps sending both cookies usrlng=en and usrlng=de to the server (I see this in Fiddler)! Why is it sending the same cookie twice and not overriding 'usrlng' with the subdomain value?
At the same time I see that PHPSESSID is being overwritten correctly for the subdomain, there are no two PHPSESSID cookies being sent to the server.
How can I fix the usrlng cookie and make it work the same way as PHPSESSID works?
You can also set a different save_path for each... so they don't share the sessions.
PHP example:
$subdomain = array_shift(explode('.',$_SERVER['HTTP_HOST']));
ini_set('session.save_path','D:\website_sessions\'.$subdomain.'\');
ini_set('session.save_path','D:\website_sessions\'.$subdomain.'\');
PHP needs access to write in the sessions directory.
For now I solved the problem by setting the 'host' of the cookie instead of 'domain'; 'host' property allowed to limit the cookie to mydomain.com or www.mydomain.com.
Maybe that is the only way to go and 'domain' cannot be set up to oveeride top level domain cookies.