3 ms·

This post is about XSS, not JWTs... > For security reasons, it is advisable for users to log out from a web application once they have completed their tasks N

This post is about XSS, not JWTs... > For security reasons, it is advisable for users to log out from a web application once they have completed their tasks No, the application should be resistant to XSS instead. Online banking and such are automatically logging out to prevent someone stepping away from the device and another person abusing the logged in session. > Frequently, when a Logout function is present in the application and is implemented with JSON Web Tokens, the application stores the JWT in an insecure location, such as the JavaScript code itself or the local storage in the user’s browser This claim is as valid as "Frequently, when a Logout function is present in the application and is implemented without JSON Web Tokens, the application stores the plaintext password in an insecure location". The storage location is completely independent of whether it's a JWT or not.

alex_duf 3y ago
>No, the application should be resistant to XSS instead Or we can admit that vulnerabilities are a likely possibility, despite all of our efforts. Therefore the most secure approach is to understand that limiting the impact of one vulnerability is a reasonable way of dealing with it. Otherwise you're suggesting running application code as root on the machine isn't a problem, since your application has no vulnerability.
- aidos 3y ago
  I don’t understand the downvotes here. The application should be as resistant to xss as possible but things do sneak through and we should try to limit the damage in other layers. An example is that you could think you have no xss issues because you use react to do your rendering. Meanwhile you have a window.location = something_from_url which is just as capable of running js code if you’re not careful. Having the auth (whatever it is) in a http only cookie is one protection. Having it time limited is another. For some applications locking it to an ip address might make sense. It’s not an either / or thing.
  - marius_k 3y ago
    Using xss one might target login form and steal username/password instead of a token. So I do not see argument here against jwt. Sure the xss will have to be more sofisticated(?)
    - aidos 3y ago
      I’m not arguing for / against any specific technology. I’m saying that relying on a lack of security flaws in one layer isn’t a great idea.

alex_duf 3y ago

>No, the application should be resistant to XSS instead Or we can admit that vulnerabilities are a likely possibility, despite all of our efforts. Therefore the most secure approach is to understand that limiting the impact of one vulnerability is a reasonable way of dealing with it. Otherwise you're suggesting running application code as root on the machine isn't a problem, since your application has no vulnerability.

aidos 3y ago
I don’t understand the downvotes here. The application should be as resistant to xss as possible but things do sneak through and we should try to limit the damage in other layers. An example is that you could think you have no xss issues because you use react to do your rendering. Meanwhile you have a window.location = something_from_url which is just as capable of running js code if you’re not careful. Having the auth (whatever it is) in a http only cookie is one protection. Having it time limited is another. For some applications locking it to an ip address might make sense. It’s not an either / or thing.
- marius_k 3y ago
  Using xss one might target login form and steal username/password instead of a token. So I do not see argument here against jwt. Sure the xss will have to be more sofisticated(?)
  - aidos 3y ago
    I’m not arguing for / against any specific technology. I’m saying that relying on a lack of security flaws in one layer isn’t a great idea.