Assessing Session Management Mechanisms

This chapter covers techniques used to bypass and assess session management schemes. Session management schemes are used by applications to keep track of user activity, usually by means of session tokens. Web assessments of session management also involve determining the strength of the session tokens used and whether those tokens are properly protected. We will learn how to use Burp Suite to perform such tests.

In this chapter, we will cover the following recipes:

• Testing session token strength using Sequencer
• Testing for cookie attributes
• Testing for session fixation
• Testing for exposed session variables
• Testing for cross-site request forgery

Technical requirements

To complete the recipes in this chapter, you will need the following:

• An OWASP Broken Web Applications (BWA) VM
• OWASP Mutillidae link
• Burp Suite Proxy Community or Professional (https://portswigger.net/burp/)
• A Firefox browser or Burp Suite browser configured to allow Burp Suite to proxy traffic (https://www.mozilla.org/en-US/firefox/new/)

Testing session token strength using Sequencer

To track user activity from page to page within an application, developers create and assign unique session token values to each user. Most session token mechanisms include session IDs, hidden form fields, or cookies. Cookies are placed within the user’s browser on the client side.

These session tokens should be examined by a penetration tester to ensure their uniqueness, randomness, and cryptographic strength, to prevent information leakage.

If a session token value is easily guessable or remains unchanged after login, an attacker could apply (or fixate) a pre-known token value to a user. This is known as a session fixation attack. The purpose of the attack is to harvest sensitive data in the user’s account, since the session token is known to the attacker.

Getting ready

We’ll check the session tokens used in OWASP Mutillidae II to ensure they are created in a secure and unpredictable way. An attacker...

Testing for cookie attributes

Important user-specific information, such as session tokens, is often stored in cookies within the client browser. Due to their importance, cookies need to be protected from malicious attacks. This protection usually comes in the form of two flags—secure and HttpOnly.

The secure flag informs the browser to only send the cookie to the web server if the protocol is encrypted (for example, HTTPS or TLS). This flag protects the cookie from eavesdropping over unencrypted channels.

The HttpOnly flag instructs the browser to not allow access or manipulation of the cookie via JavaScript. This flag protects the cookie from cross-site scripting attacks.

Getting ready

Check the cookies used in the OWASP Mutillidae II application, to ensure the presence of protective flags. Since the Mutillidae application runs over an unencrypted channel (for example, HTTP), we can only check for the presence of the HttpOnly flag. Therefore, the secure flag is...

Testing for session fixation

Session tokens are assigned to users for tracking purposes. This means that when browsing an application as an unauthenticated user, they are assigned a unique session ID, which is usually stored in a cookie. Application developers should always create a new session token after the user logs in to the website. If this session token does not change, the application could be susceptible to a session fixation attack. It is the responsibility of web penetration testers to determine whether this token changes values from an unauthenticated state to an authenticated state.

Session fixation is present when application developers do not invalidate the unauthenticated session token, allowing the user to use the same one after authentication. This scenario allows an attacker with a stolen session token to masquerade as the user.

Getting ready

Using the OWASP Mutillidae II application and the Proxy | HTTP history tab in Burp Suite, as well as Comparer, we...

Testing for exposed session variables

Session variables such as tokens, cookies, or hidden form fields are used by application developers to send data between the client and the server. Since these variables are exposed on the client side, an attacker can manipulate them in an attempt to gain access to unauthorized data or to capture sensitive information.

Burp Suite’s Proxy option provides a feature to enhance the visibility of so-called hidden form fields. This feature allows web application penetration testers to determine the level of sensitivity of the data held in these variables. Likewise, a pentester can determine whether the manipulation of these values produces a different behavior in the application.

Getting ready

Using the OWASP Mutillidae II application and Burp Suite’s Unhide hidden form fields feature under Proxy, we’ll determine whether manipulation of a hidden form field value results in gaining access to unauthorized data.

How to do...

Testing for cross-site request forgery

Cross-Site Request Forgery (CSRF) is an attack that rides on an authenticated user’s session to allow an attacker to force the user to execute unwanted actions on the attacker’s behalf. The initial lure for this attack can be a phishing email or a malicious link executing through a cross-site scripting vulnerability found on the victim’s website. CSRF exploitation may lead to a data breach or even a full compromise of the web application.

Getting ready

Using the OWASP Mutillidae II application registration form, determine whether a CSRF attack is possible within the same browser (a different tab) while an authenticated user is logged in to the application.

How to do it...

To begin this recipe, let’s first baseline the current number of records in the account table and perform SQL injection to see this:

1. Navigate to the User Info page by going to OWASP 2013 | A1 - Injection (SQL) | SQLi - Extract Data...