15

The answer to this question about how cookies are potentially vulnerable between sub-domains sparked my curiosity.

As far as I know, if a cookie is set on a sub-path of the same domain (www.example.com/dogs), then it is not accessible to any other path, unless it's a sub-folder of the path. i.e. neither www.example.com/cats nor www.example.com/ should have access to those cookies, but www.example.com/dogs/labrador would.

Reading further, I see it's possible to get the cookies from different paths:

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.

If that's the case, then what security (or even functionality) does the cookie-path provide? And if it can be read using an iframe, why isn't it accessible directly in javascript? Does this "restriction" actually give a false sense of security?

Community
  • 1
Yoav Aner
  • 5,299
  • 3
  • 24
  • 37
  • A hidden iframe element can be stopped by the framed path sending `X-Frame-Options: DENY` header, which whoever controls the server *should* be able to do. – iBug Apr 18 '21 at 13:30
  • @iBug An iframe is not the only way to get hold of a window reference; `window.open` is another. And `X-Frame-Options` has no effect, in this case. – jub0bs Jul 26 '22 at 11:53

1 Answers1

26

The cookie path doesn't provide any security (in most real-world situations).

It is important to understand that the cookie spec is ancient technology. It dates back from the earliest days of the web. The security model of the web has evolved since then, and become more carefully thought-out. The security model for cookies hasn't evolved correspondingly.

As another example of impedance mismatches between the web's security model and cookies, the same-origin policy treats www.example.com:80 as a different origin from www.example.com:81, but they are treated as identical for purposes of cookies. You can find more discussion of security oddities with cookies from Michal Zalewski.

Cookies can be read by Javascript. While the browser may take the path into account when Javascript tries to read cookies, this is not a security feature: the path is not a security boundary, so malicious Javascript on one page can still read cookies for other paths (e.g., by opening an invisible iframe with the proper path, injecting malicious Javascript into it, and then grabbing the cookie). The only effective security boundary is at the granularity of an origin. As a result, the bottom line from a security perspective is: malicious Javascript on www.example.com/dogs can read a cookie whose path is www.example.com/cats.

In practice, developers typically avoid these corner cases that are left over from earlier days, or at least avoid relying upon them to provide extra security. For instance, web developers should not rely upon the cookie-path to provide security (at best it reduces the number of cookies sent back, which could perhaps be used to reduce bandwidth in some situations). As another example, sites these days usually avoid serving content from non-standard port numbers, since that situation is another corner case that exposes unexpected semantics.

At this point, the cookie path is mostly a vestigial remnant of earlier days. It doesn't serve much purpose any longer, as far as I can tell, and if the cookie-path had never been introduced, today you'd probably never notice. But browsers still need to support it, for backwards-compatibility reasons. And so it goes, on the web. It is best to think of the web not as a carefully designed artifact but as something that evolved over time -- and as a result, has accumulated now-useless gunk, like our appendix.

D.W.
  • 98,420
  • 30
  • 267
  • 572
  • 4
    +1. One valid benefit of cookie paths, is if you need to have (for some reason) different cookies with identical names in the different paths. For example if you have two instances of the same application installed in parallel... The cookie path is simply a selector, to ensure the correct cookie gets sent to the correct application - but as you say it is not a security boundary. – AviD Mar 06 '12 at 06:56
  • Thanks D.W and @AviD. That's more or less what I thought. (+1 for the difference in SOP, didn't realise that either!!). However I am not sure "The cookie-path is ignored when Javascript tries to read a cookie" is entirely correct. You'd have to use tricks like iframes to do this. This is the part I wonder most about - why restrict javascript when it gives you no security anyway? – Yoav Aner Mar 06 '12 at 08:10
  • @YoavAner again, I think this has more to do with clarity, than any form of security enforcement. If the cookie is not in scope, why should you see it? Not that you *can't*, or shouldnt be *able* to, but by default there is no reason for it. – AviD Mar 06 '12 at 08:29
  • @AviD - makes sense, just that it might give a false sense of security. D.W. I've accepted your answer, but I think the sentence I mentioned above might still need correction or clarification. – Yoav Aner Mar 06 '12 at 08:59
  • 2
    @YoavAner, you are right. Sorry, on re-reading, I realized I mis-read your question. I've updated my answer accordingly. As far as why browsers restrict Javascript when it gives no security -- I don't know. Perhaps it is cleaner to stay consistent with how cookies are treated elsewhere in the browser. Perhaps it is, as AviD explains, to enable people to have two instances of the same application (or two different application with overlapping cookie names) installed at the same time -- not to provide a security boundary between them, but just to let them function. – D.W. Mar 06 '12 at 20:22
  • 3
    I think it is worth mentioning that using the "http-only" flag on cookies on different paths actually do prevents script access to reading cookie values across sub-paths. – PålOliver Aug 31 '16 at 07:16
  • @PålOliver yes and it is also worth mentioning that only the `set-cookie` header has the http-only and secure flags; the `cookie` header does *not* provide the information back to the server. JS code can create cookies with a path. The server code could be confused. – curiousguy Jun 16 '18 at 06:49
  • @PålOliver Sure, `HttpOnly` prevents scripts running in the context of the same origin from accessing the cookie, but if said script can read the entire page on the path to which the cookie is scoped, the cookie is of little value. – jub0bs Jul 26 '22 at 10:18