On Patrol

Many automated web security tools are available in the market today, but even the best of these tools have limitations. Many web vulnerabilities are difficult – or even impossible – to detect without human interaction. Some of the best tools for web security analysis take the form of a browser (with a few simple add-ons) and an attack proxy. This article describes how attack proxies work and shows how to look for web vulnerabilities using the popular attack proxy Burp Suite.

Attack proxies vary in functionality, price, and reliability, so for consistency, I'll use Burp Suite throughout these examples. Burp Suite includes a tool for intercepting traffic (the "proxy" module itself), as well as modules for spidering sites, repeating and manipulating individual requests, sequencing random values, decoding traffic, and more. Each of these components provides unique insight into the application's functionality and security ramifications, but all require an intelligent person to decode the results.

Installation and Configuration

After you download the free edition of Burp Suite [1], simply double-click the .jar file to run the file. Once the application is running, click Proxy  | Options, and check the Proxy Listeners Section (Figure 1) to identify the IP Address and port the proxy is listening on. The default port is 127.0.0.1:8080.

For the rest of the exercise, you'll need a browser (Firefox), two Firefox extensions (Cookies Manager+ [2] and FoxyProxy Standard [3]), and Burp Suite for the testing. Once these tools are installed, you should see a new icon to the right of the URL bar, indicating the status of the Firefox proxy. Similarly, you can access Cookies Manager+ in the Tools bar, which lets you easily identify cookies, values, and associated data. With Burp running and browser extensions installed, right-click the FoxyProxy icon (in red), click the Options tab, then select Add New Proxy (Figure  2).

Using the data from the Burp proxy, insert the IP address and port for a new proxy configuration, type in a proxy name, and click Accept. Once back on the main browser page, right-click on the FoxyProxy icon to cycle through proxy configurations and enable the newly created proxy. In testing the new settings, type in a URL and verify that the proxy is intercepting the request, as shown in Figure 3.

Burp Suite Basics

Once you have Burp Suite installed and configured, take a moment to look around. The most common and basic function is the proxy, which allows you to intercept HTTP(S) requests from the browser to the site you are testing. As packets are intercepted, you can modify parameters, cookies, and other data, and you can filter packets within the proxy to include or exclude similar packets (Figure 4).

The Spider tab allows for the spidering of sites through link identification and scraping of pages in the Robots.txt file. Spidering is a vital piece of any security assessment, because it can yield administrative access pages, test functions, or other pages that were not intended to be published. Similar to the Spidering tab is the Target tab, which allows whitelisting and blacklisting of pages within the target scope, as well as viewing of spidered pages in the site map (Figure 5).

Describing the scope properly makes it easier to identify rogue pages and helps you better isolate useful pages in other areas of Burp Suite. Nearly all modules support isolating analyzed sessions to those in the target scope.

The Intruder section lets you set any values within an HTTP request as insertion points for a given variable. Although this sounds like a cryptic definition, it's easily understood with a basic example. Using the default sample, the URL /example?p1=aaal is sent, with a single GET parameter.

By setting the parameter as an insertion point for security testing, you can replace the aaa value with a variety of payloads, including dates, numbers, passwords, filenames, or a custom list of user-defined values. Because it can fuzz parameters, brute force usernames and passwords, and be used for a number of other security tests, the Intruder section is the Swiss army knife of the Burp Suite toolset, providing a wide range of possibilities.

The Repeater tab provides an easy interface to craft custom requests, as well as identify consistency issues within the application. Often, I prefer this module to verify time-based SQL injection vulnerabilities, which testing tools often find as false positives.

Next, the Sequencer tab collects and analyzes tokens for randomness and predictability – a significant vulnerability if not securely random. This information is used by identifying in the Proxy history the page where a session token is issued and sending it to the Sequencer for live capture of tokens. Once the session value is identified (similar to creating an Insertion Point in the Intruder), start the live capture and begin collecting session cookies. Once 100 of these have been collected, the randomness testing can begin, and results are displayed as more values are collected for a more thorough analysis. This explanation doesn't fully cover the process, but it will be further explained as I describe a real attack process.

Vulnerability Identification

With the basics of Burp Suite explained, I'll focus more on using these tools to identify flaws in your web infrastructure. To begin, I'll analyze cookie security misconfigurations, particularly relating to the Secure and HttpOnly flags on web applications. I'll use the aforementioned Burp Intruder to attack login forms and brute force valid accounts and then test the randomness of session cookies with the Sequencer. All of these steps will be performed using only a web browser and the free edition of Burp Suite.

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.

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.

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).

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).

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).

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.

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.

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.

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.

Conclusion

In this article, I looked at the basics of attack proxies (Burp Suite in particular), looked at the security of cookies and the various security-related fields they can have, performed brute forcing against the target application, and ran through a randomness test for the session tokens used in the application.

Although this article is designed to help developers and security technicians test for a few basic web flaws, it's not intended to be a comprehensive walkthrough of Burp Suite or a replacement for a professional security assessment.