protección CSRF con ID de sesión

Parece que la solución simple (es decir, la protección CSRF pero con todos los recursos web que se pueden almacenar en caché) es simplemente agregar una cookie separada que contenga el token anti-CSRF pero accesible a la página javascript.

En otras palabras, cuando el cliente inicie sesión, realmente estableceré dos cookies (un identificador de sesión HttpOnly y un token anti-CSRF no HttpOnly, al que se accede mediante scripts de página). Por lo tanto, el servidor almacenará (junto con un ID de sesión del cliente) su valor de token anti-CSRF y validará que es el mismo valor que el establecido originalmente a través de la segunda cookie. Si la validación falla, tienes un CSRF potencial.

Este enfoque también se menciona en otros lugares de la web ...

Citado en Página de Prevención de CSRF de OWASP :

  

Doble envío de cookies

     

El envío doble de cookies se define como enviar la cookie de ID de sesión de dos maneras diferentes para cada solicitud de formulario. Primero como un valor de encabezado tradicional, y nuevamente como un valor de forma oculta. Cuando un usuario visita un sitio, el sitio debe generar un valor pseudoaleatorio (criptográficamente fuerte) y establecerlo como una cookie en la máquina del usuario. Esto normalmente se conoce como el ID de sesión. El sitio debe requerir que cada envío de formulario incluya este valor pseudoaleatorio como un valor de formulario oculto y también como un valor de cookie. Cuando se envía una solicitud POST al sitio, la solicitud solo debe considerarse válida si el valor del formulario y el valor de la cookie son los mismos. Cuando un atacante envía un formulario en nombre de un usuario, solo puede modificar los valores del formulario. Un atacante no puede leer los datos enviados desde el servidor ni modificar los valores de las cookies, según la política del mismo origen. Esto significa que mientras un atacante puede enviar cualquier valor que desee con el formulario, el atacante no podrá modificar o leer el valor almacenado en la cookie. Dado que el valor de la cookie y el valor del formulario deben ser los mismos, el atacante no podrá enviar un formulario con éxito a menos que sea capaz de adivinar el valor de ID de sesión.

     

Si bien este enfoque es eficaz para mitigar el riesgo de falsificación de solicitudes entre sitios, los identificadores de sesión autenticados en los parámetros HTTP pueden aumentar el riesgo general de secuestro de sesión. Los arquitectos y desarrolladores deben asegurarse de que ningún dispositivo de red, código de aplicación personalizado o módulos registren explícitamente o revelen los parámetros HTTP POST. Un atacante que pueda obtener acceso a los repositorios o canales que pierden los parámetros POST de HTTP podrá reproducir los tokens y realizar ataques de secuestro de sesión. Sin embargo, tenga en cuenta que el registro transparente de todos los parámetros HTTP POST es una ocurrencia rara en los sistemas de red y las aplicaciones web, ya que al hacerlo expondrán datos confidenciales significativos además de los identificadores de sesión, incluidas las contraseñas, los números de tarjetas de crédito y los números de seguridad social. La inclusión del identificador de sesión en HTML también puede aprovecharse mediante ataques de scripts entre sitios para evitar las protecciones de HTTPOnly. La mayoría de los navegadores modernos impiden que las secuencias de comandos del lado del cliente accedan a las cookies HTTPOnly. Sin embargo, esta protección se pierde si los identificadores de sesión HTTPOnly se colocan dentro de HTML, ya que las secuencias de comandos del lado del cliente pueden atravesar y extraer fácilmente el identificador del DOM. Se sigue recomendando a los desarrolladores que implementen el patrón de token del sincronizador como se describe en este artículo.

No hay una razón real para no usar simplemente el mecanismo de prevención CSRF incorporado, casi todos los marcos serios lo tienen ahora.

No, porque nunca debe permitir que los scripts puedan acceder a sus cookies. Consulte HTTPOnly en el sitio web de OWASP.

Para evitar que las personas puedan robar los ID de sesión, en caso de que XSS esté presente, siempre debe establecer esta marca de cookie. Su mecanismo ya no funcionará ya que no podría acceder a la cookie.

Usted podría , pero me parece un poco difícil de manejar. Cualquier mecanismo de prevención de CSRF funciona así:

• Hacer que el servidor solo acepte solicitudes que cumplan con algunas condiciones
• Asegúrese de que las condiciones sean algo que no pueda ser falsificado
• Escriba su HTML para que las solicitudes que genere sigan las condiciones establecidas por el servidor.

El método probado y probado es usar <input type=hidden> en los campos HTML que contienen algún token anti-CSRF. Su método también funciona con ¹ , pero usar JS para interceptar e inyectar solicitudes POST suena complicado e innecesario cuando toda la lógica del lado del cliente puede estar contenida en el HTML.

^{1 Como señaló TildalWave, colocar datos confidenciales en cookies que no sean httponly y hacer accesible el JS del lado del cliente podría ser un problema si tiene vulnerabilidades de XSS. Seguir con el método probado y probado entonces.}

Como lo mencionó un número de personas, el envío doble es una protección correcta de CSRF, siempre que utilice un nonce separado. El uso de id de sesión es muy incorrecto en este contexto, comenzando con el hecho de que sessionid tiene que ser HTTPOnly para la protección XSS.

El argumento de "qué pasa si hay XSS en esta página / sitio web" no es válido. Cuando tienes XSS, CSRF es la menor de tus preocupaciones. El navegador se puede controlar de forma remota a través de un script inyectado y no se requiere que CSRF obligue al navegador a realizar acciones en nombre del usuario.