Assessing Web App Security with Mozilla

Web application assessment is a challenging task for security analysts. Several products and tools are available, each claiming to perform automated analysis on entire applications. Their capabilities include obtaining data, corroborating it, and printing aesthetically appealing reports--all without user intervention.

The nature of web applications is very different from that of standard applications. Many times, these tools miss key vulnerabilities in the application. The best way to perform web application assessment is by using the unassailable combination of automated tools and human intellect. This article examines the LiveHTTPHeaders project, which fits seamlessly into Mozilla browser components to facilitate very effective web application assessment.

Application Assessment Challenges

To perform web application assessment, you need strong HTTP (Hypertext Transfer Protocol) skills--a comprehensive knowledge of how clients and servers communicate over the Web. A web application talks to the client (the web browser) with the HTTP protocol only, with or without SSL support enabled. The HTTP protocol has two parts, the header and the body (or content). Essentially, the header contains key information about the message, which helps servers and clients understand each other. The body of the HTTP contains an HTML block that the browser renders. Assessing a web application involves two tasks:

Performing in-depth HTTP analysis that entails understanding the entire communication sequence between the application and client. Deriving various clues and information about the application from HTTP headers is the next important step.

Manipulating HTTP requests in order to explore both known and as-yet-unearthed web application vulnerabilities necessitates changing HTTP header values and scrutinizing application behavior.

The W3C web site hosts RFC 2616, a complete description of the headers in HTTP/1.1.

Solution to Combat Challenges

The HTTP protocol runs with or without SSL. A level of difficulty in reverse-engineering protocols crops in when HTTP traffic travels over secure channels. There are a couple of ways to solve this:

Sniffing the wire--It is possible to sniff traffic that travels over HTTP ports (80, 443) and collect logs of requests and responses. Your sniffing tool needs SSL sniffing capabilities to monitor SSL requests. It is possible to reproduce similar requests and send these requests back on the wire after manipulation, though not without some difficulty.

HTTP proxy as man-in-the-middle--Existing HTTP/TCP listeners and port-forwarding utilities can act as man-in-the-middle agents, and all HTTP traffic must pass through these agents. In such a situation, HTTP traffic is visible, and the utility can manipulate it as well. One such proxy tool, called Paros, is great for analyzing HTTP and HTTPS communication between server and client.

Those are both complex. Is there a better way to achieve the same objective? Very definitely yes. The answer lies in browser plugins, extensions that add features to a web browser. Mozilla has an extension called LiveHTTPHeaders that can help with web application assessment.

Leveraging LiveHTTPHeaders with Mozilla

This tool can perform HTTP protocol sniffing and analysis, as well as HTTP protocol manipulation.

Installing LiveHTTPHeaders in your Mozilla

Installing LiveHTTPHeaders is a very simple task. Presently, the only supported browsers for this application are Mozilla, Firefox, Netscape, and Phoenix.

