APPLICATION INTERFACES
felipe@wobot.org
OWASP	
  NY/NJ	
  Chapter	
  Mee3ng	
  –	
  Nov	
  2,	
  2010	
  
MANIPULATING WEB...
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 fricti...
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
Groundspeed Presentation at the OWASP NY/NJ
Upcoming SlideShare
Loading in …5
×

Groundspeed Presentation at the OWASP NY/NJ

4,389 views

Published on

These are the slides for the Groundspeed presentation at the OWASP NY/NJ chapter meeting on Nov 2, 2010

Published in: Technology, Design
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,389
On SlideShare
0
From Embeds
0
Number of Embeds
2,613
Actions
Shares
0
Downloads
43
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Groundspeed Presentation at the OWASP NY/NJ

  1. 1. APPLICATION INTERFACES felipe@wobot.org OWASP  NY/NJ  Chapter  Mee3ng  –  Nov  2,  2010   MANIPULATING WEB h=p://groundspeed.wobot.org  
  2. 2. User problem?
  3. 3. User problem?
  4. 4. The Standard Approach: Interact with interface Intercept and modify HTTP Analyze response 1   2   3  
  5. 5. Advantages: single point of interception, absolute control over data
  6. 6. Historic reason: browser used to be a closed box, no easy way to extend
  7. 7. The origin of input data: HTML interface (forms) client side logic (JavaScript) the HTTP client (cookies)
  8. 8. Question: can this information be useful for improving the penetration test?
  9. 9. Core question: would it be useful to look for a different approach?
  10. 10. http://groundspeed.wobot.org open source Firefox add-on released in Nov 09 at AppSecDC
  11. 11. Groundspeed goal: manipulate the webapp interface to remove client-side limitations in order to work inside the browser
  12. 12. Things you can do: change the type of form fields remove size and length limitations remove JS event handlers
  13. 13. Demo: see Groundspeed in action
  14. 14. But wait a minute: why is this really different than manipulating HTTP requests?
  15. 15. #1 reason: in order to understand information we need context
  16. 16. Context problems: without the context we need to fill in for what is missing
  17. 17. Ambiguous context: if the context is not clear, we can make mistakes
  18. 18. Context is important!
  19. 19. Labels are for humans: the function of the interface is to provide context to users
  20. 20. Parameters are for code: HTTP parameters are meant for the server side code, they can be any arbitrary value
  21. 21. The mapping problem: when we manipulate HTTP requests we need to map parameter to interface label
  22. 22. #2 reason: working at the interface reduces the unnecessary tasks
  23. 23. Test Friction: all this creates“test friction”, makes the test less efficient (and more boring)
  24. 24. Ok, but… how is this different than using Firebug or the Web Dev Extension?
  25. 25. Firebug and WedDev Extension: very powerful but developer tools, when used for security will produce a lot of ‘test friction’
  26. 26. Hammers versus screwdrivers: ‘test friction’always appears when you use a tool that was not designed for the job
  27. 27. Performance load: degree of mental and physical activity to perform a task
  28. 28. Improved interface
  29. 29. Conclusion #1: thinking about the nature of input data can make our life easier create an input testing toolbox
  30. 30. Input data toolbox: interface layer (Groundspeed) javascript layer (Firebug) HTTP layer (Burp)
  31. 31. Conclusion #2: tool design should focus on user process (not the problem) process = user + problem + context
  32. 32. Conclusion #3: bring the tool into the browser or the browser into the tool
  33. 33. Thank you! more about groundspeed: http://groundspeed.wobot.org comments, questions: felipe@wobot.org

×