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.
Related
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.
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?
There doesn't seem to be much information around on forcing Cookie values in JMeter (2.8).
I'd like to be able to set a cookie at the start of a thread (AWS LoadBalancer ID), so that i can select a specific ID each time. The reason for this is that AWS gives the same ELB ID every time unless you change IP. I want to test more than one.
I have tried setting user-defined cookies in the HTTP Cookie Manager without success. (nothing is added)
I have also tried adding a COOKIE_Test to HTTP Header Manager without success. (adds to the header but doesn't treat as cookie)
Might not be possible?
Update: Adding the domain entry fixed it...
On inspecting the normal set-cookie, it omitted the domain, so i did the same...
I guess Cookie Manager ignores and user-defined cookies with null values.
Adding the domain entry fixed it
On inspecting the normal set-cookie, it omitted the domain, so i did the same...
Cookie Manager ignores any user-defined cookies with null values.
Did you try using the Cookie Manager User Interface?
http://jmeter.apache.org/usermanual/component_reference.html#HTTP_Cookie_Manager
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.
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.