The slides for the Oredev 2014 talk "confessions of an accidental Security Tester" - describing the various approaches and bad habits that I use, which allow me to stumble on to security problems.
Accidental Security Tester Reveals How to Find Bugs Without Looking
1. Confessions of an Accidental
Security Tester
"I didn't break in, you left the door open"
Alan Richardson
@eviltester
www.SeleniumSimplified.com
www.EvilTester.com
www.CompendiumDev.co.uk
www.JavaForTesters.com
3. 3
“I am not a security tester”
● I am a user that observes the system
at a lower level of detail than many
users
● I think about what I observe
● Based on my observations I then ask
the system 'what if?' questions
4. 4
“Accidentally Stumble”
I prefer to get paid for finding defects
But...
● I use the web for business
● My personal details are submitted to web sites
● I like to make sure I'm safe
● I 'accidentally stumble' across security defects
5. 5
“By adopting my
'Bad' habits, you can
Accidentally Stumble
across Security
Defects too”
6. 6
How I 'Accidentally Stumble'
● I use browser dev tools in my normal day to day
web surfing:
– Firebug, Chrome Developer Tools
● I often have all my web traffic running through a
debug proxy:
– Fiddler, BurpSuite, ZAP
● I inspect Web Forms before I submit them
This is normal behaviour for me.
11. Bypassing Bugs and annoyances on
11
WebSites
● Div based overlays that stop me doing what
I need to
● Buttons not enabled when they should be
● Incorrect JavaScript validation that marks
invalid my valid details
● Etc.
14. 14
It won't just be me doing this
● Browser Dev Tools are now installed by default
● Everyone has access to lower level observation
and manipulation features
● “No user would ever do that” is no longer valid
● Some users are kids.
– Kids love doing this
15. 15
“I'm not a security
tester. I'm just a
Cruddy guy”
16. 16
C.R.U.D.dy
● Create
– Create new POST requests with the information you
want
● Read
– Read the HTTP requests and see the information to
build a model of the system
● Update
– Update the information sent to the server to match
what I want
● Delete
– Delete requests and responses I dont' want
17. 17
What do you apply CRUD to?
● URL
● Cookies
● Payloads
● Form Fields
● DOM
● HTTP Methods
● HTTP Headers
● etc.
– make a list of 'entities' involved in HTTP process
18. 18
Example URL CRUD
● URL
– (C)Guess new urls, new params, mixup params
– (R)track used urls,
– (U)amend params in url,
– (D)change HTTP method; delete params
● Why?
– See new products, change items in page,
undocumented API commands, etc.
● How?
– Proxy tools, Amend DOM, Amend URL in browser
19. ● Read
● Update Before Sending
● Delete so never sent
● Create new requests
based on old requests
19
Example HTTP Request
Amend in DOM
before sent
to proxy
Browser Proxy Server
● Read
● Update Before Receipt
● Create/Replace so receive
something else
● Delete so never Received
20. 20
Example Cookie CRUD
● Create new Cookies
● Update values
● Read – track cookies over time
● Delete Cookies
● Why?
– Session hijacking, new permissions, change
baskets, depends what they are used for, etc.
● How?
– Browser dev tools, Debug Proxy
21. 21
My First Proper Security Bug
● My first crowd sourced testing
experiment
– Testing a 'social media' video sharing
& watching site
● Everyone else:
– Low hanging fruit, spelling errors,
broken links, missing images, etc.
● Me:
– I can access the live system and see
all customer details including emails
and addresses
22. 22
How did I find the defect?
● I used the site
● I ran the traffic through a Proxy
● I saw the urls of requests that
returned user data
● I created a request & tried /users/
instead of /user
● I changed test.site.com to site.com
to hit live
● Ooops, live data vulnerability
Read
Observe / Model
Create
Update
23. 23
Lessons Learned –
Companies Love Security Defects
5 Star Tester
Only Quality
Defects Here
24. Technical Defect
24
See how much they loved me
I raised a
I raised a
showstopper!
I was 5 star,
now I'm 4.5
$$ Big Money $$
25. 25
I didn't deliberately look for a
security issue
● I explored the system
– Perform normal functions, observing traffic
● I built a model
– How do the requests map to the functions
● I thought about the model from a 'risk'
perspective
– Does the API let you see all Users?
– Does this work on live?
● I found a way to ask the system the questions
26. 26
Generic Lessons Learned
● The techniques and tools that we normally use
for web testing extend to security testing
● Increase your ability to Observe the system
● Model the system
● Think about what that model implies
● Manipulate the system and ask 'what if'
questions
– Sometimes known as 'testing'
27. 27
Defects I 'mostly' got fixed
● Viewing the revenue reports for other sellers
– Urls not protected by user permissions
● Unpaid video downloading via ipad and android
– Permissions from web across devices
● The 'Get' that became a 'Post'
– Comments in site, Open source documentation
● Should I be able to buy this for $0?
– Shopping cart amendment
29. 29
My old process
● Email to support
● Another Email
● And another
● Etc.
30. 30
When it was really serious
● Email to support
● Public post in their user forums or Facebook
● Email to support
● Find the emails of CEO, CTO, etc.
● Email as many people in the company as I can
● Replies to other people's posts in the forums
Nag Nag Naggity Nag
31. 31
What I've found works
● Create a video of you doing the exploit, as
though it were a tutorial video
● Email the video
● Mention that you release video tutorials to
YouTube
youtube.com/EvilTesterVideos
32. 32
Lessons learned
● Make it impossible to misunderstand
– Write it up clearly
– Show it in Action
– Create a 'script' that performs the exploit
● Let everyone in the company that you can find
see the exploit
33. 33
And if they don't fix it...
...at least you have an automated
script that allows you to continue to
take advantage of it
35. 35
“I stumbled across
security issues on
a well known
developer
conference web
site”
36. 36
“There are product
sales sites where I
can still download
their stuff for free”
37. “I found a 'download'
form that supplied me
37
with emails and
server commands I
could have tried”
38. 38
If you are a tester...
● You should already have the thought processes
required to stumble across these issues
– Model, Observe, Risk, Manipulate, CRUD
● You may need to learn
– to read HTTP requests
– JavaScript, and use the Dev Tool Debugger
● You may need to start using
– Debug Proxies – Fiddler, ZAP, BurpSuite
– Browser Dev Tools & Firebug
40. 40
Warning: Slippery Slope
● You start seeing more of these problems
● You become more concerned...
– And start using VPNs
– Monitoring your apps and network using Wireshark
● You gain more technical knowledge
● You test at deeper levels of the system
41. 41
And I learn generic issues
● Too much data in JSON
– Performance issue
– Possible Security Issue
● Knock on security impact of small change
● Data in JSON used in 'other' places
– Enrich domain model from multiple sources
43. 43
Suggested Gateway Hobbies
● Monitor HTTP Wifi Network traffic using
WireShark
– Suggested locations: Hotels, Public WiFi,
Conferences, and Airport Lounges
● Monitor your network traffic using an HTTP
debug proxy
● Investigate the DOM using Browser Dev Tools,
by default
● Break out of the sandbox of Kiosk systems
44. 44
Blogs and Websites
● CompendiumDev.co.uk
● SeleniumSimplified.com
● EvilTester.com
● JavaForTesters.com
● Twitter: @eviltester
Online Training Courses
● Technical Web Testing 101
Unow.be/at/techwebtest101
● Intro to Selenium
Unow.be/at/startwebdriver
● Selenium 2 WebDriver API
Unow.be/at/webdriverapi
Videos
youtube.com/user/EviltesterVideos
Books
Selenium Simplified
Unow.be/rc/selsimp
Java For Testers
leanpub.com/javaForTesters
Alan Richardson
uk.linkedin.com/in/eviltester
Independent Test Consultant
& Custom Training
Contact Alan
http://compendiumdev.co.uk/contact