After the extension is installed in your browser (and you've restarted the browser), you can start using it immediately without post-installation configuration hassles. For example, when you have installed the extension as a plugin for Firefox, go to Tools in the main menu options and select "Live HTTP headers." A window (see Figure 1) will open.

Figure 1. LiveHTTPHeaders' front-end GUI

You can make certain configuration settings, but the most critical ones are those that affect all incoming and outgoing HTTP header information for web applications. This can be very useful in application assessment.

HTTP protocol sniffing and analysis with LiveHTTPHeaders

Assume that you have a web store at http://webshop.example.com and you want to carry out HTTP analysis on this web application. Consider what happens when you browse to the URL http://webshop.example.com. This is the HTTP request that elicits an HTTP response from the web server. Figure 2 shows this HTTP request and response in LiveHTTPHeaders.

Figure 2. Calling the HTTP GET method

The browser makes an HTTP GET request of the web server, which responds with an HTTP response. Scrutinize the response, and you'll see that it includes key information such as the web server that is running and the session cookie provided to the client. These directives expose this information:

The application also has an HTML form where you can select quantities for products. To see what kind of HTTP request goes across, you could place an order. Figure 3 shows an example of product presentation.

Figure 3. Product presentation for an iPod

When you fill in the required quantity on the form and click on the "Add to cart" button, the browser processes the form:

After processing this request, the form browser sends the HTTP request. Figure 4 illustrates the HTTP POST request as it travels over the wire.

Figure 4. POSTing to the server

The browser takes the quantity value of the form and generates a POST request on the wire with HTTP headers and Content-Length=15. As far as POSTed bytes in the HTTP headers go, the browser has sent 15 characters. In this example, that data is id=1&quantity=1.

You can observe both HTTP GET and POST requests going to and from the browser. Keep browsing and you will be able to view all the requests that the utility generates and captures. You can discover many pieces of security-related information:

Session- and application-level cookies going back and forth between the web browser and the web application.

Hidden variables passed from the web browser to the web application via forms. This is present only in HTTP POST requests.

Actual HTTP response code and redirect information.

Any Referer directive going from the web browser to the web application and any decision taken on the basis of this directive.

Complete HTTP communication tracing between browser and client, with or without SSL.

This is a great wealth of information! With this data about HTTP in place, the next step is to manipulate HTTP requests and observe the response from the web application.

HTTP protocol manipulation with LiveHTTPHeaders

LiveHTTPHeaders has added an interesting new feature to replay HTTP requests that the browser has already sent. This feature is useful to manipulate HTTP requests and evaluate the web application's response. Figure 5 shows an HTTP request's selection list.

Figure 5. Selecting from an HTTP request list

Select a request that the browser has already sent to the application, then click on Replay. A window will open, as shown in Figure 6.

Figure 6. Replaying a previous HTTP request

You can change and manipulate HTTP requests in the text block by selecting and replaying the request, which will send HTTP requests to the server. The server responses will appear in the browser. You can also manipulate POST requests.

Identifying attack vectors

Take a previously sent POST request and try to manipulate it. If you recall, the POST request passed a data buffer containing the text id=1&quantity=1.

This request clearly illustrates that the browser transmits some client information. The request contains two fields called id and quantity. An attacker would clearly identify this as a possible attack point, because it may be possible to tamper with or manipulate these variables to inject what security people call a payload into the application. By simply looking at the request, it is possible to see what is going on behind the scenes. In this example, id=1 is the payload that is targeting the SQL database behind the application layer to obtain information about a product. As Figure 7 shows, an id may represent a link to the back-end database.

Figure 7. SQL linkage to the application

Now, if this back-end code is poorly written, it opens up the possibility of SQL injection vulnerability. To inject SQL code into the application, all an attacker has to do is pass values such as a single (') or double quotation mark (") and try to break the query that is running behind the code. Figure 8 illustrates how to perform SQL injection by using LiveHTTPHeaders to manipulate HTTP values.

Figure 8. Manipulating a previous HTTP POST request

This example changes the value of id=1 to id=' (single quotation mark). This allows you to try SQL injection techniques and observe the responses received. Suppose that you do so and receive an error status 500 with the error block:

Instead of a valid HTML page that displays order status, the web application generated an error and threw it back to the browser. The error clearly suggests a SQL error has occurred. This has identified a SQL injection attack vector!

Other security attack vectors that you can probe with this technique include:

SQL injection points and analysis of responses obtained from the server.

Other metacharacter injections and input validation testing.

POST variable and query string manipulations.

Conclusion

When walking through a new web application with web application security assessment as the primary objective, then, having a web browser with extensions that allow HTTP traffic to be sniffed, manipulated, and replayed, all under one roof, benefits the security analyst immensely. A browser extension such as LiveHTTPHeaders provides a comprehensive set of tools without the additional overhead of installing disparate products and getting them to work in tandem in varied environments. All in all, this is a simple solution for complex and challenging tasks such as web application assessment.

Shreeraj Shah
is the founder of Blueinfy, a company that provides application security services.