Los exploradores web modernos admiten una marca Secure para cada cookie. Si se define una marca, el explorador solo puede enviar la cookie a través de HTTPS. Enviar cookies a través de un canal no cifrado puede exponerlas a ataques de espionaje de red. Las marcas seguras ayudan a mantener la confidencialidad del valor de una cookie. Esto es especialmente importante cuando la cookie contiene datos privados o porta un identificador de sesión.

Ejemplo 1: En el ejemplo siguiente, se ha creado una cookie sin configurar el parámetro isSecure como true.

...
Cookie cookie = new Cookie('emailCookie', emailCookie, path, maxAge, false, 'Strict');
...

Si su aplicación utiliza tanto HTTPS como HTTP, pero no define el parámetro isSecure, las cookies enviadas durante una solicitud HTTPS también se envían en las solicitudes HTTP subsiguientes. El espionaje del tráfico de red a través de conexiones inalámbricas no cifradas es una tarea fácil para los atacantes. Enviar cookies (sobre todo las que incluyen ID de sesión) a través de HTTP puede poner en peligro la aplicación.

Los exploradores web modernos admiten una marca Secure en cada cookie. Si se incluye una marca, el explorador solo puede enviar la cookie a través de HTTPS. Enviar cookies a través de un canal no cifrado puede exponerlas a ataques de reconocimiento de red, por lo que las marcas seguras ayudan a mantener la confidencialidad del valor de una cookie. Esto es especialmente importante cuando la cookie contiene datos privados o porta un identificador de sesión.

Ejemplo: en el ejemplo siguiente, se ha añadido una cookie a la respuesta sin configurar la propiedad Secure.

...
 HttpCookie cookie = new HttpCookie("emailCookie", email);
    Response.AppendCookie(cookie);
...

Si su aplicación utiliza tanto HTTPS como HTTP pero no define la marca Secure, las cookies enviadas durante una solicitud HTTPS también se enviarán en subsiguientes solicitudes HTTP. Espiar tráfico de red a través de conexiones inalámbricas no cifradas es una tarea fácil para los atacantes, por lo que enviar cookies (sobre todo con ID de sesión) a través de HTTP puede poner en peligro la aplicación.

Los exploradores web modernos admiten una marca Secure para cada cookie. Si se define una marca, el explorador solo puede enviar la cookie a través de HTTPS. Enviar cookies a través de un canal no cifrado puede exponerlas a ataques de espionaje de red, por lo que las marcas seguras ayudan a mantener la confidencialidad del valor de una cookie. Esto es especialmente importante cuando la cookie contiene datos privados o identificadores de sesión, o cuando porta un token de CSRF.
Ejemplo 1: En código siguiente agrega una cookie a la respuesta sin establecer la marca Secure.

cookie := http.Cookie{
  Name:     "emailCookie",
  Value:    email,
}
http.SetCookie(response, &cookie)
...

Si una aplicación utiliza tanto HTTPS como HTTP, pero no define la marca Secure, las cookies enviadas durante una solicitud HTTPS también se enviarán en las subsiguientes solicitudes HTTP. Los atacantes pueden secuestrar el tráfico de red no cifrado y poner en peligro la cookie, lo cual es especialmente fácil en el caso de las redes inalámbricas.

Los exploradores web modernos admiten una marca Secure en cada cookie. Si se incluye una marca, el explorador solo puede enviar la cookie a través de HTTPS. Enviar cookies a través de un canal no cifrado puede exponerlas a ataques de reconocimiento de red, por lo que las marcas seguras ayudan a mantener la confidencialidad del valor de una cookie. Esto es especialmente importante cuando la cookie contiene datos privados o porta un identificador de sesión.
Ejemplo 1: en el ejemplo siguiente, se ha añadido una cookie a la respuesta sin configurar la propiedad Secure como true.

  res.cookie('important_cookie', info, {domain: 'secure.example.com', path: '/admin', httpOnly: true, secure: false});

Si su aplicación utiliza tanto HTTPS como HTTP pero no define la marca Secure, las cookies enviadas durante una solicitud HTTPS también se enviarán en subsiguientes solicitudes HTTP. Espiar tráfico de red a través de conexiones inalámbricas no cifradas es una tarea fácil para los atacantes, por lo que enviar cookies (sobre todo con ID de sesión) a través de HTTP puede poner en peligro la aplicación.

Los exploradores web modernos admiten una marca Secure en cada cookie. Si se incluye una marca, el explorador solo puede enviar la cookie a través de HTTPS. Enviar cookies a través de un canal no cifrado puede exponerlas a ataques de reconocimiento de red, por lo que las marcas seguras ayudan a mantener la confidencialidad del valor de una cookie. Esto es especialmente importante cuando la cookie contiene datos privados o porta un identificador de sesión.
Ejemplo 1: En el ejemplo siguiente, se ha agregado una cookie a la respuesta sin establecer la marca Secure.

  ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

Si su aplicación utiliza tanto HTTPS como HTTP pero no define la marca Secure, las cookies enviadas durante una solicitud HTTPS también se enviarán en subsiguientes solicitudes HTTP. Espiar tráfico de red a través de conexiones inalámbricas no cifradas es una tarea fácil para los atacantes, por lo que enviar cookies (sobre todo con ID de sesión) a través de HTTP puede poner en peligro la aplicación.

