Cookie Security: Overly Broad Domain

A cookie with an overly broad domain opens an application to attack through other applications.

Developers often set cookies to be active across a base domain such as ".example.com". This exposes the cookie to all web applications on the base domain and any sub-domains. 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 secure application deployed at http://secure.example.com/, and the application sets a session ID cookie with the domain ".example.com" when a user logs in.

For example:

  HttpCookie cookie = new HttpCookie("sessionID", sessionID);
  cookie.Domain = ".example.com";

Suppose you have another, less secure, application at http://insecure.example.com/ and it contains a cross-site scripting vulnerability. Any user authenticated to http://secure.example.com that browses to http://insecure.example.com risks exposing their session cookie from http://secure.example.com.

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

A cookie with an overly broad domain opens an application to attack through other applications.

Developers often set cookies to be active across a base domain such as ".example.com". This exposes the cookie to all web applications on the base domain and any sub-domains. 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 secure application deployed at http://secure.example.com/ and the application sets a session ID cookie with the domain ".example.com" when a user logs in.

For example:

cookie := http.Cookie{
  Name:       "sessionID",
  Value:      getSessionID(),
  Domain:     ".example.com",
}
...

Suppose you have another, less secure, application at http://insecure.example.com/, and it contains a cross-site scripting vulnerability. Any user authenticated to http://secure.example.com that browses to http://insecure.example.com risks exposing their session cookie from http://secure.example.com.

In addition to reading a cookie, attackers can perform a "Cookie poisoning attack" by using insecure.example.com to create its own overly broad cookie that overwrites the cookie from Secure.example.com.

A cookie with an overly broad domain opens an application to attack through other applications.

Developers often set cookies to be active across a base domain such as ".example.com". This exposes the cookie to all web applications on the base domain and any sub-domains. 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 secure application deployed at http://secure.example.com/ and the application sets a session ID cookie with the domain ".example.com" when a user logs in.

For example:

  cookie_options = {};
  cookie_options.domain = '.example.com';
  ...
  res.cookie('important_cookie', info, cookie_options);

Suppose you have another, less secure, application at http://insecure.example.com/, and it contains a cross-site scripting vulnerability. Any user authenticated to http://secure.example.com that browses to http://insecure.example.com risks exposing their session cookie from http://secure.example.com.

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

A cookie with an overly broad domain opens an application to attack through other applications.

Developers often set cookies to be active across a base domain such as ".example.com". This exposes the cookie to all web applications on the base domain and any sub-domains. 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 secure application deployed at http://secure.example.com/ and the application sets a session ID cookie with the domain ".example.com" when a user logs in.

For example:

  ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  [cookieProperties setValue:@".example.com" forKey:NSHTTPCookieDomain];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

Suppose you have another, less secure, application at http://insecure.example.com/, and it contains a cross-site scripting vulnerability. Any user authenticated to http://secure.example.com that browses to http://insecure.example.com risks exposing their session cookie from http://secure.example.com.

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

A cookie with an overly broad domain opens an application to attack through other applications.

Developers often set cookies to be active across a base domain such as ".example.com". This exposes the cookie to all web applications on the base domain and any sub-domains. 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 secure application deployed at http://secure.example.com/ and the application sets a session ID cookie with the domain ".example.com" when a user logs in.

For example:

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

Suppose you have another, less secure, application at http://insecure.example.com/, and it contains a cross-site scripting vulnerability. Any user authenticated to http://secure.example.com that browses to http://insecure.example.com risks exposing their session cookie from http://secure.example.com.

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

A cookie with an overly broad domain opens an application to attack through other applications.

Developers often set cookies to be active across a base domain such as ".example.com". This exposes the cookie to all web applications on the base domain and any sub-domains. 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 secure application deployed at http://secure.example.com/ and the application sets a session ID cookie with the domain ".example.com" when a user logs in.

For example:

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("mySessionId", getSessionID(), domain=".example.com")
  return res
...

Suppose you have another, less secure, application at http://insecure.example.com/, and it contains a cross-site scripting vulnerability. Any user authenticated to http://secure.example.com that browses to http://insecure.example.com risks exposing their session cookie from http://secure.example.com.

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

A cookie with an overly broad domain opens an application to attack through other applications.

Developers often set cookies to be active across a base domain such as ".example.com". This exposes the cookie to all web applications on the base domain and any sub-domains. 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 secure application deployed at http://secure.example.com/ and the application sets a session ID cookie with the domain ".example.com" when a user logs in.

For example:

    Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, domain = Some(".example.com")))

Suppose you have another, less secure, application at http://insecure.example.com/, and it contains a cross-site scripting vulnerability. Any user authenticated to http://secure.example.com that browses to http://insecure.example.com risks exposing their session cookie from http://secure.example.com.

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

A cookie with an overly broad domain opens an application to attack through other applications.

Developers often set cookies to be active across a base domain such as ".example.com". This exposes the cookie to all web applications on the base domain and any sub-domains. 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 secure application deployed at http://secure.example.com/ and the application sets a session ID cookie with the domain ".example.com" when a user logs in.

For example:

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

Suppose you have another, less secure, application at http://insecure.example.com/, and it contains a cross-site scripting vulnerability. Any user authenticated to http://secure.example.com that browses to http://insecure.example.com risks exposing their session cookie from http://secure.example.com.

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