The Web Application Hacker’s Handbook Discovering and Exploiting Security Flaws

If the application specifies a path attribute that does not contain a

trailing slash, then the browser will not interpret this as representing an actual

directory. Rather it will submit the cookie to any paths that match the pattern

specified. For example, if the application specifies a path scope of 

/apps

, then

the browser will submit its cookies to the paths 

/apps-test/

and 

/apps-

old/

and all of their subdirectories, in addition to the path 

/apps/

. This

behavior is probably not what the developer intended.

It is surprisingly common to encounter applications that explicitly liberalize

the path scope of their cookies to the web server root (

/

). In this situation, the

application’s cookies will be submitted to every application accessible via the

same domain name. For example:

/apps/secure/bar-app/

/apps/test/

/blogs/users/solero/

Liberalizing a cookie’s path scope can leave an application vulnerable in the

same way as when an application sets the domain scope of a cookie to its par-

ent domain. If a security-critical application sets a cookie with its path scope

set to the web server root, and a less secure application resides at some other

path, then the cookies issued by the former application will be submitted to

the latter. This will enable an attacker to leverage any weakness in the less

secure application as a means of attacking sessions on the more secure target.