WebApp Sec mailing list archives

Re: [Tool Announcement] Groundspeed Firefox add-on


From: Felipe Moreno <felipe () wobot org>
Date: Wed, 16 Dec 2009 23:33:25 -0500

Here is an email exchange that took place today outside the list but
is interesting to share with the entire group. I imagine that other
people out there might be asking themselves the same question. I'm
sharing it with Kevin's permission :)

On Wed, Dec 16, 2009 at 10:51 AM, Wall, Kevin <Kevin.Wall () qwest com> wrote:
IMO, you are right, Firebug add-on was written to help developers debug JavaScript, but it
seems to me that the Tamper Data add-on was done to facilitate pen testing. And if
it were not enough, one also has things like the Paros and Burp proxies to choose
from.  So what makes Groundspeed more suitable for pen testing then using any
of these 3 or things like them?

That is also a very good point. In the OWASP presentation I made an
argument about the "context" of input data.

Basically the idea is that the data we are trying to manipulate in
input validation tests originates in the application user interface
(most of the time). There the data makes sense to a human being,
because it has context (the labels and other information in the page
helps the user know what the data he is typing in means).

When we work at the HTTP level (Tamper Data or proxies), the data is no
longer in the same context. There are no "labels" anymore and although
the parameter names can act as pseudo-labels sometimes, they are not
meant for humans, they are meant for server-side code. They could be
any random string. The tester has then the extra burden of "mapping
parameters" to what they can actually mean (back to the UI labels most
of the time). And this is hard, including some cognitive tasks like
reading through ("parsing") HTTP requests that impose a high "cost" on
the tester.

While this may be relatively easy for simple web applications (where
one form matches one HTTP request and fields in the form map to
parameters one-to-one) as applications become more complex (more
client-side logic) this will become more and more complicated. Think
about AJAX for example.

So the idea behind Groundspeed is that working at the interface level
is better for cases where the input data comes from the user. Of
course not all input data starts at the user interface, some will start
in the client-side logic, some will be hardcoded in links, etc. In these
cases it is better to use a JavaScript debugger and/or a proxy.

Groundspeed does not intend to replace Firebug, Tamper Data or proxies
but just to be one more tool in the toolbox. Sometimes it will make sense to
work at the interface level, sometimes it will not.

--
Felipe.



This list is sponsored by Cenzic
--------------------------------------
Let Us Hack You. Before Hackers Do!
It's Finally Here - The Cenzic Website HealthCheck. FREE.
Request Yours Now! 
http://www.cenzic.com/2009HClaunch_Securityfocus
--------------------------------------


Current thread: