My JavaScript application may be run in a subfolder at a strange web server.
Is setting Path attribute of a cookie secure enough to prevent stealing secret data (with money!) from a user for whom I set the cookie by programmers managing other folders of the same server?
https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies :
The Path attribute indicates a URL path that must exist in the requested URL in order to send the Cookie header.
Here it's said nothing about that the path must exist also in the requested URL also in order to allow JavaScript code of this path to retrieve the cookie.
Is it also secure when JavaScript History API is used to change the URL of the page without reloading?
It is not secure:
https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie#Security :
It is important to note that the path attribute does not protect against unauthorized reading of the cookie from a different path. It can be easily bypassed using the DOM, for example by creating a hidden <iframe> element with the path of the cookie, then accessing this iframe's contentDocument.cookie property. The only way to protect the cookie is by using a different domain or subdomain, due to the same origin policy.
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.
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 am implementing one advertising system in which when one user puts down script code into their website A. what I want to do at that time is set up a cookie into website A while it display response or resource of website B(Advertising System), so in present day when user comes again , I can log it's entry. I have read down this question and came to know that it is possible to set cookie into other website A when that website A is display content from another website B
In script I am executing one rest API and returning one response like below..
source_image = "http://example.com/media/format.png"
response = Response({'success':source_image})
response.set_cookie( 'cookie_name', 'cookie_value' )
return response
Now I am able to see cookie set in browser of the response of this url. But when I reload it ,cookie does not get display. Also why it is not getting display in the cookies section of the site in which I have put down script code.
Am I doing right thing to set up a cookie? And I have tried to set cookie's expiry date for 1 day. But still it is getting destroyed..Please help..
There are a few important things to know about cookies and browsers and how they interact across domains.
Websites can set cookies for their own website
Websites cannot set cookies for a different website
Cookies can be set on the response or using things such as JavaScript
The first two may seem confusing, especially when some sources say they are possible. It's important to note that they only affect cases where the response is directly setting the cookie using the Set-Cookie header, which allows a website to directly set a cookie. There are some special cases for things like subdomains, but in general you should not expect browsers to respect cookies set on other domains that you don't control.
If you were allowed to arbitrarily set cookies on other websites, this would open the door for websites to arbitrarily set and unset cookies you are using, even if they are unrelated. This would include the ability to log someone out across domains in just the response alone, which isn't possible.
The third point is important for cases like advertising, as cookies can be set using the Set-Cookie header (or response.set_cookie in Django) or using JavaScript through the document.cookie property. As JavaScript can included from any domain using the src property on <script> tags, any domain can manage cookies on another domain if it is included through JavaScript. This is important to how many analytics services, such as Google Analytics, work becuase it allows them to store unqiue cookies on each website for each user that is being monitored, even though they do not have full control over the response. They also typically use tracking beacons in the form of images to send data back to the external domain and associate it with the stored cookie.
The answer you linked to talks about this with images, but explains that it does not actually set the cookie on another domain. The cookie which is being set using the image or frame is stored only on the external domain, and cannot be accessed from the domain including the remote image.
Make sure that the HTTP header of "Set-Cookie" is being passed to the client in the HTTP response.
Try adding in the "domain" attribute for the cookie so the browser knows where to send the cookie.
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.