Web Sessions

Dr. Greg M. Bernstein

October 20th, 2019

Sessions

References

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.

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.