En el contexto de una aplicación web ... los tokens confidenciales, como los utilizados para sesiones, autenticación y / o autorización, deben almacenarse en localStorage o en una cookie HTTPOnly; ¿O son ambos enfoques aceptables en diferentes circunstancias?

Para los fines de esta pregunta, suponga que el token en cuestión, cualquiera que sea la forma que pueda tomar, podría aprovecharse para hacerse pasar por el usuario / secuestrar su sesión si se revelara a un adversario.

Fondo

Mi entendimiento / creencia personal siempre ha sido que las cookies HTTPOnly son la opción de seguridad óptima en estas situaciones, debido a los riesgos asociados con las secuencias de comandos entre sitios. hoja de trucos de HTML5 de OWASP recomienda lo mismo.

Pro HTTPOnly cookies:

• Un ataque exitoso de secuencias de comandos entre sitios no puede acceder al token.
• Las extensiones de navegador malintencionadas no pueden acceder al token.
• Explotar el token es más difícil para el atacante, que tiene que realizar XMLHttpRequests a través del navegador de la víctima (cuando el token se adjuntará automáticamente a la solicitud).

Pro localStorage / sessionStorage:

• Los ataques de falsificación de solicitudes entre sitios se evitan por completo.

Para mí, tanto los ataques XSS como los CSRF son complejos de proteger y, como resultado, se beneficiarían de múltiples capas de controles de seguridad. Es decir. Veo que los equipos de desarrollo con experiencia todavía producen aplicaciones con el error ocasional XSS y / o CSRF: la protección contra estos problemas de manera universal y a escala puede ser un desafío.

localStorage parece resolver completamente CSRF, pero deja el token accesible a JavaScript malicioso en caso de un error de XSS. Las cookies de HTTP solo mitigan parcialmente el XSS, pero presentan CSRF como un nuevo vector de ataque, que debe protegerse mediante sus propios controles. El impacto de un ataque XSS es potencialmente mayor que el CSRF.