session

  • session hijacking
    • anti-pattern: session id in plain text
    • ref: cross site scripting (XSS)
  • session fixation (hacker creates valid session, and tries to get the target to use it)
    • Anti-pattern: authenticating an existing session
    • pattern: generate a new session ID when (re)authenticating
  • session prediction
    • Anti-pattern: session IDs based on user’s own data
    • Anti-pattern: sequential session ids
just because a session looks random, does not mean it is random

guidelines for handling session IDs ./resources/owasp-broken-authentication-and-session-management.resources/img_20220908_150933.jpeg pattern: long session ID with lots of entropy pattern: session id from random with cryptographic properties anti-pattern: session id from language’s built-in random function pattern: protect against XSS pattern: generate a new session ID when (re)authenticating pattern: use up-to-date platform session management pattern: use ONLY cookies to exchange session IDs (disable all other ways) anti-pattern: accept session IDs via query parameters

exercise: write a cURL command for a TLS-secured call to a development server using a self-signed certificate

Antipattern Metaphor: pie-crust defense

You had to authenticate to cross a boundary,
but services inside the "pie" could call each other freely

./resources/owasp-broken-authentication-and-session-management.resources/img_20220908_152511.jpeg

Authentication options:

  • first-party (build it yourself)
  • third-party (eg. Kerberos, NTLM, Oauth)

(src: