5

Lets say I am using a reverse proxy with URL rewriting that provides access to 2 different applications

http://www.example.com/app1/ and http://www.example.com/app2/.

I don't want those applications to be able to get access to each other cookies, especially because I want to contain a potential XSS vulnerability to one application only. Is it sufficient to set the path of the cookies accordingly? The http-only flag is not set in this scenario.

If setting the cookie path is not enough, I would be interested which additional steps should be taken.

|improve this question
  • 2
    "setting the cookie path is not enough" the path parameter is "not enough" for ANYTHING. Do NOT RELY on it for anything. – curiousguy Jun 12 '12 at 12:53
4

An XSS vulnerability on www.example.com means that all cookies relating to that domain can be read, regardless of path. (If app1 was http and app2 was https that would be slightly different, but i imagine they're not and it would rarely be the case).

Subdomains would work, eg. app1.example.com has different cookies to app2.example.com, assuming they've been set at the correct sub-domain (rather than just example.com).

|improve this answer
5

No. The JavaScript Same Origin Policy allows you to execute code in any document on a given hostname from any other document on the same hostname (+scheme+port).

Compromised code in www.example.com/app1 can interact with www.example.com/app2 through eg forms, iframes and AJAX, giving it an almost complete ability to pose as the genuine user - which is more than just a problem of leaking cookies. CSRF protection does not help you as the CSRF token can itself be read by the script code.

The path= feature of cookies is only of use for preventing accidental clashes; it has no security value. You should only reverse-proxy two applications into the same hostname if they fully trust each other.

Otherwise look at subdomains or full separate domains. (Subdomains prevent apps from reading each other's cookies, but don't prevent a domain= being used to make a cookie available to the other site. This isn't typically a security problem as such, but can be an annoyance when it masks a real cookie and stops the app from working.)

|improve this answer
  • "This isn't typically a security problem as such" being able to force another user to login as me is a security issue in most cases! – curiousguy Jun 12 '12 at 14:23
  • @curiousguy: well, in certain corner cases (eg getting them to post information as you so you have access to it) it could be an issue, but more often being able to write an interfering cookie is more of a nuisance issue. It's less obvious and consistently a problem than reading third-party cookies, and it's often considered not worth solving (for cost and marketing reasons) when the only solution is to buy completely separate domains for each application. – bobince Jun 12 '12 at 15:06
  • It is not a security issue only if you never ever upload confidential information to your account! – curiousguy Jun 13 '12 at 17:54
3

There is a possibility that a cookie from app1 and app2 can be stolen due to a XSS vulnerability. Since you specifically mentioned XSS, a DOM based XSS that runs an javascript in clients browser in the first app can read the cookie in the second app since the domain name is same www.example.com.

For example - If app1 is vulnerable to XSS then http://www.example.com/app1/submit.php?subject=<SCRIPT>alert(document.cookie);</SCRIPT> will read cookies set for http://www.example.com/app2/ too.

Once the cookie is read, it can be posted some where else using a javascript. This is irrelevant to cookie path and CSRF. So setting cookie path will not save you from XSS stealing other app's cookie.

|improve this answer
  • are you sure your example is correct? it would seem that http://www.example.com/app1/submit.php?subject=<SCRIPT>alert(document.cookie);</SCRIPT> would only include cookies for app1, and you'd have to work a bit harder to get cookies from app2. – cnst Mar 15 '13 at 18:34
2

You should take the CSRF attack into consideration too.

Adding the path in your cookie only avoid having the cookie to be shared between the two application, it's does not apply to XSS.

With CSRF attack, if someone is connected in your two apps, and one of them have a XSS flaw, I can create a form post that will put content in the other app, like deleting entries.

|improve this answer
  • Thanks for your answer. Do I understand you correctly, that a vulnerability in the script www.example.com/app1/foo.php would be able to get access to a cookie set for the path /app2/ ? – Demento Jun 12 '12 at 8:57
  • If you didn't take in consideration the CSRF attacks, yes. But it's the same for every website that don't prevent CSRF attacks. Read more about it to a better understanding : if you don't ensure that the button clicked is from your website and not an other, everyone can trick your users. – Cyril N. Jun 12 '12 at 9:01
1

According to https://developer.mozilla.org/en-US/docs/DOM/document.cookie:

It is important to note that the path restriction does not protect against unauthorized reading of the cookie from a different path. It can easily be bypassed with simple 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 cookie access is by using a different domain or subdomain, due to the same origin policy.

So, you have to use different domains for different apps if security is important, setting Cookie path alone will not protect you against JavaScript-based XSS between the apps at all.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.