Skip to content

V3.2.3 - How do we define insecure methods for storage of session token? #553

Closed

Description

@securitybits

"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?

Activity

  1. added this to the 4.0 milestone on Feb 25, 2019
  2. mastacheata commented on Feb 25, 2019

    @mastacheata
    Contributor

    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.

  3. added a commit that references this issue on Feb 25, 2019
  4. tghosth commented on Feb 25, 2019

    @tghosth
    Collaborator

    @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.

  5. securitybits commented on Feb 26, 2019

    @securitybits
    Author

    @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

  6. vanderaj commented on Feb 26, 2019

    @vanderaj
    Member

    @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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    2) Awaiting responseAwaiting a response from the original poster

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions