¿Es seguro almacenar el valor del parámetro de estado en una cookie?

3

Según enlace :

  

El cliente DEBE implementar la protección CSRF para su URI de redirección.      Esto se logra típicamente requiriendo cualquier solicitud enviada al      el punto final de URI de redirección para incluir un valor que vincule la solicitud a      el estado autenticado del agente de usuario (por ejemplo, un hash de la sesión      cookie utilizada para autenticar al usuario-agente). El cliente DEBE      utilizar el parámetro de solicitud "estado" para entregar este valor a la      servidor de autorización al realizar una solicitud de autorización .

     

Una vez obtenida la autorización del usuario final, la      el servidor de autorización redirige al usuario-agente del usuario final a la      Cliente con el valor de enlace requerido contenido en el "estado"      parámetro. El valor de enlace permite al cliente verificar la      validez de la solicitud haciendo coincidir el valor de enlace con el      Estado autenticado por el usuario-agente . El valor de enlace utilizado para CSRF      La protección DEBE contener un valor no adivinable (como se describe en      Sección 10.10), y el estado autenticado del agente de usuario (por ejemplo,      cookie de sesión, almacenamiento local HTML5) DEBE mantenerse en una ubicación      accesible solo para el cliente y el usuario-agente (es decir, protegido por      política del mismo origen).

¿Es seguro usar una cookie segura, HTTPOnly, SameSite (por ejemplo, con un breve tiempo de espera) para almacenar el valor del parámetro state ? ¿Validar el valor en la cookie con el valor en el parámetro state sería suficiente para verificar la validez de la solicitud?

    
pregunta neverendingqs 25.10.2016 - 23:28
fuente

1 respuesta

1
  

¿Es seguro usar una cookie segura, HTTPOnly, SameSite (por ejemplo, con un breve tiempo de espera) para almacenar el valor del parámetro de estado?

Puedes hacer lo más seguro.

Suponiendo que está escribiendo software del lado del servidor (supongo que sí, ya que mencionó la configuración de la opción HTTPOnly para la cookie): cifre el parámetro de estado en el servidor y almacene el valor cifrado en la cookie. (Detalles: asegúrese de usar un algoritmo de cifrado seguro con un iv aleatorio, y no use el modo ecb). Asegúrese de mantener la clave de cifrado segura en el servidor.

¿Por qué cifrar la cookie?

Debe cifrar el valor del estado (o la cookie completa) por dos razones:

  1. En principio: a las personas de seguridad les gusta colocar sus medidas de seguridad en capas. Si uno falla, el otro todavía te protegerá. Incluso si Usted protege su tráfico con SSL, el cifrado SSL puede verse comprometido. Por ejemplo, donde trabajo, tenemos un firewall de inspección de contenido que hace MITM en SSL, por lo que rompe la seguridad de la conexión por diseño. (Esta es una idea realmente mala, en general, pero creo que es bastante común, y significa que no puede contar con SSL que proteja la conexión de su servidor a sus clientes.

  2. Para proteger el valor del estado del cliente (agente de usuario). Si hay malware en su cliente, no desea exponerle el valor del estado. Podría ser robado. Si el valor del estado está cifrado, el software del cliente no tiene acceso a él, lo que es bueno.

¿Esto es seguro?

Esto es tan seguro como almacenar un identificador de sesión en la cookie y luego usar el identificador de sesión como un índice en una tabla de base de datos del lado del servidor, ya que ni el navegador ni el javascript malintencionado se encuentran en el navegador ni nadie más ve nada más. que una cadena opaca de apariencia aleatoria en su cookie encriptada, y si se meten con ella de alguna manera, no se descifra al valor del estado original, lo que hará que la verificación del estado falle. Pero es posible que desee agregar un MAC (código de autenticación de mensaje) y solo toque el valor de estado cifrado de la cookie cuando MAC verifica para asegurar su contenido de cookies contra la intromisión.

Procesamiento local en el navegador en el navegador frente a servidor

Si está escribiendo javascript del navegador que realiza solicitudes auth, debe ser extremadamente cuidadoso (pero la seguridad del navegador con javascript está básicamente dañada; si tiene una aplicación de navegador con javascript hacer solicitudes auth, dudo que pueda hacer eso realmente seguro - puede hacerlo razonablemente seguro, pero probablemente no pueda defenderse contra un adversario determinado.

¿Es suficiente validar el parámetro de estado?

  

¿Sería suficiente validar el valor en la cookie con el valor en el parámetro de estado para verificar la validez de la solicitud?

Si la validación del estado es suficiente para validar una solicitud de verdad (¿respuesta?) depende del flujo que esté utilizando y en qué paso del protocolo se encuentra.

Por ejemplo, si recuperas un token jwt id, en casi todos los escenarios debes must verificar el token id para asegurarte de que sea válido y adecuado para ti (puedes hacerlo usted mismo o envíelo a un punto final de verificación. Un token jwt id está firmado digitalmente y debe asegurarse de que la firma esté bien, que el público y su identificación de cliente coincidan, el token no haya caducado, etc.).

Lo mismo ocurre con los tokens de acceso: si, por ejemplo, no verifica la audiencia del token de acceso, pueden ocurrir cosas malas (por ejemplo, el token de acceso podría estar destinado a otro cliente ...)

Hay algunos casos en los que no necesita verificar los tokens. Cuando utiliza Open ID Connect para obtener un token de ID de un proveedor de identidad y no enruta la solicitud a través del navegador, y recupera el token de ID de su proveedor de identidad a través de la solicitud del lado del servidor, entonces creo que puede Confía en el token de identificación sin verificación. Sin embargo, siempre lo verifico, solo para asegurarme de no tropezar con mi propia inteligencia ;-)

    
respondido por el Pascal 26.10.2016 - 00:15
fuente

Lea otras preguntas en las etiquetas