Cookie Security: Overly Broad Path

A cookie with an overly broad path can be accessed by other applications on the same domain.

Developers often set cookies to be accessible from the root context path ("/"). This exposes the cookie to all web applications on the domain. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1:
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:

...
String path = '/';
Cookie cookie = new Cookie('sessionID', sessionID, path, maxAge, true, 'Strict');
...

Suppose an attacker creates another application at http://communitypages.example.com/EvilSite and posts a link to this site on the forum. When a user of the forum clicks this link, the browser will send the cookie set by /MyForum to the application running at /EvilSite. By stealing the session ID, the attacker can compromise the account of any forum user that browsed to /EvilSite.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using /EvilSite to create its own overly broad cookie that overwrites the cookie from /MyForum.

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. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

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 = "/";

Suppose an attacker creates another application at http://communitypages.example.com/EvilSite and posts a link to this site on the forum. When a user of the forum clicks this link, the browser will send the cookie set by /MyForum to the application running at /EvilSite. By stealing the session ID, the attacker can compromise the account of any forum user that browsed to /EvilSite.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using /EvilSite to create its own overly broad cookie that overwrites the cookie from /MyForum.

A cookie with an overly broad path can be accessed through other applications on the same domain.

Developers often set cookies to be accessible from the root context path ("/"). This exposes the cookie to all web applications on the domain. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1:
Suppose 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:

cookie := http.Cookie{
  Name:    "sessionID",
  Value:   sID,
  Expires: time.Now().AddDate(0, 0, 1),
  Path:    "/",
}
...

Suppose an attacker creates another application at http://communitypages.example.com/EvilSite and posts a link to this site on the forum. When a forum user clicks this link, the browser sends the cookie set by /MyForum to the application running at /EvilSite. By stealing the session ID, the attacker can compromise the account of any forum user that browsed to /EvilSite.

In addition to reading a cookie, attackers can perform a "Cookie poisoning attack" by using /EvilSite to create its own overly broad cookie that overwrites the cookie from /MyForum.

A cookie with an overly broad path can be accessed through other applications on the same domain.

Developers often set cookies to be accessible from the root context path ("/"). This exposes the cookie to all web applications on the domain. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1:
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:

  cookie_options = {};
  cookie_options.path = '/';
  ...
  res.cookie('important_cookie', info, cookie_options);

Suppose an attacker creates another application at http://communitypages.example.com/EvilSite and posts a link to this site on the forum. When a user of the forum clicks this link, the browser will send the cookie set by /MyForum to the application running at /EvilSite. By stealing the session ID, the attacker can compromise the account of any forum user that browsed to /EvilSite.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using /EvilSite to create its own overly broad cookie that overwrites the cookie from /MyForum.

A cookie with an overly broad path can be accessed through other applications on the same domain.

Developers often set cookies to be accessible from the root context path ("/"). This exposes the cookie to all web applications on the domain. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1:
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:

  ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  [cookieProperties setValue:@"/" forKey:NSHTTPCookiePath];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

Suppose an attacker creates another application at http://communitypages.example.com/EvilSite and posts a link to this site on the forum. When a user of the forum clicks this link, the browser will send the cookie set by /MyForum to the application running at /EvilSite. By stealing the session ID, the attacker can compromise the account of any forum user that browsed to /EvilSite.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using /EvilSite to create its own overly broad cookie that overwrites the cookie from /MyForum.

A cookie with an overly broad path can be accessed through other applications on the same domain.

Developers often set cookies to be accessible from the root context path ("/"). This exposes the cookie to all web applications on the domain. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1:
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:

  setcookie("mySessionId", getSessionID(), 0, "/", "communitypages.example.com", true, true);

Suppose an attacker creates another application at http://communitypages.example.com/EvilSite and posts a link to this site on the forum. When a user of the forum clicks this link, the browser will send the cookie set by /MyForum to the application running at /EvilSite. By stealing the session ID, the attacker can compromise the account of any forum user that browsed to /EvilSite.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using /EvilSite to create its own overly broad cookie that overwrites the cookie from /MyForum.

A cookie with an overly broad path can be accessed through other applications on the same domain.

Developers often set cookies to be accessible from the root context path ("/"). This exposes the cookie to all web applications on the domain. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1:
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:

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("sessionid", value)   # Path defaults to "/"
  return res
...

Suppose an attacker creates another application at http://communitypages.example.com/EvilSite and posts a link to this site on the forum. When a user of the forum clicks this link, the browser will send the cookie set by /MyForum to the application running at /EvilSite. By stealing the session ID, the attacker can compromise the account of any forum user that browsed to /EvilSite.

In addition to reading a cookie, it might be possible for attackers to perform a "Cookie poisoning attack" by using /EvilSite to create its own overly broad cookie that overwrites the cookie from /MyForum.

A cookie with an overly broad path can be accessed through other applications on the same domain.

Developers often set cookies to be accessible from the root context path ("/"). This exposes the cookie to all web applications on the domain. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1: 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:

    Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, path = "/"))

Suppose an attacker creates another application at http://communitypages.example.com/EvilSite and posts a link to this site on the forum. When a user of the forum clicks this link, the browser will send the cookie set by /MyForum to the application running at /EvilSite. By stealing the session ID, the attacker can compromise the account of any forum user that browsed to /EvilSite.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using /EvilSite to create its own overly broad cookie that overwrites the cookie from /MyForum.

A cookie with an overly broad path can be accessed through other applications on the same domain.

Developers often set cookies to be accessible from the root context path ("/"). This exposes the cookie to all web applications on the domain. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1:
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:

...
let properties = [
    NSHTTPCookieDomain: "www.example.com",
    NSHTTPCookiePath: "/",
    NSHTTPCookieName: "foo",
    NSHTTPCookieValue: "bar",
    NSHTTPCookieSecure: true
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...

Suppose an attacker creates another application at http://communitypages.example.com/EvilSite and posts a link to this site on the forum. When a user of the forum clicks this link, the browser will send the cookie set by /MyForum to the application running at /EvilSite. By stealing the session ID, the attacker can compromise the account of any forum user that browsed to /EvilSite.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using /EvilSite to create its own overly broad cookie that overwrites the cookie from /MyForum.