Cookie Security: Overly Broad Domain

Una cookie con un dominio demasiado grande expone una aplicación a los ataques a través de otras aplicaciones.

A menudo, los desarrolladores configuran las cookies para que se activen en un dominio básico como ".example.com". Esto expone la cookie a todas las aplicaciones web del dominio básico y los subdominios. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.

Ejemplo 1:
Suponga que tiene una aplicación segura implementada en http://secure.example.com/ y que la aplicación define una cookie de ID de sesión con un dominio ".example.com" cuando los usuarios inician sesión.

Por ejemplo:

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

Supongamos que tiene otra aplicación menos segura en http://insecure.example.com/ que contiene una vulnerabilidad Cross-Site Scripting. Cualquier usuario autenticado en http://secure.example.com que acceda a http://insecure.example.com corre el riesgo de exponer su cookie de sesión de http://secure.example.com.

Además de leer una cookie, los atacantes podrían realizar un ataque de Cookie Poisoning utilizando insecure.example.com para crear su propia cookie demasiado grande que sustituya a la cookie de secure.example.com.

Una cookie con un dominio demasiado grande expone una aplicación a los ataques a través de otras aplicaciones.

A menudo, los desarrolladores configuran las cookies para que se activen en un dominio básico como ".example.com". Esto expone la cookie a todas las aplicaciones web del dominio básico y los subdominios. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.

Ejemplo 1: Imagine que tiene una aplicación segura implementada en http://secure.example.com/ y que la aplicación define una cookie de ID de sesión con un dominio ".example.com" cuando los usuarios inician sesión.

Por ejemplo:

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

Supongamos que tiene otra aplicación menos segura en http://insecure.example.com/ que contiene una vulnerabilidad Cross-Site Scripting. Cualquier usuario autenticado en http://secure.example.com que acceda a http://insecure.example.com corre el riesgo de exponer su cookie de sesión de http://secure.example.com.

Además de leer una cookie, los atacantes pueden realizar un "ataque de envenenamiento de cookies" mediante el uso de insecure.example.com para crear su propia cookie demasiado grande que sustituya a la cookie de Secure.example.com.

Una cookie con un dominio demasiado grande expone una aplicación a los ataques a través de otras aplicaciones.

A menudo, los desarrolladores configuran las cookies para que se activen en un dominio básico como ".example.com". Esto expone la cookie a todas las aplicaciones web del dominio básico y los subdominios. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.

Ejemplo 1:
Imagine que tiene una aplicación segura implementada en http://secure.example.com/ y que la aplicación define una cookie de ID de sesión con un dominio ".example.com" cuando los usuarios inician sesión.

Por ejemplo:

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

Supongamos que tiene otra aplicación menos segura en http://insecure.example.com/ y que contiene una vulnerabilidad de Cross-Site Scripting. Cualquier usuario autenticado en http://secure.example.com que acceda a http://insecure.example.com crea un riesgo al exponer su cookie de sesión de http://secure.example.com.

Además de leer una cookie, los atacantes podrían realizar un ataque de envenenamiento de cookies utilizando insecure.example.com para crear su propia cookie demasiado grande que sustituya a la cookie de secure.example.com.

Una cookie con un dominio demasiado grande expone una aplicación a los ataques a través de otras aplicaciones.

A menudo, los desarrolladores configuran las cookies para que se activen en un dominio básico como ".example.com". Esto expone la cookie a todas las aplicaciones web del dominio básico y los subdominios. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.

Ejemplo 1:
Imagine que tiene una aplicación segura implementada en http://secure.example.com/ y que la aplicación define una cookie de ID de sesión con un dominio ".example.com" cuando los usuarios inician sesión.

Por ejemplo:

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

Supongamos que tiene otra aplicación menos segura en http://insecure.example.com/ y que contiene una vulnerabilidad de Cross-Site Scripting. Cualquier usuario autenticado en http://secure.example.com que acceda a http://insecure.example.com crea un riesgo al exponer su cookie de sesión de http://secure.example.com.

Además de leer una cookie, los atacantes podrían realizar un ataque de envenenamiento de cookies utilizando insecure.example.com para crear su propia cookie demasiado grande que sustituya a la cookie de secure.example.com.

