Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security vulnerabilities #97

Open
jsardev opened this issue Jan 4, 2019 · 3 comments
Open

Security vulnerabilities #97

jsardev opened this issue Jan 4, 2019 · 3 comments

Comments

@jsardev
Copy link

jsardev commented Jan 4, 2019

Just a suggestion: it would be cool to add some information about security concerns in different JWT storage methods on the client-side (cookie/localStorage) - XSS, CSRF etc.

@nelsonic
Copy link
Member

nelsonic commented Jan 4, 2019

@sarneeh thank you for opening this issue. 👍
If you have time to create a Pull Request please go for it! (you have write access to this repository)

Security concerns applicable to JWTs are the same as for other token schemes.
If a malicious user is able to run an XSS attack on the domain they will be able to acquire the JWT and use it to impersonate the user regardless of how it is stored on the client.
Malicious JS can read and leak cookies and localStorage just as easily.

We should advise people using JWTs that they do not protect against OWASP attacks and are merely a convenient way of transmitting signed claims/data. 📝

@jsardev
Copy link
Author

jsardev commented Jan 4, 2019

@nelsonic

Security concerns applicable to JWTs are the same as for other token schemes.
If a malicious user is able to run an XSS attack on the domain they will be able to acquire the JWT and use it to impersonate the user regardless of how it is stored on the client.
Malicious JS can read and leak cookies and localStorage just as easily.

I partially agree. You have something like a httpOnly and secure cookie which prevents an attacker from acquiring your JWT. But I totally agree that if you're open to XSS attacks, this doesn't protect you from anything as someone can do stuff on behalf of the user (not stealing the token, but i.e. injecting a malicious script).

So I guess that in the end, it doesn't matter if you use localStorage or a cookie - if you're open to OWASP attacks - you're screwed. But if you're protected against them - you should be safe with both methods.

I'd love to prepare some PR but I'm hard on time right now and will be free just in the next 1-2 months. If someone won't outrun me I'll prepare some PR 😄

@ilan-schemoul
Copy link

ilan-schemoul commented Nov 13, 2019

@sarneeh thank you for opening this issue.
If you have time to create a Pull Request please go for it! (you have write access to this repository)

Security concerns applicable to JWTs are the same as for other token schemes.
If a malicious user is able to run an XSS attack on the domain they will be able to acquire the JWT and use it to impersonate the user regardless of how it is stored on the client.
Malicious JS can read and leak cookies and localStorage just as easily.

We should advise people using JWTs that they do not protect against OWASP attacks and are merely a convenient way of transmitting signed claims/data.

As said above cookie can have httpOnly option.
According to this article it is really unsecure to use localstorage instead of httponly cookie

While I feel like I made myself clear that you should never ever store sensitive information in local storage in the previous section, I feel the need to specifically call out JSON Web Tokens (JWTs).
The biggest security offenders I see today are those of us who store JWTs (session data) in local storage. Many people don’t realize that JWTs are essentially the same thing as a username/password.
If an attacker can get a copy of your JWT, they can make requests to the website on your behalf and you will never know. Treat your JWTs like you would a credit card number or password: don’t ever store them in local storage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants