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

Update: JSON_Web_Token_for_Java_Cheat_Sheet #1458

Open
Tib3rius opened this issue Jul 29, 2024 · 8 comments
Open

Update: JSON_Web_Token_for_Java_Cheat_Sheet #1458

Tib3rius opened this issue Jul 29, 2024 · 8 comments
Labels
ACK_WAITING Issue waiting acknowledgement from core team before to start the work to fix it. HELP_WANTED Issue for which help is wanted to do the job. UPDATE_CS Issue about the update/refactoring of a existing cheat sheet.

Comments

@Tib3rius
Copy link

What is missing or needs to be updated?

The Token Storage on Client Side page recommends using Session Storage over Local Storage, seemingly because Local Storage persists between browser restarts (accurate), however it makes no mention of the fact that Session Storage is implemented per-tab and not per-site. That is, if example.com adds some item to Session Storage, and a user then opens a new tab through any method other than "duplicate tab" (e.g. right-click -> open link in new tab), the new tab will have a completely new (and empty) Session Storage instance, even if the user goes to example.com.

Since opening things in multiple tabs is pretty common user behavior, it is not realistic (IMO) for the recommended method to be implemented by developers.

How should this be resolved?

Honestly, I think the recommendation should be to use Local Storage but with tokens that have short expiration times. There's no perfect solution, but Session Storage doesn't work at all so it's surprising to see it being recommended.

@Tib3rius Tib3rius added ACK_WAITING Issue waiting acknowledgement from core team before to start the work to fix it. HELP_WANTED Issue for which help is wanted to do the job. UPDATE_CS Issue about the update/refactoring of a existing cheat sheet. labels Jul 29, 2024
@jmanico
Copy link
Member

jmanico commented Jul 31, 2024

ASVS also recommends session storage over local storage and I'd like to be consistent with that.

If you want to suggest localStorage please please make sure you state this is only a suggestion if the token exp time is low. Overall I do not suggest localStorage for most services.

@Tib3rius
Copy link
Author

@jmanico right but surely that just means ASVS needs changing? We shouldn't be recommending developers use a storage medium for session tokens that deletes them when their users do the simple act of opening a page in a new tab, IMO.

Do you know of any modern app that actually stores them in Session Storage, and how that app maintains sessions with new tabs? If you want to stick with Session Storage, then the advice at least needs to be updated to mention the downsides and how to get around them...

@jmanico
Copy link
Member

jmanico commented Aug 3, 2024

I suggest that the USERNAME can be stored long term, but features that maintain a long term active session is discouraged for secure software. In general we suggest 15-30 minute idle timeout and a absolutely timeout of like 8 hours.

So storing a active session is localstorage that keeps a user logged in long term is discouraged for any secure software.

@Tib3rius
Copy link
Author

Tib3rius commented Aug 3, 2024

@jmanico I appreciate the response but you aren't really answering any of my questions here, and I never once mentioned long term active sessions. My point from the start has been that the OWASP recommendations simply don't work practically for modern websites / browsers.

How does a secure application maintain a session, stored in Session Storage, when a user opens a link in a new tab?

It is this fact that I am most concerned about, because if developers were to implement OWASP recommendations as they currently stand, most if not all applications would break. That to me, seems like something that at the very least we should address by mentioning the limitations of Session Storage on this page, and by suggesting a perhaps less secure method for developers who need users to remain logged in if they open separate tabs.

@jmanico
Copy link
Member

jmanico commented Aug 4, 2024

I am convinced you are correct. But I would only advise the use of localStorage if the token has both idle and absolute timeout. Let me leave this open for now and I'll make a comment in ASVS and cross-reference this issue. I am with you now.

@Tib3rius
Copy link
Author

Tib3rius commented Aug 4, 2024

Thanks @jmanico! Appreciate the willingness to have the discussion, I agree localStorage with severe timeout restrictions seems like a good compromise. This is a problem with seemingly no "nice" solution.

@jmanico
Copy link
Member

jmanico commented Aug 7, 2024

One more note, this is how some folks deal with the sessionStorage issue:

In one application I use, the session token is indeed not shared across tabs. When you open a new tab with the application, you are redirected to the SSO provider and automatically logged in into the application. So while the application's token is stored in sessionStorage, it still works with multi-tab browsing because of the interaction with the SSO provider.

@ryarmst
Copy link

ryarmst commented Aug 26, 2024

Do you know of any modern app that actually stores them in Session Storage, and how that app maintains sessions with new tabs?

@Tib3rius I have encountered several apps that use Session Storage, but they do not maintain sessions in new tabs natively. Two of them are from personal use rather than testing, so I can share details. The first is the TD Bank's (Canadian bank) EasyWeb (online banking). This was actually the first app I encountered doing this and it was before I started working in security, so they've had it configured that way for some time now. It was definitely annoying from a usability perspective (before I was aware I could simply "duplicate tab") and customers regularly complain about this online. It seems that people have largely adapted to just using a single tab, which I assume was intended by the bank.

More recently, I've been using PlexTrac, which also uses Session Storage in this way. I thought I had actually seen user guidance to make use of "Duplicate Tab" in normal use, but I cannot find it now.

I am not saying this approach is preferred, just offering a couple examples of modern apps doing this ("modern" might be generous in the case of the bank...). Regarding built-in support for multi-tab, it looks like the Broadcast Channel API may be a way to share Session Storage data between tabs as necessary, but I am not sure if there are other implications.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ACK_WAITING Issue waiting acknowledgement from core team before to start the work to fix it. HELP_WANTED Issue for which help is wanted to do the job. UPDATE_CS Issue about the update/refactoring of a existing cheat sheet.
Projects
None yet
Development

No branches or pull requests

3 participants