Session Cookies and Security

Because HTTP is a connectionless protocol, it does not require web servers to retain information on users for a session over multiple requests. To bridge this functionality gap, session cookies or hidden form variables are used to track users and continue a session past the original HTTP request. Whereas long random strings can be identifiers of various tracking systems (including web analytics applications), user sessions for applications are often held with one of a variety of language-integrated cookies  – JSESSION, PHPSESSID, and so on. By being able to compromise one of these cookies, you can establish yourself to the server as the original user and access their account. So, although some cookies can be useful and sensitive, I'll focus exclusively on session cookies.

From a security perspective, three fields in cookies have high-risk potential. The first, the Secure flag, which dictates whether the server/browser should send the cookie in cleartext (HTTP) or encryption (HTTPS), must be used. If the Secure flag is set, the cookie will only be sent by the browser (and returned by the web server) if the session is encrypted. If an HTTP request is sent by the browser, the cookie will not be returned. Although this isn't a security necessity for all cookies, session cookies should always include a Secure flag to prevent compromise of this sensitive data. As with all cleartext protocols, attackers could sniff HTTP packets if they're on the same network as the victim (or between the victim and web server).

To identify this flaw in your own application, you can use Cookie+ (in Tools  | Cookie Manager+ ) to locate a cookie and see its details. Figure 6 shows an example of a JSESSION cookie (from a Fortune 500 firm) issued from the web server without a Secure flag.

Figure 6: Session cookie Secure flag.

The next piece to look at is the HttpOnly field, which specifies whether the cookie can be read by client-side code, such as JavaScript. There are legitimate web uses for this functionality, but it increases the risk of a successful cross-site scripting attack, allowing an attacker's malicious client-side code to access the victim's sensitive cookies. Unlike the Secure flag, which is a tradeoff between client speed and security, the HttpOnly flag should always be enabled unless it needs to be disabled for functionality. In Figure 7, there is no HttpOnly flag for the example session cookie.

Figure 7: Session Cookie HttpOnly flag.

In addition to the Secure Flag and HttpOnly flag, a session token's expiration has a significant effect on its security. Cookies can be set to expire either at the end of the session (when the user leaves the page) or on a given date set by the server. Expiring cookies at the conclusion of a user session is the most secure option, but many sites provide (either by default or by option) a "stay logged in" functionality that extends cookie expiration anywhere from a few days to a few weeks (Figure 8).

Figure 8: Session cookie expiration setting.

In this case, however, the cookie expiration isn't for a year after the first login – meaning if the cookie is accessed (through XSS, network sniffing, or system compromise), the attacker can still use the session months afterward.

Brute Forcing

Although the security concerns of session cookies can be of significant consequence, they're also technically easy to identify. Leveraging some of the features of Burp Suite, I'll look at brute forcing login forms, how to bypass basic technical controls, and explain how to remediate the issue on the server.

Brute force vulnerabilities, unlike many security issues, do not rely on a misconfiguration or missing patch to exploit, but simply a lack of checking for user logins in the login code. This common issue can be conceptually tested by entering a given username with a host of passwords, but that approach does not scale well – entering hundreds or thousands of passwords manually is slow, tedious, and prone to errors.

Using Burp Suite to automate the process, the first step is to configure the browser for your local proxy (right-click on the FoxyProxy icon), turn off the Burp Proxy intercept function (which can be verbose), and log in with test credentials through the browser. This ensures that the correct HTTP syntax was sent for the application and is captured by the proxy for a modified replay later. With the credentials submitted to the target login, look for the correct packet (presumably a POST) with the credentials in it. There's likely to be several requests for JavaScript, JSON, fonts, CSS, and others, but these do not affect the login functionality and are unnecessary for your needs. Once you've identified the login packet (Figure 9), right-click and send it to the Burp Intruder (Figure  10).

Figure 9: Login parameters for brute forcing.

Figure 10: Intruder with username/password selected.

