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?
Related
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.
Given a cookie with the common attributes (name, id, etc), is there anyway we can identify if the cookie is a third-party cookie? By that we mean a cookie that has been placed by website B while visiting website A. At the moment, I can see no ways of achieving that but perhaps I've missed something. I'm working on a project related to user privacy online and would like to get a list of websites that left third-party cookies in user's browser. I use Mozilla Firefox Browser.
There's no way to tell when looking at the store of cookies. The issue is that a cookie is always first party with respect to some site; the third-party-ness relates to the provenance of the cookie. The only way to identify if a cookie was a third-party cookie is to examine the actual header which set the cookie and see if that cookie was set for a domain other than the originating one. Everything is made far more complex by the fact that a cookie can be set for a whole domain (thus foo.bar.com is allowed to set for .bar.com so that grill.bar.com will also see the cookie) and determining whether a suffix is a domain or not is not at all easy (e.g., some countries have multi-level domains).
The final problem is that it's easy enough for the site to request some resource from another domain for real, and set the cookie that way. That's formally not a third-party cookie, as it is being set by the domain it references, but it works in effectively the same way.
Every cookie is set for a domain. You can compare domain names to identify 3rd party cookies. But maybe I did not fully grasp your question.
Based merely on list of cookies created so far in the browser, there is no way to say if a cookie is a third-party cookie.
How can I access a cookie on ".bar.com" from javascript in a webpage at "foo.bar.com"?
document.cookie (in Chrome) doesn't appear to contain this cookie even though I can see it on the Resources tab in Chrome and see that its send to the web server on a POST.
when setting the cookie you define the domain it can be read from, subdomains also work.
There also exist http-only cookies, they can't be read using javascript but you will see them in the http request.
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.