Something that interests me is the storage of JWT. Whilst I appreciate the usage of cookies can aid to remove the accessibility of the cookie via client side javascript, my implementation required some of the data to be accessible. I went with storing the JWT in local storage. This brought me on to thinking deeper around JWT security. Technically even with a secure cookie I can still use chrome extensions to read it's content and thus extract the JWT. Once I have this JWT there is nothing stopping me passing this token to someone else who would have the exact same privileges as myself.
I assume under scenarios where tokens get passed around or an attacker engineers a method to retrieve such token then there really isn't much else you can do? Maybe browser fingerprinting would help as an additional check?
I'm on the faculty at Boston University in the computer science department, where I teach software engineering, intro courses, and application architecture and development. Also a bit of a Deadhead.
A really good point; maybe one of our security wonks will drop in and offer an opinion.
One approach might be to use the JWT in combination with a session identifier which changes on each request/response pair. The client would need to present both the signed JWT and the correct session identifier; both would be sent on the request automatically and both would be deleted when the browser or tab is closed. On the server side, seeing the same session identifier twice would be an error and would indicate a possible attack.
Also, requiring HTTPS would reduce the chance of a man-in-the-middle or sniffing attack.
In your case, where some data needs to be visible on the client, I think I'd still use the secure JWT and then send a second object back on the response with the data.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Quite timely I have recently asked a question in relation to this here: dev.to/imthedeveloper/critique-my-...
Something that interests me is the storage of JWT. Whilst I appreciate the usage of cookies can aid to remove the accessibility of the cookie via client side javascript, my implementation required some of the data to be accessible. I went with storing the JWT in local storage. This brought me on to thinking deeper around JWT security. Technically even with a secure cookie I can still use chrome extensions to read it's content and thus extract the JWT. Once I have this JWT there is nothing stopping me passing this token to someone else who would have the exact same privileges as myself.
I assume under scenarios where tokens get passed around or an attacker engineers a method to retrieve such token then there really isn't much else you can do? Maybe browser fingerprinting would help as an additional check?
A really good point; maybe one of our security wonks will drop in and offer an opinion.
One approach might be to use the JWT in combination with a session identifier which changes on each request/response pair. The client would need to present both the signed JWT and the correct session identifier; both would be sent on the request automatically and both would be deleted when the browser or tab is closed. On the server side, seeing the same session identifier twice would be an error and would indicate a possible attack.
Also, requiring HTTPS would reduce the chance of a man-in-the-middle or sniffing attack.
In your case, where some data needs to be visible on the client, I think I'd still use the secure JWT and then send a second object back on the response with the data.