Los exploradores web modernos admiten una marca Secure en cada cookie. Si se incluye una marca, el explorador solo puede enviar la cookie a través de HTTPS. Enviar cookies a través de un canal no cifrado puede exponerlas a ataques de reconocimiento de red, por lo que las marcas seguras ayudan a mantener la confidencialidad del valor de una cookie. Esto es especialmente importante cuando la cookie contiene datos privados o porta un identificador de sesión.
Ejemplo 1: En código siguiente agrega una cookie a la respuesta sin establecer la marca Secure.

...
setcookie("emailCookie", $email, 0, "/", "www.example.com");
...

Si una aplicación utiliza tanto HTTPS como HTTP pero no define la marca Secure, las cookies enviadas durante una solicitud HTTPS también se enviarán en subsiguientes solicitudes HTTP. Los atacantes pueden poner en peligro la cookie secuestrando el tráfico de red no cifrado, lo cual es especialmente fácil en el caso de las redes inalámbricas.

Los exploradores web modernos admiten una marca Secure en cada cookie. Si se incluye una marca, el explorador solo puede enviar la cookie a través de HTTPS. Enviar cookies a través de un canal no cifrado puede exponerlas a ataques de reconocimiento de red, por lo que las marcas seguras ayudan a mantener la confidencialidad del valor de una cookie. Esto es especialmente importante cuando la cookie contiene datos privados o identificadores de sesión, o cuando porta un token de CSRF.
Ejemplo 1: En código siguiente agrega una cookie a la respuesta sin establecer la marca Secure.

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("emailCookie", email)
  return res
...

Si una aplicación utiliza tanto HTTPS como HTTP pero no define la marca Secure, las cookies enviadas durante una solicitud HTTPS también se enviarán en subsiguientes solicitudes HTTP. Los atacantes pueden poner en peligro la cookie secuestrando el tráfico de red no cifrado, lo cual es especialmente fácil en el caso de las redes inalámbricas.

Los exploradores web modernos admiten una marca Secure para cada cookie. Si se define una marca, el explorador solo puede enviar la cookie a través de HTTPS. Enviar cookies a través de un canal no cifrado puede exponerlas a ataques de espionaje de red, por lo que las marcas seguras ayudan a mantener la confidencialidad del valor de una cookie. Esto es especialmente importante cuando la cookie contiene datos privados o porta un identificador de sesión.
Ejemplo 1: En el ejemplo siguiente, se ha agregado una cookie a la respuesta sin establecer la marca Secure.

    Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, secure = false))

Si su aplicación utiliza tanto HTTPS como HTTP, pero no define la marca Secure, las cookies enviadas durante una solicitud HTTPS también se enviarán en las solicitudes HTTP subsiguientes. El espionaje del tráfico de red a través de conexiones inalámbricas no cifradas es una tarea fácil para los atacantes, por lo que enviar cookies (sobre todo las que incluyen ID de sesión) a través de HTTP puede poner en peligro la aplicación.

Los exploradores web modernos admiten una marca Secure para cada cookie. Si se define una marca, el explorador solo puede enviar la cookie a través de HTTPS. Enviar cookies a través de un canal no cifrado puede exponerlas a ataques de espionaje de red, por lo que las marcas seguras ayudan a mantener la confidencialidad del valor de una cookie. Esto es especialmente importante cuando la cookie contiene datos privados o porta un identificador de sesión.
Ejemplo 1: En el ejemplo siguiente, se ha agregado una cookie a la respuesta sin establecer la marca Secure.

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

Si su aplicación utiliza tanto HTTPS como HTTP, pero no define la marca Secure, las cookies enviadas durante una solicitud HTTPS también se enviarán en las solicitudes HTTP subsiguientes. El espionaje del tráfico de red a través de conexiones inalámbricas no cifradas es una tarea fácil para los atacantes, por lo que enviar cookies (sobre todo las que incluyen ID de sesión) a través de HTTP puede poner en peligro la aplicación.

Todos los exploradores más comunes admiten la propiedad de cookie HttpOnly que evita que scripts del lado del cliente puedan acceder a la cookie. Los ataques de Cross-Site Scripting suelen acceder a las cookies con el fin de robar los identificadores de sesión o los tokens de autenticación. Cuando HttpOnly no está habilitado, los atacantes pueden acceder más fácilmente a las cookies del usuario.
Ejemplo 1: el siguiente código crea una cookie sin configurar la propiedad HttpOnly.

    HttpCookie cookie = new HttpCookie("emailCookie", email);
    Response.AppendCookie(cookie);

Los exploradores admiten la propiedad de cookie HttpOnly que evita que los scripts del lado del cliente accedan a la cookie. Los ataques Cross-Site Scripting suelen acceder a las cookies con el fin de robar los identificadores de sesión o los tokens de autenticación. Cuando HttpOnly no está habilitado, los usuarios malintencionados pueden acceder más fácilmente a las cookies del usuario.
Ejemplo 1: el siguiente código crea una cookie sin configurar la propiedad HttpOnly.

cookie := http.Cookie{
  Name:     "emailCookie",
  Value:    email,
}
...

Todos los exploradores más comunes admiten la propiedad de cookie HttpOnly que evita que scripts del lado del cliente puedan acceder a la cookie. Los ataques de Cross-Site Scripting suelen acceder a las cookies con el fin de robar los identificadores de sesión o los tokens de autenticación. Cuando HttpOnly no está habilitado, los atacantes pueden acceder más fácilmente a las cookies del usuario.
Ejemplo 1: el siguiente código crea una cookie sin configurar la propiedad httpOnly.

  res.cookie('important_cookie', info, {domain: 'secure.example.com', path: '/admin'});

Todos los exploradores más comunes admiten la propiedad de cookie HttpOnly que evita que scripts del lado del cliente puedan acceder a la cookie. Los ataques de Cross-Site Scripting suelen acceder a las cookies con el fin de robar los identificadores de sesión o los tokens de autenticación. Cuando HttpOnly no está habilitado, los atacantes pueden acceder más fácilmente a las cookies del usuario.
Ejemplo 1: el siguiente código crea una cookie sin configurar la propiedad HttpOnly.

setcookie("emailCookie", $email, 0, "/", "www.example.com", TRUE);  //Missing 7th parameter to set HttpOnly

Los exploradores admiten la propiedad de cookie HttpOnly que evita que scripts del lado del cliente puedan acceder a la cookie. Los ataques de Cross-Site Scripting suelen acceder a las cookies con el fin de robar los identificadores de sesión o los tokens de autenticación. Cuando HttpOnly no está habilitado, los atacantes pueden acceder más fácilmente a las cookies del usuario.
Ejemplo 1: el siguiente código crea una cookie sin configurar la propiedad HttpOnly.

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("emailCookie", email)
  return res
...

Todos los exploradores más comunes admiten la propiedad de cookie HttpOnly que evita que scripts del lado del cliente puedan acceder a la cookie. Los ataques de Cross-Site Scripting suelen acceder a las cookies con el fin de robar los identificadores de sesión o los tokens de autenticación. Cuando HttpOnly no está habilitado, los atacantes pueden acceder más fácilmente a las cookies del usuario.
Ejemplo 1: el siguiente código crea una cookie sin configurar la propiedad HttpOnly.

    Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, httpOnly = false))

Todos los exploradores más comunes admiten la propiedad de cookie HttpOnly que evita que scripts del lado del cliente puedan acceder a la cookie. Los ataques de Cross-Site Scripting suelen acceder a las cookies con el fin de robar los identificadores de sesión o los tokens de autenticación. Cuando HttpOnly no está habilitado, los atacantes pueden acceder más fácilmente a las cookies del usuario.
Ejemplo 1: El siguiente código crea una sesión de cookie sin establecer el parámetro HttpOnly como true

session_set_cookie_params(0, "/", "www.example.com", true, false);

Los exploradores admiten la propiedad de cookie HttpOnly que evita que scripts del lado del cliente puedan acceder a la cookie. Los ataques de Cross-Site Scripting suelen acceder a las cookies con el fin de robar los identificadores de sesión o los tokens de autenticación. Cuando HttpOnly no está habilitado, los atacantes pueden acceder más fácilmente a las cookies del usuario.

Ejemplo 1: Los parámetros de configuración siguientes establecen explícitamente las cookies de sesión sin establecer la propiedad HttpOnly.

...
MIDDLEWARE = (
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'csp.middleware.CSPMiddleware',
    'django.middleware.security.SecurityMiddleware',
    ...
)
...
SESSION_COOKIE_HTTPONLY = False
...

Los navegadores añaden cookies automáticamente a cada solicitud HTTP realizada al sitio que establece la cookie. Las cookies pueden almacenar datos confidenciales como el identificador de sesión y el token de autorización, o datos del sitio que se comparten entre diferentes solicitudes al mismo sitio durante una sesión. Un atacante puede realizar un ataque de suplantación de identidad generando una solicitud al sitio autenticado desde una página de un sitio de terceros cargada en el equipo cliente porque el navegador adjuntó automáticamente la cookie a la solicitud.

El atributo SameSite limita el alcance de la cookie de modo que solo se adjuntará a una solicitud si la solicitud se genera a partir de un contexto propio o del mismo sitio. Esto ayuda a proteger las cookies contra ataques de Cross-site Request Forgery (CSRF, por sus siglas en inglés). El atributo SameSite puede tener los siguientes tres valores:

- Strict: Cuando se establece en Strict, las cookies solo se envían junto con las solicitudes en la navegación de nivel superior.
- Lax: Cuando se establece en Lax, las cookies se envían con la navegación de nivel superior desde el mismo host, así como las solicitudes GET que se originan en sitios de terceros, incluidos aquellos que tienen etiquetas iframe o href que se vinculan al sitio del host. Si un usuario sigue el enlace, la solicitud incluirá la cookie.
- None: Las cookies se envían en todas las solicitudes realizadas al sitio dentro de la ruta y el alcance del dominio establecidos para la cookie. Las solicitudes generadas debido al envío de formularios mediante el método POST también pueden enviar cookies con la solicitud.

Ejemplo 1: El siguiente código deshabilita el atributo SameSite en las cookies de sesión.

    ...
    CookieOptions opt = new CookieOptions()
    {
        SameSite = SameSiteMode.None;
    };
    context.Response.Cookies.Append("name", "Foo", opt);
    ...

