Session Management
This checklist is designed to ensure that user sessions on a website are secure. It includes a series of steps and best practices for protecting user data and preventing unauthorized access.
🔨 Session Creation
| #️⃣ |
✅Items |
⚠️Severity |
💀Vulnerabilities |
🔗Sources |
| 1 |
Verify: Change the default session ID name set by the framework to a generic name as 'id' Reason: Session ID name can disclose information about the application's framework and language being used |
Low |
Information Leakage |
SMCS |
| 2 |
Verify: The session ID must be at least 128 bits or 16 characters long Reason: Provides enough entropy to make guessing challenging |
Medium |
Brute Force |
SMCS |
| 3 |
Verify: The session ID name is meaningless, meaning it doesn't reveal any information about the app or the user Reason: Prevent sensitive information from leaking |
Low |
Information Leakage |
SMCS, SP800-63B |
| 4 |
Verify: The session ID has an entropy of at least 64 bits Reason: Minimum randomness that makes guessing challenging |
Medium |
Brute Force |
SMCS, ASVS, SP800-63B |
| 5 |
Verify: The session ID is generated by using cryptographically secure random function Reason: Ensure that the ID value is random and cannot be predicted |
High |
Brute Force |
SMCS, ASVS, SP800-63B |
| 6 |
Verify: The session ID is unique for each user Reason: Prevent users from accessing someone else's account |
High |
Impersonation |
NIST |
| 7 |
Verify: The session mechanism provided by a modern framework is being used Reason: Custom session mechanisms aren't thoroughly tested and may contain vulnerabilities |
High |
Roll Your Own Code |
SMCS |
| 8 |
Verify: If an older version of a framework is being used, ensure that session mechanism isn't vulnerable Reason: An attacker can compromise your session by using the publicly available vulnerability |
High |
Vulnerable Dependency |
SMCS |
📦 Session Storage
| #️⃣ |
✅Items |
⚠️Severity |
💀Vulnerabilities |
🔗Sources |
| 1 |
Verify: Secure attribute is enabled for cookies Reason: Instructs the browser to send cookies through HTTPS |
High |
Eavesdropping xxxxxxxxxx |
SMCS, ASVS, SP800-63B |
| 2 |
Verify: HttpOnly attribute is enabled for cookies Reason: Instructs web browsers not to allow scripts to prevent XSS |
High |
Injection, Credential Theft |
SMCS, ASVS, SP800-63B |
| 3 |
Verify: SameSite attribute is enabled for cookies Reason: Instructs web browsers to only send the cookie to the specified domain and all subdomains |
Medium |
Cross-Site Request Forgery |
SMCS, ASVS |
| 4 |
Verify: If Domain cookie attribute exists, ensure that the domain value is not too permissive Reason: Ensures that cookies are only shared with the domain provided. Vulnerabilities in example.com might allow an attacker to get access to the session IDs from secure.example.com |
Medium |
Session Hijacking |
SMCS, ASVS |
| 5 |
Verify: If Path cookie attribute exists, ensure it is as restrictive as possible to the application that makes use of the session ID Reason: If the path is generic such as /, then there's a chance that important cookie, such as session ID, will be accessible throughout the site |
Medium |
Credential Theft |
SMCS, ASVS |
| 6 |
Verify: If Expires and Max-Age attributes are used, a short expiration time is set to prevent long persistent cookies Reason: Persistent cookies will outlive the close browser event. It is highly recommended to use non-persistent cookies for session management purposes so that the session ID does not remain on the web client cache for long periods, from where an attacker can obtain it |
Medium |
Credential Theft |
SMCS, ASVS |
| 7 |
Verify: The session ID is not stored in local storage Reason: Local storage is insecure as it doesn't have protection against XSS attacks, and it's value is persistent unless changed manually in code |
High |
Injection, Credential Theft |
SMCS |
| 8 |
Verify: The session ID is not stored in session storage Reason: Session storage data is persistent unless the tab or window is closed, and it is vulnerable to XSS |
High |
Injection, Credential Theft |
SMCS |
| 9 |
Verify: Ensure that session ID is not cached in browser Reason: If logged in device is stolen or left unattended, someone else can have access to that account |
Low |
Credential Theft |
SMCS |
| 10 |
Verify: Session data is stored server side by using secure encryption and hashing algorithms Reason: Provides additional security incase of a database compromise |
High |
Credential Theft |
SMCS |
🗑️ Session Expiration
| #️⃣ |
✅Items |
⚠️Severity |
💀Vulnerabilities |
🔗Sources |
| 1 |
Verify: Session expires after a period of inactivity Reason: Limits the time an attacker has to guess a session ID |
High |
Session Hijacking |
SMCS, ASVS, SP800-63B |
| 2 |
Verify: Expired session ID is no longer active Reason: This ensures that incase an older session ID is stolen, it won't be of use |
High |
Session Hijacking |
SMCS, ASVS, SP800-63B |
| 3 |
Verify: When the user clicks the logout button, the session is invalidated, and the user is asked to login Reason: This ensures that an account is not accessible after a logout attempt |
High |
Impersonation |
SMCS, ASVS, SP800-63B |
| 4 |
Verify: Allow the user to invalidate sessions on different devices Reason: A stolen or old device doesn't give access to someone else |
Medium |
Impersonation |
SMCS, ASVS |
| 5 |
Verify: An application should have an absolute timeout after which a user is required to login regardless of their activity/inactivity Reason: Additional security measure to ensure that session IDs are being refreshed |
Low |
Session Hijacking |
SMCS |
| 6 |
Verify: Timeout functionality isn't client based Reason: An attacker is not able to manipulate the current time and continue their session for longer than intended |
Low |
Session Hijacking |
SMCS |
| 7 |
Verify: Session ID renewable process exists regardless of idle timeouts Reason: This limits the amount of time a hacker can have access to a hijacked session |
Low |
Session Hijacking |
SMCS |
📋 Session Policies
| #️⃣ |
✅Items |
⚠️Severity |
💀Vulnerabilities |
🔗Sources |
| 1 |
Verify: Session related events are logged such as creation, renewable, and destruction Reason: Helps in detecting and investigating security incidences |
High |
Insufficient Logging |
SMCS, ASVS |
| 2 |
Verify: The session ID is never trusted and is always validated for malicious input before processing it Reason: Protection against injection and denial of service attacks |
High |
Denial of Service, Injection |
SMCS |
| 3 |
Verify: Session ID exchange takes place over TLS (HTTPS) Reason: Encrypted channel that prevent eavesdropping |
High |
Eavesdropping |
SMCS, ASVS, SP800-63B |
| 4 |
Verify: Rate-limiting mechanisms exist on the session ID Reason: Prevention against guessing and Denial of Service (DoS) |
Medium |
Denial of Service, Brute Force |
⛔ |
| 5 |
Verify: If a library is used for session management, ensure it is not misconfigured Reason: Default configurations or misconfigurations can grant unauthorized access to an attacker |
High |
Misconfiguration |
⛔ |
| 6 |
Verify: Libraries used for session management are not vulnerable Reason: An attacker can use the vulnerable library to escalate their privileges |
High |
Vulnerable Dependency |
⛔ |
| 7 |
Verify: The application never reveals session ID in URL parameters or error messages Reason: An attacker can steal this information and hijack someone's session |
Medium |
Information Leakage |
ASVS |
| 8 |
Verify: A new session is generated when privileges change or sensitive features are performed, such as resetting passwords Reason: Added security in case current session was hijacked |
Medium |
Impersonation |
SMCS, ASVS |
| 9 |
Verify: The user is notified when a new session is generated from a new device or location Reason: In case an unwanted login occurs from another device or a location, the user knows |
Medium |
Impersonation |
⛔ |
🔴 Session in Production
| #️⃣ |
✅Items |
⚠️Severity |
💀Vulnerabilities |
🔗Sources |
| 1 |
Verify: There's a process for invalidating sessions in the event of a security breach Reason: Prevent an attacker from having prolonged access |
High |
Session Hijacking |
⛔ |
| 2 |
Verify: Audit logs are monitored regularly for anomalies Reason: Identify attacks that were attempted on a user's account |
High |
Session Hijacking |
⛔ |
| 3 |
Verify: Third party software or libraries used for session management are updated to the most recent version and are regularly patched Reason: Vulnerability in a third party resource can grant an attacker unauthorized access |
High |
Session Hijacking, Vulnerable Dependency |
⛔ |
| 4 |
Verify: Conduct regular security assessments, vulnerability scans, and penetration testing to identify vulnerabilities in custom and third-party code Reason: Identify any security vulnerabilities that might have appeared in session implementation |
High |
Session Hijacking |
⛔ |
🔗 Sources:
Open Web Application Security Project (OWASP):
National Institute of Standards and Technology (NIST):