Stream: smart
Topic: is it kosher to store `state` in a cookie during launch?
Isaac Vetter (Mar 19 2020 at 21:14):
The spec states that the state param presented by the app and returned by the AS during the /authorize step, prevents CSRF and session fixation.
The inherent risk of a (SameSite=Strict) cookie is that the user could change the value at any point, but this wouldn't enable CSRF. As long as the app wrote a new state value for every launch, it wouldn't be possible to fix the session before it started -- and even that's a very minimal risk.
Additionally, a SPA doesn't have any other choice than cookie or sessionStorage.
Isaac Vetter (Mar 19 2020 at 21:14):
Got this question -- can anyone confirm or deny my logic?
Josh Mandel (Mar 19 2020 at 22:54):
For a single-page app, state indeed needs to be stored somewhere. My recommendation is sessionStorage because it requires less cleanup and it's harder to goof with the same-origin poilcy.
Josh Mandel (Mar 19 2020 at 22:54):
But there may be other considerations here I haven't thought about.
Isaac Vetter (Mar 19 2020 at 23:54):
Thanks, Josh. For a multi-tabbed browser, the only functional difference between sessioStorage and a cookie is separation from other instances of the same app (domain). If the state is only used during the launch process, the only difference would be preventing two+ instances of the same app from session hijacking. This wouldn't occur during an ehr launch in practice (in which there's no auth page presented -- and therefore no real delay), but could occur during standalone launches.
I think that makes sense -- assuming a user-facing auth page during an ehr launch doesnt give the user the opportunity to relaunch the same app in a different context.
Jenni Syed (Mar 25 2020 at 02:21):
We've seen real life instances of apps being open for multiple patients stealing session storage from each other. Eg: embedded browsers share sessions.
Josh Mandel (Mar 25 2020 at 02:22):
Do you mean "stealing" maliciously, or somehow confusing?
Josh Mandel (Mar 25 2020 at 02:25):
If I remember correctly, I think Cerner saw some kind of shared access happening across sessions in its embedded browser environment? (It's not something that should be possible in browsers that are correctly implementing sessionStorage APIs.)
Isaac Vetter (Mar 25 2020 at 04:21):
Hey guys, I think Jenni means "confusing". I've already incorporated this consideration in my remarks, above.
Here's the details of sessionstorage in a single threaded windows exe with multiple browser controls: https://github.com/cerner/fhir-client-cerner-additions/blob/master/README.md
Last updated: Apr 12 2022 at 19:14 UTC
