Web Sessions
Dr. Greg M. Bernstein
Updated October 19th, 2021
Sessions
References
- Session Management Cheat Sheet. Introduction provides clear definition and need for sessions and security issues.
What is a Web Session?
From OWASP:
A web session is a sequence of network HTTP request and response transactions associated with the same user. Modern and complex web applications require the retaining of information or status about each user for the duration of multiple HTTP requests.
Sessions provide the ability to establish variables – such as access rights and localization settings – which will apply to each and every interaction a user has with the web application for the duration of the session.
Sessions and State
HTTP is a stateless protocol, each request/response is independent of the one that came before it from the point of HTTP.
A Web application may need to keep state about a user such as preferences, login status, privileges, shopping carts, etc…
We have seen that cookies provide one way of keeping application state between subsequent requests to the same site.
Who Stores State?
Could make client store state by putting all relevant state information into a cookie or similar mechanism. If there is a significant amount of state this method can be quite inefficient.
Could have server store state and identify that state with a unique session identifier that the server uses to look up application state. Such a session identifier can be kept in a cookie. This is much more efficient when there is a lot of state. This is the approach we will take in this class.
Sessions and Access Control
From OWASP:
Web applications can create sessions to keep track of anonymous users after the very first user request. An example would be maintaining the user language preference. Additionally, web applications will make use of sessions once the user has authenticated. This ensures the ability to identify the user on any subsequent requests as well as being able to apply security access controls, authorized access to the user private data, and to increase the usability of the application.
Access Control Approaches
Authenticate Every Request, used in many APIs, not appropriate in UIs.
Establish a server based session tied to a session ID that lasts a given period of time or other criteria. This class
Keep credentials in a secure JWT (JSON Web Token)
Danger!
From OWASP:
Once an authenticated session has been established, the session ID (or token) is temporarily equivalent to the strongest authentication method used by the application, such as username and password, passphrases, one-time passwords, client-based digital certificates, smartcards, or biometrics.
Session Implementation
Server Responsibilities
Maintain the session data store and session ids:
- Generate session ids and session state for new site visitors
- Retrieve session state based on session id from session storage and deliver it to the server application for use.
- Remove session state and “retire” session id when sessions end.
- Ensure security of session ids
Server Session Diagram
Sessions and Cookies I
The server will keep state about a session, i.e., a set of interactions with a client.
This state will be associated with a session id that the server will set in a cookie.
The cookie with the session id gets sent from the client to the server with every subsequent request.
Sessions and Cookies II
Session information can include: user preferences, login status, permissions, shopping carts, etc.
Session information is not kept in the cookie! Only the session id.
The server will have a data store to map session ids to session state.
Club Example: Session State
Simplest Login example
- Initial state for visitor:
{loggedin: false}- After login:
{loggedin: true, firstName: "Dr", lastName: "B",
email: "db@whatever.com"}Sequence Charts
Message Sequence Charts of various types have been used in software and protocol specifications. Though often overly formal they can be very handy.
Used Sequence Diagram.org to construct the sequence diagrams used in this lecture.
Initial Visit
Unauthorized Access to User List
Logon
Authorized Access to User List
Protecting Sessions
Session Attacks
From OWASP
The disclosure, capture, prediction, brute force, or fixation of the session ID will lead to session hijacking (or sidejacking) attacks, where an attacker is able to fully impersonate a victim user in the web application.
Session IDs
From OWASP
In order to keep the authenticated state and track the users progress within the web application, applications provide users with a session identifier (session ID or token) that is assigned at session creation time, and is shared and exchanged by the user and the web application for the duration of the session (it is sent on every HTTP request).
Session ID Recommendations
- Length: must be long enough to prevent brute force attacks, current recommendations are for 16 bytes or more.
- Entropy: the session ID must be unpredictable (random enough) to prevent guessing attacks; We will use cryptographically strong random numbers.
- Content : must be meaningless to prevent information disclosure attacks
Session ID Fingerprinting
- Session ID are passed in the form of “name=value” pairs
- The names given by popular web frameworks are well known
- The detection of one of these names gives an attacker additional information
- Change the default names used by your framework (if possible)
Session ID Transport: Cookies
- We will use HTTP cookies to transport our session IDs between client and server.
- In any deployment you MUST use HTTPS to prevent disclosure of session IDs as they are carried across the network.
Recommended Cookie Attributes 1
- secure: Browser will only send cookie over an HTTPS channel (not HTTP)
- HttpOnly: The browser will not let JavaScript access the cookie, this helps prevent XSS attacks
- SameSite: makes it impossible for the browser send this cookie along with cross-site requests
Recommended Cookie Attributes 2
domain and path: Use a narrow or restricted scope for these two attributes, e.g., the “Domain” attribute should not be set (restricting the cookie just to the origin server) and the “Path” attribute should be set as restrictive as possible to the web application path that makes use of the session ID.
expire and max-age: Note that with many browsers providing “session restore” the advice to use “session” cookies is somewhat dated. We will want to make sure that cookies disappear from the browser in some fashion
Session ID Lifecycle
Generation and Verification
From OWASP
Web applications should never accept a session ID they have never generated, and in case of receiving one, they should generate and offer the user a new valid session ID. Additionally, this scenario should be detected as a suspicious activity and an alert should be generated.
Manage Session ID as Any Other User Input
From OWASP
Session IDs must be considered untrusted, as any other user input processed by the web application, and they must be thoroughly validated and verified.
Renew the Session ID After Any Privilege Level Change
From OWASP
The session ID must be renewed or regenerated by the web application after any privilege level change within the associated user session. The most common scenario where the session ID regeneration is mandatory is during the authentication process, as the privilege level of the user changes from the unauthenticated (or anonymous) state to the authenticated state.
Session Expiration
From OWASP
In order to minimize the time period an attacker can launch attacks over active sessions and hijack them, it is mandatory to set expiration timeouts for every session, establishing the amount of time a session will remain active.