APPLICATION INTERFACES

felipe@wobot.org

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: felipe@wobot.org