Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Confessions of an Accidental Security Tester

5,913 views

Published on

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.

Published in: Software
  • Be the first to comment

Confessions of an Accidental Security Tester

  1. 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
  2. 2. 2 WARNING I AM NOT A SECURITY TESTER
  3. 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. 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. 5 “By adopting my 'Bad' habits, you can Accidentally Stumble across Security Defects too”
  6. 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.
  7. 7. 7 “I developed these 'bad' habits out of necessity”
  8. 8. 8 I wanted to skip the online TV ads
  9. 9. 9 I sucked at online games
  10. 10. 10 Reading 'unreadable content'
  11. 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.
  12. 12. “It wasn't me Guv, THEY made me do it” 12
  13. 13. 13 “Other normal people will develop these habits as well”
  14. 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. 15 “I'm not a security tester. I'm just a Cruddy guy”
  16. 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. 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. 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. 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. 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. 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. 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. 23 Lessons Learned – Companies Love Security Defects 5 Star Tester Only Quality Defects Here
  24. 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. 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. 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. 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
  28. 28. 28 Some notes on Reporting and Advocacy
  29. 29. 29 My old process ● Email to support ● Another Email ● And another ● Etc.
  30. 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. 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. 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. 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
  34. 34. 34 “Some Defects don't get fixed quickly, they are still live”
  35. 35. 35 “I stumbled across security issues on a well known developer conference web site”
  36. 36. 36 “There are product sales sites where I can still download their stuff for free”
  37. 37. “I found a 'download' form that supplied me 37 with emails and server commands I could have tried”
  38. 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
  39. 39. 39 WARNING THIS IS A SLIPPERY SLOPE OUCH!
  40. 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. 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
  42. 42. 42 Suggested Reading/ Viewing unow.be/at/techwebtest101
  43. 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. 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

×