A large number of web applications keep track of information about each user for the duration of the web transactions. Several web applications have the ability to establish variables such as access rights and localization settings. These variables apply to each and every interaction a user has with the web application for the duration of the session. For example, Figure 6-16 shows Wireshark being used to collect a packet capture of a web session to cnn.com. You can see the different elements of a web request (such as GET ) and the response. You can also see localization information (in this case, Raleigh, NC) in a cookie.
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, one-time password, client-based digital certificate, and so on.
NOTE A good resource that provides a lot of information about application authentication is the OWASP Authentication Cheat Sheet, available at *https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html*.
In order to keep the authenticated state and track users’ progress, applications provide users with a session ID, or token. This token is assigned at session creation time and is shared and exchanged by the user and the web application for the duration of the session. The session ID is a name/value pair.
There are multiple mechanisms available in HTTP to maintain session state within web applications, such as cookies (in the standard HTTP header), URL parameters and rewriting (defined in RFC 3986), and URL arguments on GET requests. Application developers also use body arguments on POST requests. For example, they can use hidden form fields (HTML forms) or proprietary HTTP headers.
One of the most widely used session ID exchange mechanisms is cookies. Cookies offer advanced capabilities that are not available in other methods.
The session ID names used by the most common web application development frameworks can be easily fingerprinted. For example, it is possible to easily fingerprint these development frameworks and languages by using the following session ID names:
TIP It is recommended to change the default session ID name of the web development framework to a generic name, such as id. The session ID must be long enough to prevent brute-force attacks. Sometimes developers set it to just a few bits, but the session ID must be at least 128 bits (16 bytes). Also, the session ID must be unique and unpredictable. It’s a good idea to use a cryptographically secure pseudorandom number generator (PRNG) because the session ID value must provide at least 256 bits of entropy.
Sometimes the session ID is included in the URL. This dangerous practice can lead to the manipulation of the ID or session fixation attacks.
Web development frameworks such as ASP.NET, PHP, and Ruby on Rails provide their own session management features and associated implementation.
NOTE It is recommended to use these built-in frameworks rather than build your own from scratch since they have been tested by many people. Unfortunately, when you perform pen testing, you are likely to find people trying to create their own frameworks.
This is pretty obvious, but you have to remember to encrypt an entire web session with HTTPS – not only for the authentication process where the user credentials are exchanged but also to ensure that the session ID is exchanged only through an encrypted channel. Using an encrypted communication channel also protects the session against some session fixation attacks, in which the attacker is able to intercept and manipulate the web traffic to inject (or fix) the session ID on the victim’s web browser.
There are two types of cookies: non-persistent (or session) cookies and persistent cookies. If a cookie has a Max-Age or Expires attribute, it is considered a persistent cookie and is stored on disk by the web browser until the expiration time.
Configuring a cookie with the HTTPOnly flag forces the web browser to have this cookie processed only by the server, and any attempt to access the cookie from client-based code or scripts is strictly forbidden. This protects against several type of attacks, including CSRF.