cookie path protection within same domain

Question

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?

Answer 1

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.