Una cookie con un dominio demasiado grande expone una aplicación a los ataques a través de otras aplicaciones.

A menudo, los desarrolladores configuran las cookies para que se activen en un dominio básico como ".example.com". Esto expone la cookie a todas las aplicaciones web del dominio básico y los subdominios. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.

Ejemplo 1:
Imagine que tiene una aplicación segura implementada en http://secure.example.com/ y que la aplicación define una cookie de ID de sesión con un dominio ".example.com" cuando los usuarios inician sesión.

Por ejemplo:

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

Supongamos que tiene otra aplicación menos segura en http://insecure.example.com/ y que contiene una vulnerabilidad de Cross-Site Scripting. Cualquier usuario autenticado en http://secure.example.com que acceda a http://insecure.example.com crea un riesgo al exponer su cookie de sesión de http://secure.example.com.

Además de leer una cookie, los atacantes podrían realizar un ataque de envenenamiento de cookies utilizando insecure.example.com para crear su propia cookie demasiado grande que sustituya a la cookie de secure.example.com.

Una cookie con un dominio demasiado grande expone una aplicación a los ataques a través de otras aplicaciones.

A menudo, los desarrolladores configuran las cookies para que se activen en un dominio básico como ".example.com". Esto expone la cookie a todas las aplicaciones web del dominio básico y los subdominios. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.

Ejemplo 1: Imagine que tiene una aplicación segura implementada en http://secure.example.com/ y que la aplicación define una cookie de ID de sesión con un dominio ".example.com" cuando los usuarios inician sesión.

Por ejemplo:

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

Supongamos que tiene otra aplicación menos segura en http://insecure.example.com/ y que contiene una vulnerabilidad de Cross-Site Scripting. Cualquier usuario autenticado en http://secure.example.com que acceda a http://insecure.example.com crea un riesgo al exponer su cookie de sesión de http://secure.example.com.

Además de leer una cookie, los usuarios malintencionados podrían realizar un "ataque de envenenamiento de cookies" utilizando insecure.example.com para crear su propia cookie demasiado grande que sustituya a la cookie de secure.example.com.

Una cookie con un dominio demasiado grande expone una aplicación a los ataques a través de otras aplicaciones.

A menudo, los desarrolladores configuran las cookies para que se activen en un dominio básico como ".example.com". Esto expone la cookie a todas las aplicaciones web del dominio básico y los subdominios. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.

Ejemplo 1: Imagine que tiene una aplicación segura implementada en http://secure.example.com/ y que la aplicación define una cookie de ID de sesión con un dominio ".example.com" cuando los usuarios inician sesión.

Por ejemplo:

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

Supongamos que tiene otra aplicación menos segura en http://insecure.example.com/ que contiene una vulnerabilidad Cross-Site Scripting. Cualquier usuario autenticado en http://secure.example.com que acceda a http://insecure.example.com corre el riesgo de exponer su cookie de sesión de http://secure.example.com.

Además de leer una cookie, los atacantes podrían realizar un ataque de Cookie Poisoning utilizando insecure.example.com para crear su propia cookie demasiado grande que sustituya a la cookie de secure.example.com.

Una cookie con un dominio demasiado grande expone una aplicación a los ataques a través de otras aplicaciones.

A menudo, los desarrolladores configuran las cookies para que se activen en un dominio básico como ".example.com". Esto expone la cookie a todas las aplicaciones web del dominio básico y los subdominios. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.

Ejemplo 1:
Imagine que tiene una aplicación segura implementada en http://secure.example.com/ y que la aplicación define una cookie de ID de sesión con un dominio ".example.com" cuando los usuarios inician sesión.

Por ejemplo:

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

Supongamos que tiene otra aplicación menos segura en http://insecure.example.com/ y que contiene una vulnerabilidad de Cross-Site Scripting. Cualquier usuario autenticado en http://secure.example.com que acceda a http://insecure.example.com crea un riesgo al exponer su cookie de sesión de http://secure.example.com.

Además de leer una cookie, los atacantes podrían realizar un ataque de envenenamiento de cookies utilizando insecure.example.com para crear su propia cookie demasiado grande que sustituya a la cookie de secure.example.com.