So I have an iframed page of my subdomain in my main domain, and this subdomain page requires user to be logged in and have a membership to be accessed.
Basically I need that the session variables and cookie are passed to the subdomain in order for the iframe to load.
How can I achieve this in Nginx ?
Cookies have a domain attribute, which specifies which domains they will be sent to from the client. For example, in PHP's setcookie function the 5th argument accepts a $domain string to set in the cookie. By default it's left blank which means it will use the domain the request came from when the client receives it.
The domain that the cookie is available to. Setting the domain to 'www.example.com' will make the cookie available in the www subdomain and higher subdomains. Cookies available to a lower domain, such as 'example.com' will be available to higher subdomains, such as 'www.example.com'. Older browsers still implementing the deprecated » RFC 2109 may require a leading . to match all subdomains.
So if you set your cookie to your main domain the client UA won't have a problem making it available to your sub domain.
Now, iframes are little trickier, however. For example, Internet Explorer can treat iframes differently due its varying privacy policy rules and block all cookies from an iframe. See this question for more details. However, Nginx really shouldn't play anything more than a passive role in all of this.
Related
In a scenario where you've potentially got two cookies with the same name but with different subdomains, one with WWW and the other without. Can you read one specifically? In this case the cookies domain was never explicitly set, however, when I check the browsers I often see what appear to be duplicate cookies with only the subdomain being different. Presumably at the time of creating the cookie the browser dictated the domain to assign it to.
So for example, the cookie is named 'test' and the domain is www.example.com
When I check my cookies I can see 'test' in .example.com and www.example.com
Is it possible in C# or Javascript to read in a named cookie from a specific subdomain?
I know I can use this in C#
Request.Cookies["test"]
But I believe this
Request.Cookies["test"].Domain
Is only for setting the domain value.
Is there a reliable way I can check for and read the value of the www.example.com cookie?
I'm developing a page/form for a campaign inside my company. However, the first step is to check if the person is logged in. This is easily checked against a cookie - CUSTOMER - that is set once they're logged in.
However:
1) I'm developing locally, not on the same domain, and, as a result can't see that cookie
2) The final campaign may or may not end up residing on the actual domain. They may end up using a vanity URL or something.
For purposes of this, let's assume I do NOT have access to the main domain where the cookie was set.
How can I read that cookie from off the domain? Oh, and since IT folks don't let us touch the back-end grumble, it has to be a JS solution.
Thanks!
You can't.
The only cookies you can read with client side JavaScript are those belonging to the host of the HTML document in which the <script> is embedded.
By setting withCredentials you can support cookies in cross-origin requests, but they are handled transparently by the browser and JS has no direct access to them (the XHR spec goes to far as to explicitly ban getAllResponseHeaders from reading cookie related headers). The only way for a cross-origin request to get access to cookies is for the server (which you say you don't have access to) to copy the data into the body or a different response header).
You can if you can install server side components.
You can use a dedicated domain to host your cookie and then share it using XSS technics
When dom1.foo.com logs in then you register a cookie on cookie.foo.com using an Ajax XSS call then when you go on dom2.foo.com you have to query cookie.foo.com with your XSS api
I' ve played with it some time ago
https://github.com/quazardous/mudoco/blob/master/mudoco/README.txt
It's just some sort of POC..
I'm looking at using Amazon Cloudfront to distribute my JavaScript.
What I'm not clear on, however, is what happens to cookies if I do that. For example, if my site is example.com, and I'm including JavaScript from foo.cloudfront.net, does that JavaScript have access to cookies I set on example.com and visa versa? What's the best approach for cookie safety when you are serving your assets from another domain?
The javascript executes in the context of example.com, so no matter where it's served from will be able to access those cookies, and those cookies only. This encapsulation, which presumably is what you meant by cookie-safety, is enforced by the browser and shouldn't be something that you need worry about.
There might be third party cookies set in the distribution of the files (that depends on the distribution network, in this case Amazon's), although that won't be visible to the javascript, nor should it interest the javascript. If there are third party cookies set you should mention that in your privacy policy.
And to answer the question in the header; no, setting a cookie in code distributed from another domain does not count as third-party, since it executes under example.com, and will therefore only be able to set cookies under than domain.
Doesn't matter where the javascript code itself is hosted, what's important is the context in which it's running in - so the cookie will be correctly set to whatever host your main page is loading from...
I am developing a web app that is served from domain.ext. This web app uses cookie–based sessions and provides users with the ability to host a web pages containing custom JavaScript on a subdomain, ex. sub1.domain.ext, sub2.domain.ext. The subdomains do not use cookie–backed sessions.
Given this setup, is it possible to ensure the following?:
users at sub1.domain.ext cannot read or write a cookie for domain.ext (i.e. domain.ext sessions cannot be stolen or hijacked by JavaScript embedded in a page at sub1.domain.ext).
JavaScript embedded in a page at sub1.domain.ext cannot read or write cookies at sub2.domain.ext, and vice versa.
I’ve tested out a few things, for example it appears to be possible to interact with domain.ext’s cookies from sub1.domain.ext by running document.domain = 'domain.ext' inside the sub1.domain.ext’s window. Is there some way to prevent this, for example by specifying some kind of policy when setting the domain from domain.ext?
You can't specify that a cookie should only be valid for example.com by setting the domain parameter. If you set domain=example.com, it will be valid for *.example.com.
Setting a cookie on example.com without a domain parameter sets a cookie for only example.com in most browsers. But not IE.
So, if you ever want to have subdomains with separate cookie contexts, you should serve your site from www.example.com only. As Gaby said, naturally you can still support access through example.com by giving a 301 redirect to the www version.
Say there is a site foo.com which loads JavaScript from site bar.com. Now, say the JavaScript from site bar.com tries to read cookies using document.cookies. I was under the impression that using JavaScript, you can read all the cookies set in the browser irrespective of their source. But it turns out that the JavaScript from the site bar.com can only access cookies set by bar.com and not any other. If this is the case, how are script injection attacks which steal cookies carried out?
But it turns out that the JavaScript from the site bar.com can only access cookies set by bar.com and not any other.
That isn't true. What matters is where the HTML document containing the <script> element is, not the URL of the JS file that said <script> mentions in the src attribute.
I suspect your problem is that you are accessing document.cookies when the property is called document.cookie (Singular!)
They load scripts inside the attacked page.
For instance, when comments in a blog system get compromised, they contain a script element that is executed when the page is rendered. This script can get the cookies and send it to the attacker's server.
That's why you should never trust user input and disallow at least certain tags in comments (or translate every < to <). But don't do this on the client side, as this prevention technique can easily be circumvented; test for (and change) malicious input on the server side.
You can only access cookies which have been set for the given domain name. From the Wikipedia article on cookies:
Beside the name/value pair, a cookie
may also contain an expiration date, a
path, a domain name, and whether the
cookie is intended only for encrypted
connections. RFC 2965 mandates cookies
have a version number, but this is
usually omitted. These pieces of data
follow the name=newvalue pair and are
separated by semicolons. For example,
a cookie can be created by the server
by sending a line Set-Cookie:
name=newvalue; expires=date; path=/;
domain=.example.org.
The domain and
path tell the browser that the cookie
has to be sent back to the server when
requesting URLs of a given domain and
path. If not specified, they default
to the domain and path of the object
that was requested. As a result, the
domain and path strings may tell the
browser to send the cookie when it
normally would not. For security
reasons, the cookie is accepted only
if the server is a member of the
domain specified by the domain string.
If foo.com sent a cookie which had the domain name of bar.com, or even .com, then JavaSCript code on bar.com could read that cookie. However most browsers are configured to only accept cookies when the domain name matches, and would reject such a cookie.