groundspeed presentation at the owasp ny/nj
DESCRIPTION
These are the slides for the Groundspeed presentation at the OWASP NY/NJ chapter meeting on Nov 2, 2010TRANSCRIPT
APPLICATION INTERFACES
OWASP NY/NJ Chapter Mee3ng – Nov 2, 2010
MANIPULATING WEB
h=p://groundspeed.wobot.org
User problem?
User problem?
The Standard Approach:
Interact with interface
Intercept and modify HTTP
Analyze response
1 2 3
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
different 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 fields
remove size and length limitations remove JS event handlers
Demo: see Groundspeed in action
But wait a minute: why is this really different than
manipulating HTTP requests?
#1 reason: in order to understand
information we need context
Context problems: without the context we need to fill
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 efficient
(and more boring)
Ok, but… how is this different 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: [email protected]