Considering I have JWT-based web application, which does not check JWT against some database (which would, to my understanding, made JWT usage void since any random string would make the same). The JWT timeout is long enough, so that it will last at least a few minutes after I 'logout'.

The computer is shared, but it is sure it has no keyloggers, sniffers or browser modifications installed (which, say, can be proofed, or the system is well protected and has only monitored internet connection, no peripherals, or simply all is monitored). The JWT is stored in the JavaScript memory, or in localStorage, which is cleaned after pressing 'logout' button. The tab in which the application is closed. After I leave, anybody can sit and use the same browser.

How safe is my web application then? If someone get the token, they will still, for a few minutes, be able to work as they were me. The local storage was purged. The browser debugger was inactive or was purged. Is there any other place anyone can access where the token could be read?

  • Token replay attacks are often overlooked by web developers keen to use something that isn't a cookie or "traditional" session. But as you correctly identify, JWT on its own is far from ideal. It is up to the web developer to ensure that replay attacks are mitigated. Your scenario takes things to an extreme (though absolutely valid) level. – Julian Knight Dec 15 '16 at 19:37

The JWT has about as much protection as a cookie, except you're relying on the ability of the developer to handle the management of the token correctly. Putting the token is localStorage means it can persist across browser closes unless something is explicitly done to remove it (e.g. logout button, hook the close event to clear it). Alternatively sessionStorage works in a similar manner, but will automatically clear values when the browser is closed (the trade off being you can't share the token across browser tabs/windows).

Additionally, the ability to prevent things like XSS token stealing is reduced considerably because any JavaScript can query localStorage/sessionStorage, whereas the browser has built-in defenses to prevent JavaScript from reading cookies. On the other hand, you potentially get some inherent defenses against CSRF because the token must be added to the request manually.

So like all things, this all depends on your security requirements. Given all your caveats, it seems like it might be fine such that it's on par with cookie-based sessions. On the other hand, it doesn't necessarily protect against someone seriously interested in stealing your token. With that said, a browser isn't going to do much to help you in that regard anyway, so you might consider requiring all sessions be launched in a private browsing session/incognito/etc.

  • "ability to prevent" is correct and correctly implies that the web developer has more work to do to prevent replay attacks. Normally, this is dealt with by incorporating something unique to the browser/PC in the token such as the IP address but that wouldn't be enough in this instance. – Julian Knight Dec 15 '16 at 19:40

The simple thing to do in this case, which you should do anyway, is - on logout - invalidate the token at the server. Now it doesn't matter at all since no replay attack is possible.

Of course, this does require some processing at the server which JWT is trying to limit but in reality there is no realistic way to provide good security without some processing at the server end.

  • But AFAIK, it's not possible to invalidate JWT on server, because JWT is self-containing... – 9ilsdx 9rvj 0lo Dec 16 '16 at 9:00
  • But that's what I'm saying. JWT itself is self-contained but JWT on its own isn't all that secure. It is highly susceptible to replay attacks. If that matters to you, you need to add additional checks & that almost certainly requires some server-side processing. – Julian Knight Dec 16 '16 at 9:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.