Los navegadores añaden cookies automáticamente a cada solicitud HTTP realizada al sitio que establece la cookie. Las cookies pueden almacenar datos confidenciales como el identificador de sesión y el token de autorización, o datos del sitio que se comparten entre diferentes solicitudes al mismo sitio durante una sesión. Un atacante puede realizar un ataque de suplantación de identidad generando una solicitud al sitio autenticado desde una página de un sitio de terceros cargada en la máquina cliente porque el navegador adjuntó automáticamente la cookie a la solicitud.

El atributo SameSite limita el alcance de la cookie de modo que solo se adjunta a una solicitud si la solicitud se genera a partir de un contexto propio o del mismo sitio. Esto ayuda a proteger las cookies contra ataques de falsificación de petición en Cross-Site Request Forgery (CSRF). El atributo SameSite puede tener los siguientes tres valores:

- Strict: Cuando se establece en Strict, las cookies solo se envían junto con las solicitudes en la navegación de nivel superior.
- Lax: Cuando se configura en Lax, las cookies se envían con navegación de nivel superior desde el mismo host, así como las solicitudes GET originadas en el host desde sitios de terceros. Por ejemplo, suponga un sitio de terceros tiene etiquetas iframe o href para el sitio host. Si un usuario sigue el enlace, la solicitud incluirá la cookie.
- None: Las cookies se envían en todas las solicitudes realizadas al sitio dentro de la ruta y el alcance del dominio establecidos para la cookie. Las solicitudes generadas debido al envío de formularios mediante el método POST también pueden enviar cookies con la solicitud.

Ejemplo 1: El siguiente código deshabilita el atributo SameSite en las cookies de sesión.

c := &http.Cookie{
  Name: "cookie",
  Value: "samesite-none",
  SameSite: http.SameSiteNoneMode,
}

Los navegadores añaden cookies automáticamente a cada solicitud HTTP realizada al sitio que establece la cookie. Las cookies pueden almacenar datos confidenciales como el identificador de sesión y el token de autorización, o datos del sitio que se comparten entre diferentes solicitudes al mismo sitio durante una sesión. Un atacante puede realizar un ataque de suplantación de identidad generando una solicitud al sitio autenticado desde una página de un sitio de terceros cargada en el equipo cliente porque el navegador adjuntó automáticamente la cookie a la solicitud.

El atributo SameSite limita el alcance de la cookie de modo que solo se adjunta a una solicitud si la solicitud se genera a partir de un contexto propio o del mismo sitio. Esto ayuda a proteger las cookies contra ataques de Cross-site Request Forgery (CSRF, por sus siglas en inglés). El atributo SameSite puede tener los siguientes tres valores:

- Strict: Cuando se establece en Strict, las cookies solo se envían junto con las solicitudes en la navegación de nivel superior.
- Lax: Cuando se establece en Lax, las cookies se envían con la navegación de nivel superior desde el mismo host, así como las solicitudes GET que se originan en sitios de terceros, incluidos aquellos que tienen etiquetas iframe o href que se vinculan al sitio del host. Por ejemplo, suponga que un sitio de terceros tiene etiquetas iframe o href para vincularse con el sitio host. Si un usuario sigue el enlace, la solicitud incluirá la cookie.
- None: Las cookies se envían en todas las solicitudes realizadas al sitio dentro de la ruta y el alcance del dominio establecidos para la cookie. Las solicitudes generadas debido al envío de formularios mediante el método POST también pueden enviar cookies con la solicitud.

Ejemplo 1: El siguiente código deshabilita el atributo SameSite en las cookies de sesión.

