The document discusses an approach called Groundspeed for manipulating web application interfaces from within the browser rather than intercepting and modifying HTTP requests. Groundspeed aims to provide context about form fields and parameters that is missing when analyzing HTTP traffic alone. It argues this reduces unnecessary tasks ("test friction") compared to traditional approaches. Specifically, working at the interface level 1) provides important contextual information and 2) reduces test friction by avoiding tasks like mapping parameters to interface labels. The presentation concludes by advocating a toolbox approach using multiple tools tailored to different layers (interface, JavaScript, HTTP) and bringing testing directly into the browser interface.

1. APPLICATION INTERFACES
felipe@wobot.org
OWASP
NY/NJ
Chapter
Mee3ng
–
Nov
2,
2010
MANIPULATING WEB
h=p://groundspeed.wobot.org

3. User problem?

4. User problem?

5. The Standard Approach:
Interact with
interface
Intercept and
modify HTTP
Analyze
response
1
2
3

6. Advantages:
single point of interception,
absolute control over data

7. Historic reason:
browser used to be a closed box,
no easy way to extend

8. The origin of input data:
HTML interface (forms)
client side logic (JavaScript)
the HTTP client (cookies)

9. Question:
can this information be useful for
improving the penetration test?

10. Core question:
would it be useful to look for a
different approach?

11. http://groundspeed.wobot.org
open source Firefox add-on
released in Nov 09 at AppSecDC

12. Groundspeed goal:
manipulate the webapp interface to
remove client-side limitations in
order to work inside the browser

13. Things you can do:
change the type of form fields
remove size and length limitations
remove JS event handlers

14. Demo:
see Groundspeed in action

15. But wait a minute:
why is this really different than
manipulating HTTP requests?

16. #1 reason:
in order to understand
information we need context

17. Context problems:
without the context we need to fill
in for what is missing

18. Ambiguous context:
if the context is not clear,
we can make mistakes

19. Context is important!

20. Labels are for humans:
the function of the interface is to
provide context to users

21. Parameters are for code:
HTTP parameters are meant for
the server side code, they can be
any arbitrary value

22. The mapping problem:
when we manipulate HTTP
requests we need to map
parameter to interface label

23. #2 reason:
working at the interface reduces
the unnecessary tasks

24. Test Friction:
all this creates“test friction”,
makes the test less efficient
(and more boring)

25. Ok, but…
how is this different than using
Firebug or the Web Dev
Extension?

26. Firebug and WedDev Extension:
very powerful but developer tools,
when used for security will
produce a lot of ‘test friction’

27. Hammers versus screwdrivers:
‘test friction’always appears when
you use a tool that was not
designed for the job

28. Performance load:
degree of mental and physical
activity to perform a task

29. Improved interface

30. Conclusion #1:
thinking about the nature of input
data can make our life easier
create an input testing toolbox

31. Input data toolbox:
interface layer (Groundspeed)
javascript layer (Firebug)
HTTP layer (Burp)

32. Conclusion #2:
tool design should focus on user
process (not the problem)
process = user + problem + context

33. Conclusion #3:
bring the tool into the browser
or the browser into the tool

34. Thank you!
more about groundspeed:
http://groundspeed.wobot.org
comments, questions:
felipe@wobot.org