📌
Software Security
  • README
  • Prerequisites
    • Prerequisites
  • Introduction
    • Cyber security principles
    • Basic web concepts
      • HTTP
      • JavaScript
      • Cookies
      • SQL
      • DOM
      • APIs and the multitier architecture
    • Basic browser security concepts
      • Same-Origin Policy (SOP)
      • Cross-Origin Resource Sharing (CORS)
      • Cookies
      • Tracking
    • Basic security concepts
      • Hashing
  • Access Control: Basics
    • Authentication
      • Passwords
      • Password managers
      • Attacking passwords - online
      • Attacking passwords - offline
    • Authorization
      • Insecure direct object references
    • Session Management
    • CSRF
      • CSRF: why & how it works
      • Protecting against CSRF attacks
    • SSRF
      • SSRF: how it works and how we can protect against it
  • Access Control: Advanced
    • Authentication
      • Federation
      • Alternative authentication mechanisms
      • FIDO2 and WebAuthn
  • Injection attacks
    • Injection attacks
    • SQL Injection
    • Command Injection
    • Cross-site scripting
      • Input validation
      • Context sensitive output encoding
      • About the HttpOnly flag
      • Content Security Policy
    • Subresource integrity
    • Sandboxing
  • HTTPS
    • HTTPS
    • Introduction to cryptography
    • PKI
    • Setting up HTTPS
    • References
  • HTTP Headers for security
    • HTTP Headers
  • Threat Modeling
    • Threat modeling introduction
    • Threat modeling basics
    • Inspiration for threats
  • Bringing it all together
    • A comprehensive overview of controls
Powered by GitBook
On this page
  • Session management - hijacking
  • Session identifier requirements
  • Source attribution

Was this helpful?

  1. Access Control: Basics

Session Management

PreviousInsecure direct object referencesNextCSRF

Last updated 3 years ago

Was this helpful?

Session management - hijacking

As covered in the section about and , the HTTP protocol is stateless. However, developers can implement session management capabilities into their application to tie HTTP requests and responses together in one single session.

Most often, this is done by setting a session cookie which contains a unique session identifier. When used in conjunction with access control, the session identifier binds the user authentication credentials to the user's HTTP traffic. This way, the application can not only tie HTTP sessions together, but it can also know which identity is executing the actions.

Common examples of session identifiers in cookies are cookies with the name JSESSIONID, PHPSESSIONID, or ASP.NET_SessionId

Session identifier requirements

The session identifier must be adequately protected to prevent an attacker from obtaining it and thereby 'hijacking' the session:

  • A session identifier should not be descriptive nor offer unnecessary details about the purpose and meaning of the ID

  • A session identifier should be long enough to prevent bruteforce attacks

  • A session identifier must be random enough to prevent guessing attacks

  • A session identifier must be meaningless to prevent information disclosure attacks

  • It is essential to use an encrypted HTTPS connection for the entire web session, to prevent the session identifier from leaking

  • The cookie containing the session identifier should be marked as 'secure' to prevent it from being transmitted over insecure HTTP connections

  • The cookie containing the session identifier should be marked as 'httponly' to not allow scripts access to it in the case of XSS (this cookie flag will be discussed in more detailed in the XSS chapter)

  • The cookie containing the session identifier may be marked as 'samesite', but be sure to understand the potential impact setting this flag may have (this cookie flag will be discussed in more detail in the CSRF chapter)

Most web development frameworks such as J2EE, ASP.NET, PHP, and other provide their own session management features and associated implementation. It is recommended to use these built-in frameworks versus building a home made one from scratch.

Source attribution

Some parts of this page are based on the by OWASP, which is licensed under .

http
cookies
Session Management Cheat Sheet
FLOSS