When we manually test web applications we tend to treat all input data the same way. We set up an HTTP proxy, we intercept requests and manipulate them.

But interesting data, from the perspective of the penetration tester, can come from very different places in the client side: HTML forms in the user interface, client-side JavaScript code, hard-coded query strings in the HTML, cookies or other HTTP headers, etc.

Think about how painful it can be to perform manual test on an AJAX application using only an HTTP proxy. Most of the requests are asynchronous and it is hard to understand the data they contain. However it is much easier to work directly at the JavaScript layer using a debugger like Firebug because reading the code associated to the AJAX requests provide the context we are missing to understand the data.

Client side HTTP proxies are “catch all” tools, they work for all types of input data because everything goes to the server via HTTP. Maybe there are opportunities to improve the testing if we consider more the nature of the input data. We could think about new tools that would be better integrated into the client-side process instead of sitting in front of it, waiting to intercept the raw HTTP traffic as it leaves the browser.

Following my previous post about how groundspeed compares to Firebug and the Web Developer extension, another interesting question is how Groundspeed compares to client-side proxies (Paros, Burp, etc.) and other tools that modify HTTP requests like TamperData.

The data we manipulate when performing input validation usually originates at the application user interface (the forms). At the user interface input data makes sense, because the interface was designed to be used by people. The page labels and text provide context to the information.

When we work at the HTTP level (using client proxies or TamperData) we lose the context provided by the interface. Even if the HTTP parameters act sometimes as pseudo-labels, they were not meant to be read by people and could be any random string. At the HTTP level we have to map each parameter to what it actually means and for data coming from the interface this means mapping them back to the form elements so we can use the labels as context.

This problem may be easy to solve for simple web applications (one HTTP request matches one form and form elements match parameters one to one), but is much more complicated for complex applications (more client-side logic, lack of synchronism).

The idea behind Groundspeed is that working at the interface level is better for cases where the input data comes from the user because at that level we have the best context for the information we are manipulating. Of course, not all input data comes from the user interface, so Groundspeed can never replace other tools like JavaScript debuggers or client side proxies, it’s just one more tool in the toolbox.

Some people asked me about what makes Groundspeed different from other Firefox addons like Firebug or the Web Developer Extension.

While both of these tools allow you to manipulate the DOM structure of the page loaded in the browser, they were not designed for manipulating the user interface elements for the purpose of pentest and as a consequence they require more effort to use.

Manipulating the user interface using Groundspeed requires less cognitive tasks (reading through source code, navigating a tree structure, etc.) and manipulation tasks (clicking, switching tabs, windows, etc) than doing the same thing using Firebug or the Web Developer extension.

One of the arguments I made in the OWASP presentation is that these “extra” tasks finish up having a high “cost” for the tester when you consider that you have to repeat them a lot. They distract the tester, they do not contribute to the goal of the test and they are annoying. You can think of them as some sort of “test friction”.

Groundspeed is a tool designed for a very specific task while Firebug and the Web Developer extension are very powerful tools designed to solve a broad range of problems. If you think of them as chainsaws, it’s true that you can use them to open your mail… but for that specific task, maybe it makes more sense to use a letter opener (specially if you want to keep all your fingers).