You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
V3.2.3 - How do we define insecure methods for storage of session token? #553
"Verify the application does not store session tokens using insecure methods such as HTML 5 local storage."
What do we mean by insecure methods here, do we mean methods that will persist the session token beyond the current browsing session? Would a persistent cookie also be treated as failing this, whereas a non-persistent cookie and sessionStorage would be seen as compliant? Or is it something else?
Cookies, regardless of lifetime are only OK when using the HttpOnly flag as per the Standard.
If you take that requirement and apply that to other storage, both local and session storage must be disallowed as they're always accessible from client-side scripting.
@mastacheata I think the point is that cookies should always have HttpOnly but if you have a Single Page App or something where the session token is added as a header then in that case it is ok to store in session storage.
@tghosth I will accept this merge as closing this issue. I think it makes it clearer, whilst also permitting some latitude for storing bearer tokens for API calls in a safer location.
Activity
mastacheata commentedon Feb 25, 2019
Cookies, regardless of lifetime are only OK when using the HttpOnly flag as per the Standard.
If you take that requirement and apply that to other storage, both local and session storage must be disallowed as they're always accessible from client-side scripting.
Update 0x12-V3-Session-management.md
tghosth commentedon Feb 25, 2019
@securitybits Let me know what you think about #562
@mastacheata I think the point is that cookies should always have HttpOnly but if you have a Single Page App or something where the session token is added as a header then in that case it is ok to store in session storage.
securitybits commentedon Feb 26, 2019
@tghosth I think the edits look good and agree with you regarding session storage being an acceptable option.
@mastacheata I think it's misleading to suggest that the HttpOnly flag would be a deciding factor for securing a session token. While it's a good practice for cookies that don't need to be accessible client-side, it doesn't really do much in way of preventing an XSS attack from abusing your session and it's been know for long time, e.g., see https://www.gnucitizen.org/blog/why-httponly-wont-protect-you/ and https://portswigger.net/blog/web-storage-the-lesser-evil-for-session-tokens
vanderaj commentedon Feb 26, 2019
@tghosth I will accept this merge as closing this issue. I think it makes it clearer, whilst also permitting some latitude for storing bearer tokens for API calls in a safer location.
Replace Docker-based action with direct markdown-link-check invocation
Replace deprecated URL checker action with direct invocation (#3332)
Backport markdown link checker improvements (#3371)