Seguridad. Hoy en día, ninguna aplicación puede sobrevivir a Internet si no tiene programada la seguridad adecuada, ya sea por el marco utilizado por el desarrollador o por el propio desarrollador. Actualmente estoy desarrollando una API RESTful para trabajar con la autenticación de token de portador, pero he estado leyendo sobre ataques XSS y CSRF.

Pregunta 1) Por lo que he leído, veo que las aplicaciones que consumen API RESTful que usan autenticación basada en token son vulnerables a XSS yno CSRF si el token se almacena en localStorage / sessionStorage del navegador en lugar de en cookies. Esto se debe a que, para que CSRF funcione, la aplicación debe usar cookies. ¿Estoy en lo correcto?

Pero ahora que los tokens se almacenan en localStorage / sessionStorage, la aplicación se vuelve vulnerable a los ataques XSS. Si hay alguna parte de la aplicación que no desinfecta las entradas (por ejemplo, el marco desinfecta las entradas angulares, pero tal vez una determinada biblioteca de terceros que estoy usando no desinfecta las entradas por defecto), entonces un atacante puede inyectar mal código para robar tokens de otros usuarios y luego realizar solicitudes autenticadas al hacerse pasar por ellos.

Pregunta 2) Hay una manera de protegerse contra estos dos ataques en su aplicación que consume una API RESTful. Me encontré conesta publicación. La esencia de ese artículo es que en el momento en que el usuario inicia sesión y solicita un token de portador, el servidor también devuelve unhttpOnly cookie que actuaría como, digamos,CSRFProtectionCookie. Creo que la solución en el artículo es bastante robusta y proporciona una protección sólida. De nuevo, ¿estoy en lo correcto? ¿Cuáles son tus puntos de vista?

Mi aplicación y mi versión del enfoque mencionado en la publicación anterior

El enfoque mencionado en la publicación anterior requiere que persistaCSRFProtectionCookie en una base de datos de algún tipo. No quiero hacer eso No quiero que la base de datos se vea afectada cada vez que se realiza una solicitud autenticada a la API. En cambio, lo que puedo hacer es esto:

Iniciar sesión

El usuario envía una solicitud POST al punto final del token con nombre de usuario y contraseñaEl servidor de autorización valida las credenciales del usuario y comienza a construir JWT con ciertas reclamaciones.Como parte de la construcción de JWT, también genera una cadena aleatoria,hashes y lo agrega como, digamos,csrf reclamar a la JWT.Además, a continuación, el servidor establece unhttpOnly cookie llamadaXSRF-TOKEN cuyo valor es la misma cadena aleatoria peroencriptado esta vez.Devuelve la respuesta al navegador. El navegador obtiene tanto el token portador como el cuerpo de respuesta y elXSRF-TOKEN se establece la cookie

Solicitudes autenticadas

La aplicación llama a puntos finales autenticados agregando el token portador JWT comoAuthorization encabezamiento. El navegador envía automáticamente la cookie.

El servidor descifra la cookie para obtener texto sin formato. El servidor luego verifica este texto plano con el hash presente en el JWT.

Si coincide, proceda con la solicitud. De lo contrario, devuelva la respuesta no autorizada.

Creo que esto brinda protección contra CSRF y XSS. Como tanto el token como la cookie (httpOnly) son necesarios para realizar solicitudes autenticadas.

Pregunta Sí, esto elimina la necesidad de persistir en la base de datos (¿o no? ¿Me falta alguna escapatoria?). Pero, ¿cuál es la sobrecarga de descifrar y verificar hashes en cada solicitud de usuario? ¿Es más sobrecarga que la E / S de la base de datos? Además, cualquier otra sugerencia para este enfoque u otros enfoques son bienvenidos.

Gracias :)