A cookie with an overly broad path can be accessed through other applications on the same domain.
Developers often set cookies to be the root context path "/
", however, doing so exposes the cookie to all web applications on the same domain name. Since cookies often carry sensitive information such as session identifiers, sharing cookies across applications can lead a vulnerability in one application to cause a compromise in another.
Example:
Imagine you have a forum application deployed at http://communitypages.example.com/MyForum
and the application sets a session ID cookie with path "/
" when users log in to the forum.
For example:
HttpCookie cookie = new HttpCookie("sessionID", sessionID);
cookie.Path = "/";
http://communitypages.example.com/EvilSite
and posts a link to this site on the forum. When a user of the forum clicks on the link, his browser will send the cookie set by /MyForum
to the application running at /EvilSite
. By stealing the session ID, the attacker is able to compromise the account of any forum user that browsed to /EvilSite
./EvilSite
to create its own overly broad cookie that overwrites the cookie from /MyForum
.[1] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A10 Insecure Configuration Management
[2] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A6 Information Leakage and Improper Error Handling
[3] Standards Mapping - OWASP Top 10 2010 - (OWASP 2010) A6 Security Misconfiguration
[4] Standards Mapping - FIPS200 - (FISMA) CM
[5] Standards Mapping - Web Application Security Consortium 24 + 2 - (WASC 24 + 2) Information Leakage
[6] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.10
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.5.7
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.8