app.get('/', function (req, res) {
    ...
    res.cookie('name', 'Foo', { sameSite: false });
    ...
}

Los navegadores añaden cookies automáticamente a cada solicitud HTTP realizada al sitio que establece la cookie. Las cookies pueden almacenar datos confidenciales como el identificador de sesión y el token de autorización, o datos del sitio que se comparten entre diferentes solicitudes al mismo sitio durante una sesión. Un atacante puede realizar un ataque de suplantación de identidad generando una solicitud al sitio autenticado desde una página de un sitio de terceros cargada en la máquina cliente porque el navegador adjuntó automáticamente la cookie a la solicitud.

El atributo SameSite limita el alcance de la cookie de modo que solo se adjuntará a una solicitud si la solicitud se genera a partir de un contexto propio o del mismo sitio. Esto ayuda a proteger las cookies contra ataques de falsificación de petición en sitios cruzados (CSRF, por sus siglas en inglés). El atributo SameSite puede tener los siguientes tres valores:

- Strict: Cuando se establece en Strict, las cookies solo se envían junto con las solicitudes en la navegación de nivel superior.
- Lax: Cuando se configura en Lax, las cookies se envían con navegación de nivel superior desde el mismo host, así como las solicitudes GET originadas en el host desde sitios de terceros. Por ejemplo, suponga un sitio de terceros tiene etiquetas iframe o href para el sitio host. Si un usuario sigue el enlace, la solicitud incluirá la cookie.
- None: Las cookies se envían en todas las solicitudes realizadas al sitio dentro de la ruta y el alcance del dominio establecidos para la cookie. Las solicitudes generadas debido al envío de formularios mediante el método POST también pueden enviar cookies con la solicitud.

Ejemplo 1: El siguiente código deshabilita el atributo SameSite en las cookies de sesión.

ini_set("session.cookie_samesite", "None");

Los navegadores añaden cookies automáticamente a cada solicitud HTTP realizada al sitio que establece la cookie. Las cookies pueden almacenar datos confidenciales como el identificador de sesión y el token de autorización, o datos del sitio que se comparten entre diferentes solicitudes al mismo sitio durante una sesión. Un atacante puede realizar un ataque de suplantación de identidad generando una solicitud al sitio autenticado desde una página de un sitio de terceros cargada en la máquina cliente porque el navegador adjuntó automáticamente la cookie a la solicitud.

El parámetro samesite limita el alcance de la cookie de modo que solo se adjunta a una solicitud si la solicitud se genera a partir de un contexto propio o del mismo sitio. Esto ayuda a proteger las cookies contra ataques de Cross-site Request Forgery (CSRF, por sus siglas en inglés). El parámetro samesite puede tener los siguientes tres valores:

- Strict: Cuando se establece en Strict, las cookies solo se envían junto con las solicitudes en la navegación de nivel superior.
- Lax: Cuando se configura en Lax, las cookies se envían con navegación de nivel superior desde el mismo host, así como las solicitudes GET originadas en el host desde sitios de terceros. Por ejemplo, suponga un sitio de terceros tiene etiquetas iframe o href para el sitio host. Si un usuario sigue el enlace, la solicitud incluirá la cookie.
- None: Las cookies se envían en todas las solicitudes realizadas al sitio dentro de la ruta y el alcance del dominio establecidos para la cookie. Las solicitudes generadas debido al envío de formularios mediante el método POST también pueden enviar cookies con la solicitud.

Ejemplo 1: El siguiente código deshabilita el atributo SameSite en las cookies de sesión.

  response.set_cookie("cookie", value="samesite-none", samesite=None)

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:
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 un usuario inicia 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.

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.

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.

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.

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.

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.

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 un usuario inicia 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.

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.

A menudo, los desarrolladores configuran las cookies para que sean accesibles desde la ruta de acceso al contexto raíz ("/"). Al hacerlo, se expone la cookie a todas las aplicaciones web del dominio. 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 de foros implementada en http://communitypages.example.com/MyForum y que la aplicación define una cookie de ID de sesión con una ruta "/" cuando los usuarios inician sesión en un foro. Por ejemplo:

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

Imagine que un atacante crea otra aplicación en http://communitypages.example.com/EvilSite y publica un vínculo a este sitio en el foro. Cuando un usuario del foro hace clic en este vínculo, el explorador envía la cookie configurada mediante /MyForum a la aplicación que se ejecuta en /EvilSite. Al robar el identificador de sesión, el atacante puede comprometer la cuenta de cualquier usuario del foro que haya navegado a /EvilSite.

Además de leer una cookie, los usuarios malintencionados podrían realizar un ataque de Cookie Poisoning utilizando /EvilSite para crear su propia cookie demasiado grande que sustituya a la cookie de /MyForum.

A menudo, los desarrolladores configuran las cookies para que sean accesibles desde la ruta de acceso al contexto raíz "/"; no obstante, de esta forma se expone la cookie a todas las aplicaciones web del mismo nombre de dominio. 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:
Imagine que tiene una aplicación de foros implementada en http://communitypages.example.com/MyForum y que la aplicación define una cookie de ID de sesión con una ruta "/" cuando los usuarios inician sesión.

Por ejemplo:

  HttpCookie cookie = new HttpCookie("sessionID", sessionID);
  cookie.Path = "/";

Imagine que un atacante crea otra aplicación en http://communitypages.example.com/EvilSite y publica un vínculo a este sitio en el foro. Cuando un usuario del foro hace clic en este vínculo, el explorador envía la cookie configurada mediante /MyForum a la aplicación que se ejecuta en /EvilSite. Si se apodera del ID de sesión, el usuario malintencionado puede comprometer la cuenta de cualquier usuario del foro que haya navegado a /EvilSite.

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

A menudo, los desarrolladores configuran las cookies para que sean accesibles desde la ruta de acceso al contexto raíz ("/"). Al hacerlo, se expone la cookie a todas las aplicaciones web del dominio. 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:
Supongamos que tiene una aplicación de foros implementada en http://communitypages.example.com/MyForum y que la aplicación define una cookie de ID de sesión con una ruta "/" cuando los usuarios inician sesión.

Por ejemplo:

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

Imagine que un atacante crea otra aplicación en http://communitypages.example.com/EvilSite y publica un vínculo a este sitio en el foro. Cuando un usuario del foro hace clic en este vínculo, el explorador envía la cookie configurada mediante /MyForum a la aplicación que se ejecuta en /EvilSite. Al robar el identificador de sesión, el atacante puede comprometer la cuenta de cualquier usuario del foro que haya navegado a /EvilSite.

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

A menudo, los desarrolladores configuran las cookies para que sean accesibles desde la ruta de acceso al contexto raíz ("/"). Al hacerlo, se expone la cookie a todas las aplicaciones web del dominio. 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 de foros implementada en http://communitypages.example.com/MyForum y que la aplicación define una cookie de ID de sesión con una ruta "/" cuando los usuarios inician sesión.

Por ejemplo:

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

Imagine que un atacante crea otra aplicación en http://communitypages.example.com/EvilSite y publica un vínculo a este sitio en el foro. Cuando un usuario del foro hace clic en este vínculo, el explorador envía la cookie configurada mediante /MyForum a la aplicación que se ejecuta en /EvilSite. Si se apodera del ID de sesión, el usuario malintencionado puede comprometer la cuenta de cualquier usuario del foro que haya navegado a /EvilSite.

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

A menudo, los desarrolladores configuran las cookies para que sean accesibles desde la ruta de acceso al contexto raíz ("/"). Al hacerlo, se expone la cookie a todas las aplicaciones web del dominio. 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 de foros implementada en http://communitypages.example.com/MyForum y que la aplicación define una cookie de ID de sesión con una ruta "/" cuando los usuarios inician sesión.

Por ejemplo:

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

Imagine que un atacante crea otra aplicación en http://communitypages.example.com/EvilSite y publica un vínculo a este sitio en el foro. Cuando un usuario del foro hace clic en este vínculo, el explorador envía la cookie configurada mediante /MyForum a la aplicación que se ejecuta en /EvilSite. Si se apodera del ID de sesión, el usuario malintencionado puede comprometer la cuenta de cualquier usuario del foro que haya navegado a /EvilSite.

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

A menudo, los desarrolladores configuran las cookies para que sean accesibles desde la ruta de acceso al contexto raíz ("/"). Al hacerlo, se expone la cookie a todas las aplicaciones web del dominio. 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 de foros implementada en http://communitypages.example.com/MyForum y que la aplicación define una cookie de ID de sesión con una ruta "/" cuando los usuarios inician sesión.

Por ejemplo:

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

Imagine que un atacante crea otra aplicación en http://communitypages.example.com/EvilSite y publica un vínculo a este sitio en el foro. Cuando un usuario del foro hace clic en este vínculo, el explorador envía la cookie configurada mediante /MyForum a la aplicación que se ejecuta en /EvilSite. Si se apodera del ID de sesión, el usuario malintencionado puede comprometer la cuenta de cualquier usuario del foro que haya navegado a /EvilSite.

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

A menudo, los desarrolladores configuran las cookies para que sean accesibles desde la ruta de acceso al contexto raíz ("/"). Al hacerlo, se expone la cookie a todas las aplicaciones web del dominio. 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 de foros implementada en http://communitypages.example.com/MyForum y que la aplicación define una cookie de ID de sesión con una ruta "/" cuando los usuarios inician sesión.

Por ejemplo:

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

Imagine que un atacante crea otra aplicación en http://communitypages.example.com/EvilSite y publica un vínculo a este sitio en el foro. Cuando un usuario del foro hace clic en este vínculo, el explorador envía la cookie configurada mediante /MyForum a la aplicación que se ejecuta en /EvilSite. Si se apodera del ID de sesión, el usuario malintencionado puede comprometer la cuenta de cualquier usuario del foro que haya navegado a /EvilSite.

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

A menudo, los desarrolladores configuran las cookies para que sean accesibles desde la ruta de acceso al contexto raíz ("/"). Al hacerlo, se expone la cookie a todas las aplicaciones web del dominio. 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 de foros implementada en http://communitypages.example.com/MyForum y que la aplicación define una cookie de ID de sesión con una ruta "/" cuando los usuarios inician sesión en un foro.

Por ejemplo:

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

Imagine que un atacante crea otra aplicación en http://communitypages.example.com/EvilSite y publica un vínculo a este sitio en el foro. Cuando un usuario del foro hace clic en este vínculo, el explorador envía la cookie configurada mediante /MyForum a la aplicación que se ejecuta en /EvilSite. Si se apodera del ID de sesión, el usuario malintencionado puede comprometer la cuenta de cualquier usuario del foro que haya navegado a /EvilSite.

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

A menudo, los desarrolladores configuran las cookies para que sean accesibles desde la ruta de acceso al contexto raíz ("/"). Al hacerlo, se expone la cookie a todas las aplicaciones web del dominio. 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 de foros implementada en http://communitypages.example.com/MyForum y que la aplicación define una cookie de ID de sesión con una ruta "/" cuando los usuarios inician sesión.

Por ejemplo:

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

Imagine que un atacante crea otra aplicación en http://communitypages.example.com/EvilSite y publica un vínculo a este sitio en el foro. Cuando un usuario del foro hace clic en este vínculo, el explorador envía la cookie configurada mediante /MyForum a la aplicación que se ejecuta en /EvilSite. Si se apodera del ID de sesión, el usuario malintencionado puede comprometer la cuenta de cualquier usuario del foro que haya navegado a /EvilSite.

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

Los desarrolladores suelen definir las cookies de sesión para que sean un dominio básico como ".example.com". De este modo la cookie de sesión queda expuesta a todas las aplicaciones web en el dominio base y en cualquiera de los subdominios. Compartir las cookies de sesión 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 sesión con un dominio ".example.com" cuando los usuarios inician sesión.

Por ejemplo:

session_set_cookie_params(0, "/", ".example.com", true, true);

suponga 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.

Los desarrolladores suelen definir las cookies de sesión para que estén localizadas en la ruta de acceso al contexto ("/"). Esto expone la cookie a todas las aplicaciones web pertenecientes al mismo nombre de dominio. La pérdida de cookies de sesión puede poner en peligro las cuentas en el sentido de que un atacante puede robar una cookie de sesión utilizando una vulnerabilidad de cualquiera de las aplicaciones del dominio.

Ejemplo 1:
Imagine que tiene una aplicación de foros implementada en http://communitypages.example.com/MyForum y que la aplicación define una cookie de sesión con una ruta "/" cuando los usuarios inician sesión.

Por ejemplo:

session_set_cookie_params(0, "/", "communitypages.example.com", true, true);

Imagine que un atacante crea otra aplicación en http://communitypages.example.com/EvilSite y publica un vínculo a este sitio en el foro. Cuando un usuario del foro hace clic en este vínculo, el explorador envía la cookie de sesión definida por /MyForum a la aplicación que se ejecuta en /EvilSite. Cuando un atacante roba una cookie de sesión, puede poner en peligro la cuenta de cualquier usuario del foro que haya entrado en /EvilSite.

El atributo SameSite protege las cookies de ataques como Cross-site Request Forgery (CSRF). Las cookies de sesión representan a un usuario en el sitio para que el usuario pueda realizar acciones autorizadas. Sin embargo, el navegador envía automáticamente las cookies con la solicitud y, por lo tanto, los usuarios y los sitios web confían implícitamente en el navegador para la autorización. Un atacante puede hacer un uso indebido de esta confianza y realizar una solicitud al sitio en nombre del usuario incrustando enlaces dentro del atributo href y src de las etiquetas, como el link y iframe , en páginas de sitios de terceros que controle un atacante. Si un atacante puede atraer a un usuario desprevenido al sitio de terceros que controla, el atacante puede realizar solicitudes que incluyen automáticamente la cookie de sesión que autoriza al usuario, autorizando efectivamente al atacante como si fuera el usuario.
Establezca el valor del atributo SameSite en Strict en las cookies de sesión. Esto restringe el navegador para agregar cookies solo a las solicitudes que son de navegación de nivel superior o que se originan en el mismo sitio. Las solicitudes que se originan en sitios de terceros a través de enlaces en varias etiquetas como iframe, img y form no tienen estas cookies y, por lo tanto, impiden que el sitio tome medidas que el usuario podría no haber autorizado.

Ejemplo 1: El siguiente código habilita el modo Lax en el atributo SameSite de las cookies de sesión.

    ...
    CookieOptions opt = new CookieOptions()
    {
        SameSite = SameSiteMode.Lax;
    };
    context.Response.Cookies.Append("name", "Foo", opt);
    ...

El atributo SameSite protege las cookies de ataques como la falsificación de petición en sitios cruzados (CSRF). Las cookies de sesión representan a un usuario en el sitio para que el usuario pueda realizar acciones autorizadas. Sin embargo, el navegador envía automáticamente las cookies con la solicitud y, por lo tanto, los usuarios y los sitios web confían implícitamente en el navegador para la autorización. Un atacante puede hacer un uso indebido de esta confianza y realizar una solicitud al sitio en nombre del usuario incrustando enlaces dentro del atributo href y src de las etiquetas, como el link y iframe , en páginas de sitios de terceros que controle un atacante. Si un atacante puede atraer a un usuario desprevenido al sitio de terceros que controla, el atacante puede realizar solicitudes que incluyen automáticamente la cookie de sesión que autoriza al usuario, autorizando efectivamente al atacante como si fuera el usuario.
Configure cookies de sesión con SameSiteStrictMode para el atributo SameSite, que restringe el navegador para agregar cookies solo a las solicitudes que son de navegación de nivel superior o se originan en el mismo sitio. Las solicitudes que se originan en sitios de terceros a través de enlaces en varias etiquetas como iframe, img y form no tienen estas cookies y, por lo tanto, impiden que el sitio tome medidas que el usuario podría no haber autorizado.

Ejemplo 1: El siguiente código habilita SameSiteLaxMode en el atributo SameSite en las cookies de sesión.

c := &http.Cookie{
  Name: "cookie",
  Value: "samesite-lax",
  SameSite: http.SameSiteLaxMode,
}

El atributo SameSite protege las cookies de ataques como Cross-site Request Forgery (CSRF). Las cookies de sesión representan a un usuario en el sitio para que el usuario pueda realizar acciones autorizadas. Sin embargo, el navegador envía automáticamente las cookies con la solicitud y, por lo tanto, los usuarios y los sitios web confían implícitamente en el navegador para la autorización. Un atacante puede hacer un uso indebido de esta confianza y realizar una solicitud al sitio en nombre del usuario incrustando enlaces dentro del atributo href y src de las etiquetas, como el link y iframe , en páginas de sitios de terceros que controle un atacante. Si un atacante puede atraer a un usuario desprevenido al sitio de terceros que controla, el atacante puede realizar solicitudes que incluyen automáticamente la cookie de sesión que autoriza al usuario, autorizando efectivamente al atacante como si fuera el usuario.
Establezca el valor del atributo SameSite en Strict en las cookies de sesión. Esto restringe el navegador para agregar cookies solo a las solicitudes que son de navegación de nivel superior o que se originan en el mismo sitio. Las solicitudes que se originan en sitios de terceros a través de enlaces en varias etiquetas como iframe, img y form no tienen estas cookies y, por lo tanto, impiden que el sitio tome medidas que el usuario podría no haber autorizado.

Ejemplo 1: El siguiente código habilita el modo Lax en el atributo SameSite de las cookies de sesión.

app.get('/', function (req, res) {
    ...
    res.cookie('name', 'Foo', { sameSite: "Lax" });
    ...
}

El atributo SameSite protege las cookies de ataques como la falsificación de petición en sitios cruzados (CSRF). Las cookies de sesión representan a un usuario en el sitio para que el usuario pueda realizar acciones autorizadas. Sin embargo, el navegador envía automáticamente las cookies con la solicitud y, por lo tanto, los usuarios y los sitios web confían implícitamente en el navegador para la autorización. Un atacante puede hacer un uso indebido de esta confianza y realizar una solicitud al sitio en nombre del usuario incrustando enlaces dentro del atributo href y src de las etiquetas, como el link y iframe , en páginas de sitios de terceros que controle un atacante. Si un atacante puede atraer a un usuario desprevenido al sitio de terceros que controla, el atacante puede realizar solicitudes que incluyen automáticamente la cookie de sesión que autoriza al usuario, autorizando efectivamente al atacante como si fuera el usuario.
Configure cookies de sesión con Strict para el atributo SameSite, que restringe el navegador para agregar cookies solo a las solicitudes que son de navegación de nivel superior o se originan en el mismo sitio. Las solicitudes que se originan en sitios de terceros a través de enlaces en varias etiquetas como iframe, img y form no tienen estas cookies y, por lo tanto, impiden que el sitio tome medidas que el usuario podría no haber autorizado.

Ejemplo 1: El siguiente código habilita el modo Lax en el atributo SameSite las cookies de sesión.

ini_set("session.cookie_samesite", "Lax");

El atributo SameSite protege las cookies de ataques como Cross-site Request Forgery (CSRF). Las cookies de sesión representan a un usuario en el sitio para que el usuario pueda realizar acciones autorizadas. Sin embargo, el navegador envía automáticamente las cookies con la solicitud y, por lo tanto, los usuarios y los sitios web confían implícitamente en el navegador para la autorización. Un atacante puede hacer un uso indebido de esta confianza y realizar una solicitud al sitio en nombre del usuario incrustando enlaces dentro del atributo href y src de las etiquetas, como el link y iframe , en páginas de sitios de terceros que controle un atacante. Si un atacante atrae a un usuario desprevenido al sitio de terceros que controla, el atacante puede realizar solicitudes que incluyen automáticamente la cookie de sesión con la autorización del usuario. Esto efectivamente le da acceso al atacante con la autorización del usuario.
Configure cookies de sesión en Strict para el parámetro SameSite, que restringe el navegador para agregar cookies solo a las solicitudes que son de navegación de nivel superior o se originan en el mismo sitio. Las solicitudes que se originan en sitios de terceros a través de enlaces en varias etiquetas como iframe, img y form no tienen estas cookies y, por lo tanto, impiden que el sitio tome medidas que el usuario podría no haber autorizado.

Ejemplo 1: El siguiente código habilita Lax en el atributo samesite en las cookies de sesión.

  response.set_cookie("cookie", value="samesite-lax", samesite="Lax")

La mayoría de los entornos de programación web crean por defecto cookies no persistentes. Estas cookies se guardan únicamente en la memoria del navegador (no se escriben en el disco) y se pierden cuando se cierra el navegador. Los programadores pueden especificar que las cookies permanezcan en las sesiones del navegador hasta una fecha futura. Dichas cookies se escriben en el disco y perduran durante las sesiones del navegador y los reinicios del ordenador.

Si la información privada se almacena en cookies persistentes, los atacantes tienen una ventana de tiempo más grande para robar estos datos, sobre todo porque las cookies persistentes a menudo caducan en un futuro lejano. Las cookies persistentes se suelen utilizar para elaborar perfiles de usuarios cuando interactúan con un sitio. Dependiendo de lo que se haga con estos datos de seguimiento, es posible que se utilicen cookies persistentes para violar la privacidad de los usuarios.

Ejemplo 1: El siguiente código establece una cookie para que expire en 10 años.

...
Integer maxAge = 60*60*24*365*10;
Cookie cookie = new Cookie('emailCookie', emailCookie, path, maxAge, true, 'Strict');
...

La mayoría de los entornos de programación web están predeterminados para crear cookies no persistentes. Estas cookies residen solo en la memoria del explorador (no se escriben en disco) y se pierden cuando el explorador se cierra. Los programadores pueden especificar que las cookies persistan de una sesión del explorador a otra hasta una fecha determinada. Estas cookies se escriben en disco y perduran a lo largo de las sesiones del explorador y los reinicios del equipo.

Si se almacena información privada en cookies persistentes, los atacantes tienen un margen de tiempo mayor durante el que robar estos datos, más cuando las cookies persistentes a menudo se configuran para caducar dentro de mucho tiempo. Con frecuencia, las cookies persistentes se utilizan para realizar perfiles de usuario ya que interactúan con un sitio. Dependiendo de lo que se haga con estos datos de seguimiento, se pueden utilizar estas cookies persistentes para violar la privacidad de los usuarios.
Ejemplo: el siguiente código configura una cookie para caducar en 10 años.

    HttpCookie cookie = new HttpCookie("emailCookie", email);
    cookie.Expires = DateTime.Now.AddYears(10);;