Once in, press Clear  § , select the password to be changed, and click Add  § to select. This sets the highlighted portion to change per the payloads given in the next section (in this case, a list of passwords to test for authentication). I'll use the Sniper attack type, which simply iterates through each payload for the single payload position. Port Swigger has an excellent description of other attack types [4].

Note that in my example, the credentials are sent in a GET parameter. This creates another vulnerability in itself, because URLs are often stored in proxies, used in the Referrer parameter, and stored in other places inappropriate for providing credentials.

In the payloads section, you can select the payload type (in this case, simple list ) and enter your list of payloads in the section below. You'll be entering a selection of passwords to test for the given account, and leaving the rest of the settings as the default. Once configured, select the Intruder tab and click Start Attack . A new dialog box will pop up, and the attack will automatically begin, albeit with only one thread (which is a limitation of the free version).

Using the auto-populating table, you can identify the request, the password tested, the status code (200 is HTTP code for OK), and the length of the packet. Although the given "baseline request" may not be a good baseline (e.g., because of error messages for a null password), the first password that has a "successful" response (no errors in HTML, bad HTTP codes, or other problems) should be used as a packet length baseline.

For all packets thereafter, look for deviations in the packet length. Any changes in response size likely indicate either a lockout/error or a successful login with the given credentials. Any status code changes (e.g., from 200 to 404) could indicate a blocked IP, account, or similar defensive mechanism in place.

Token Randomization Testing – Burp Sequencing

In regard to testing session tokens, occasionally developers (particularly in mobile/desktop applications) will opt to build a homegrown token rather than using a thoroughly tested library, such as the uuid library in Python, PHPSESSID in PHP, and ASP.NET_SessionId in ASP .Net.

However, you should always opt for a secure session token rather than developing the module in-house – it's faster, more secure, and custom development is completely unnecessary. Despite all this, custom session tokens are still regularly developed and often easily exploitable.

To begin testing session token randomization, you need to find where the session began to collect those tokens. This session cookie is typically issued at either the first page the client browses or the first page after authentication. In the case here, the site issues the cookie (PHPSESSID) at the user's first page request (Figure 11).

Figure 11: Session cookie and associated value.

With this packet captured in the Proxy, click the Action button and send to the Sequencer. In the Sequencer tab, you'll see the HTTP request captured, with various cookie and form fields selected as being the token location. Select the appropriate value (Figure 12) and start the live capture of cookies.

Figure 12: Session cookie within Burp Sequencer.

Once live capture has started, a new window will open, collecting and analyzing the randomness of the given value. If all the previous steps were done correctly, the number of requests and tokens (Figure 13) should be the same, indicating a unique session issued for each request.

Figure 13: The number of requests and tokens should be the same.

Analysis can begin at a minimum of 100 tokens, but the "Auto analyze" option will update the analysis section every 100 tokens, as they are acquired. In the example (testing the PHPSESSID), the effective entropy is 117 bits, which Burp Suite rates as excellent for randomness. Additional tabs within Intruder can provide further information on the tests performed, entropy for each bit in the token, and the token's performance on each test (which helps in reverse-engineering the process and thereby predicting future tokens).

Another function of the Sequencer is being able to add tokens manually and have them analyzed. "Randomly" generating my own tokens using some quick notepad calculations [5], I can see the tokens are not in an immediately predictable format (Figure 14). Nevertheless, they are rated very poor by the Sequencer (Figure 15). Without going too far into the Sequencing tests, this result demonstrates that even tokens that appear random can have flaws in their random number generation and therefore be predictable.

Figure 14: List of manually generated cookies.

Figure 15: Sequencer analysis of manually generated cookies.

If a predictable (low-entropy) session cookie is identified, exploitation is relatively simple, allowing an attacker to hijack any account that connects to the web service. As with the token collection for sequencing, you simply need to collect the given session IDs, use the identified algorithm to highlight missing values, and change a browser session to the given token to hijack the given account.