Assessing Web App Security with Mozilla

by Shreeraj Shah

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:

Related Reading

Security and Usability
Designing Secure Systems that People Can Use
By Lorrie Faith Cranor, Simson Garfinkel

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:

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.

To install LiveHTTPHeaders, just go to the LiveHTTPHeaders XPI location. This XPI script will install LiveHTTPHeaders as a browser plugin. The LiveHTTPHeaders installation guide has additional information.

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.

LiveHTTPHeaders' front-end GUI
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 and you want to carry out HTTP analysis on this web application. Consider what happens when you browse to the URL This is the HTTP request that elicits an HTTP response from the web server. Figure 2 shows this HTTP request and response in LiveHTTPHeaders.

Calling the HTTP GET method
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:

Server: Microsoft-IIS/5.0
X-Powered-By: ASP.NET

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.

Product presentation for an iPod
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:

<form method="post" action="cart.asp">
   <input name="id" value="1" type="hidden">
   <input name="quantity" value="1" size="2" type="text">
   <input value="Add to cart" type="submit">

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

POSTing a form to the server
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:

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.

Selecting from an HTTP request 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.

Replaying a previous HTTP request
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.

SQL linkage to the applicationt
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.

Manipulating a previous HTTP POST request
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:

Error Type:
Microsoft OLE DB Provider for ODBC Drivers (0x80040E14)
[Microsoft][ODBC SQL Server Driver][SQL Server]Unclosed quotation mark before
the character string ''.

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:


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.

Return to the Security DevCenter.

Copyright © 2017 O'Reilly Media, Inc.