Confessions of an Accidental Security Tester
2 likes•7,692 views
Alan Richardson shares his experiences of unintentionally discovering security vulnerabilities while performing normal web testing tasks. He emphasizes that even regular users can adopt habits that lead to the identification of security defects, illustrated through examples of manipulating web elements and utilizing developer tools. The document also discusses the importance of understanding system behaviors, observing traffic, and the techniques that testers can apply to uncover security issues.
Confessions of an Accidental Security Tester
- 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 WARNING I AM NOT A SECURITY TESTER
- 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.
- 7. 7 “I developed these 'bad' habits out of necessity”
- 8. 8 I wanted to skip the online TV ads
- 9. 9 I sucked at online games
- 10. 10 Reading 'unreadable content'
- 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. “It wasn't me Guv, THEY made me do it” 12
- 13. 13 “Other normal people will develop these habits as well”
- 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
- 28. 28 Some notes on Reporting and Advocacy
- 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
- 34. 34 “Some Defects don't get fixed quickly, they are still live”
- 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
- 39. 39 WARNING THIS IS A SLIPPERY SLOPE OUCH!
- 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
- 42. 42 Suggested Reading/ Viewing unow.be/at/techwebtest101
- 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