¿Qué tan seguro es usar una aplicación web basada en JWT en una computadora compartida?

2

Teniendo en cuenta que tengo una aplicación web basada en JWT, que no compara JWT con alguna base de datos (lo cual, a mi entender, anularía el uso de JWT ya que cualquier cadena aleatoria haría lo mismo). El tiempo de espera de JWT es lo suficientemente largo, por lo que durará al menos unos minutos después de que 'cierre la sesión'.

La computadora está compartida, pero está segura de que no tiene instalados registradores de teclas, rastreadores ni modificaciones del navegador (que, por ejemplo, pueden ser probadas, o el sistema está bien protegido y solo tiene conexión a Internet monitoreada, no hay periféricos o simplemente todos es monitoreado). El JWT se almacena en la memoria de JavaScript, o en localStorage, que se limpia después de presionar el botón 'cerrar sesión'. La pestaña en la que se cierra la aplicación. Después de que me vaya, cualquiera puede sentarse y usar el mismo navegador.

¿Qué tan segura es mi aplicación web entonces? Si alguien recibe el token, aún así, durante unos minutos, podrá trabajar como eran yo. El almacenamiento local fue purgado. El depurador del navegador estaba inactivo o fue purgado. ¿Hay algún otro lugar al que alguien pueda acceder donde se pueda leer el token?

    
pregunta 9ilsdx 9rvj 0lo 15.11.2016 - 15:47
fuente

2 respuestas

1

El JWT tiene tanta protección como una cookie, excepto que confía en la capacidad del desarrollador para manejar la gestión del token correctamente. Poner el token es localStorage significa que puede persistir en los cierres del navegador a menos que se haga algo explícitamente para eliminarlo (por ejemplo, el botón de cerrar sesión, enganchar el evento de cierre para borrarlo). Como alternativa, sessionStorage funciona de una manera similar, pero borrará automáticamente los valores cuando se cierre el navegador (la compensación es que no puede compartir el token en las pestañas / ventanas del navegador).

Además, la capacidad de prevenir cosas como el robo de token de XSS se reduce considerablemente porque cualquier JavaScript puede consultar localStorage / sessionStorage, mientras que el navegador tiene defensas incorporadas para evitar que JavaScript lea cookies. Por otro lado, potencialmente obtienes algunas defensas inherentes contra CSRF porque el token se debe agregar a la solicitud manualmente.

Así como todas las cosas, todo esto depende de sus requisitos de seguridad. Teniendo en cuenta todas sus advertencias, parece que podría estar bien, por lo que está a la par con las sesiones basadas en cookies. Por otro lado, no necesariamente protege contra alguien realmente interesado en robar tu token. Dicho esto, un navegador no va a hacer mucho para ayudarlo en ese sentido de todos modos, por lo que podría considerar que todas las sesiones se inicien en una sesión de navegación privada / incógnito / etc.

    
respondido por el Steve 15.11.2016 - 16:49
fuente
0

Lo más simple que se puede hacer en este caso, que debería hacer de todos modos, es que, al cerrar la sesión, invalide el token en el servidor. Ahora no importa en absoluto ya que no es posible un ataque de repetición.

Por supuesto, esto requiere algún procesamiento en el servidor que JWT está tratando de limitar, pero en realidad no hay una forma realista de proporcionar una buena seguridad sin algún procesamiento en el extremo del servidor.

    
respondido por el Julian Knight 15.12.2016 - 20:46
fuente

Lea otras preguntas en las etiquetas