|
Hello Group, Recently our team at Health data Compass (University of Colorado) has discovered, a logout function which the user can initiate to terminate their session. This function clears session tokens within the user’s browser but does not terminate these values server-side. This leaves these values valid for an extended period. If an attacker were able to steal valid session credentials, they would have access to the application for a prolonged period. We have also found the Leaf web application uses the GET method instead of the POST method for requests which contain potentially sensitive information. This can result in this information being stored within the web browser history, any intermediary caches or proxies that are in use, and in web server logs. Has anyone tried using a server-side database as a blacklist for JWT tokens stopping there re-use of a token until it expires? Also, has anyone implemented a node.js or javascript script that removes the JWT from the client's browser? Before I implement a POST request in place of the GET request, is there anything in the codebase I should worry about with this change? Gabriel LaBrie |
Replies: 2 comments
|
Hi @glabrie10, Thanks for your questions. I'd very much like to learn the particulars of your findings. If you'd be more comfortable discussing outside GitHub we could certainly do so. Regarding logouts, I'm not clear on what you mean by tokens not being invalidated server-side upon logout. The code at /api/user/logout server-side does invalidate the user's current Access Token. If there is a bug you've found related to this, please let us know. As to GETs with sensitive information, here too it's not clear to me which API calls you have in mind. To my knowledge no one has attempted to do what you are asking. Best, |
|
I wanted to update this for future implementations of leaf. It was an error on our end regarding token de-validation server-side. Leaf has a built-in blacklist for session tokens. We hadn't set our URL in the appsetting.json to go through Shibboleth pushing these tokens to the blacklist. Once remedied, it worked correctly. |
I wanted to update this for future implementations of leaf. It was an error on our end regarding token de-validation server-side. Leaf has a built-in blacklist for session tokens. We hadn't set our URL in the appsetting.json to go through Shibboleth pushing these tokens to the blacklist. Once remedied, it worked correctly.