I have one Admin website (Example: http://www.admin.web.com/control/) and Public websites like (http://example.web.com and http://example.com)
I want to create one cookie from http://www.admin.web.com/control/ which will be shared to both website http://www.example.web.com and http://www.example.com.
Here both public websites are the same with different URLs
So to share cookie I am creating domain specific cookie
<cfcookie name="admin" value="xyz" domain=".web.com">
So above cookie which will be created from http://admin.web.com will be shared with http://example.web.com but not with http://example.com.
Can any one tell me how I will share same cookie for http://example.com?
The short answer is that you can't. As far as the users browsers are concerned admin.web.com and example.web.com are subdomains of the same (web.com) domain so they could be owned by the same person. This means you can set it up so that the sharing you've seen above works.
Unfortunately as you've seen example.com doesn't share a domain so you can't share them as domain cookies.
There are a couple of ways to get round this that I can think of off the top of my head, none of which are particularly nice:
You could probably get away with using an ajax callstraight to example.web.com from example.com with the contents of the cookie in the response to the page.
You could use an iframe in the example.com pages that points to the example.web.com page and then send the details from the read cookie back setting the same cookie then on example.com.
For sensible security reasons it's not really a good idea to do either but instead to look for the reason you're trying to share information across domains and try and figure out a way of avoiding it.
Related
I have a dedicated server, which hosts 2 domains, let's say A and B.
I know about the cross-origin policy, that is impossible to read the cookies from another domain, but is it somehow possible to do it when they have the same hardware/owner/server/file system, etc?
I have realized an interesting thing, I have ads on domain A, and there are a lot of cookies from ad networks. How they did do it? Can I do something similar with my two domains?
Thanks for the answers/suggestions, I have really no experience in this sphere.
when you run advertisements on your domain, you include some JavaScript code provided by these ad networks.
When the script is executed, the script can create and read cookies associated with domain from where the script came from.
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 understand that there are a number of ways/hacks to implement cross domain cookies such as iframe, redirects etc. I believe those methods are necessary when different app servers are serving each domain.
Now if both domains are served by the same app server, would there be an efficient and best practice method for handling these cookies? Could the app server in this case, just keep track of the origin and determine which users each request is associated to regardless of what target domain is being requested?
Any input would be greatly appreciated.
Bob
Cookies are how a server knows who's talking to it, so having both domains on the same server doesn't really help. When the request comes in, you have the source IP:port, user agent, cookies, and that's about it. IP isn't useful because of NAT (multiple users, one IP) and mobile (one user, multiple IPs--moving from cellular to wifi or vice versa). User agent has similar problems. The answers discussed in Cross-Domain Cookies are still the best options available.
Unfortunately, there's still not the super-direct way to share user data across domains. I found that the iframe implementation was the most re-usable.
To this end, I created an NPM module to simplify cross-domain sharing. It gives you a function to produce an iframe with a whitelist of your domains, and get/set functions that let you access that iframe from any whitelisted domain.
https://www.npmjs.com/package/cookie-toss
Hope this helps!
I am developing an app, which I will deploy on Heroku. The app is only used within an iframe on another site, so I don't care about the domain name. I plan to deploy my app on example.herokuapp.com instead of using a custom domain on example.com.
My app uses cookies, and I want to be sure that others cannot manipulate my cookies to protect my app against session fixation and similar attacks. If attacker.herokuapp.com is able to set a cookie for herokuapp.com, browsers will not be able to protect me, since herokuapp.com is not a public suffix. See http://w2spconf.com/2011/papers/session-integrity.pdf for a detailed description of the issue.
My question is: When browsers can't protect my users, will Heroku do it by blocking cookies for herokuapp.com?
Just wanted to post an update for anyone who ran across this question as I did. I was working on a similar problem, except that I wanted to purposefully allow access to the same cookie from two different heroku apps.
"herokuapp.com" and "herokussl.com" are now on the Public Suffix List, so your cookies should be safe if they are set for one of those domains. I ended up having to use custom domains in order to share cookies across both apps.
Heroku also released an article on the topic: https://devcenter.heroku.com/articles/cookies-and-herokuapp-com
I just tried to add a cookie from my Heroku app with the response header Set-Cookie: name=value;Path=/;Domain=.herokuapp.com, and to my disappointment, I could see the header intact in my browser. So the Heroku infrastructure does not detect and remove this cross-app supercookie.
I see three possible ways to protect a Heroku app against cross-app supercookies:
Don't use cookies at all.
Use a custom domain.
Verify that each cookie was actually set by your app, and restrict it to the client's IP address by checking the X-Forwarded-For header.
My feature request to Heroku would be that they should filter HTTP responses that goes through their HTTP routing, such that applications hosted on their infrastructure cannot set cookies with Domain=herokuapp.com.
It seems to me that, as long as you set the cookie for example.herokuapp.com, then the cookie is safe from manipulation. The cookie will only be presented to the app running on example.herokuapp.com and to herokuapp.com (where no app runs).
We are presently rewriting an in-production Django site. We would like to deploy the new site in parallel with the old site, and slowly divert traffic from old to new using the following scheme:
New accounts go to the new site
Existing accounts go to the old site
Existing accounts may be offered the opportunity to opt in to the new site
Accounts diverted to the new site may opt out and be returned to the old site
It's clear to me that a cookie is involved, and that Nginx is capable of rewriting requests based on a cookie:
Nginx redirect if cookie present
How do I run two rails apps behind the same domain and have nginx route requests based on cookie?
How the cookie gets set remains a bit of a mystery to me. It seems like a chicken-and-egg problem. Has anyone successfully run a scheme like this? How did you do it?
I think the most suitable solution for you problem would be:
Nginx at every request should check for some specific cookie, route
If it's presented and equals old, request goes to a old site
Otherwise request goes to the new site.
Every site (new and old) should check request for that cookie (route)
If cookie isn't presented (or wrong), your app should set it to the right value, and if request is for that site, just proceed it.
If not, it should send redirect, and we begin again with step 1