Groundspeed Presentation at the OWASP NY/NJ

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

User problem?

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

Advantages: single point of interception, absolute control over data

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

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

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

Core question: would it be useful to look for a diﬀerent approach?

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

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

Things you can do: change the type of form ﬁelds remove size and length limitations remove JS event handlers

Demo: see Groundspeed in action

But wait a minute: why is this really diﬀerent than manipulating HTTP requests?

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

Context problems: without the context we need to ﬁll in for what is missing

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

Context is important!

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

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

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

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

Test Friction: all this creates “test friction”, makes the test less eﬃcient (and more boring)

Ok, but… how is this diﬀerent than using Firebug or the Web Dev Extension?

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

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

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

Improved interface

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

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

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

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

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

http://groundspeed.wobot.org	1417
http://translate.googleusercontent.com	12

by Felipe M on Nov 03, 2010