Web Application Security Testing

1. Web Application Security Testing Hands-On with RailsGoat

2. About Us • Security testing, run our testing company (ScotSTS) • Heavily involved in the OWASP community, run the Scotland chapter events • Rory has presented at Scottish Ruby Conf/Scotland on Rails since 2009 • Marion is an avowed Microsofty (spot the number of MS products!)

3. Agenda • Introduction to Web App Testing • Introduction to Burp Suite • Introduction to RailsGoat • Hands-On!

4. Introduction to Web App Testing

5. Warning!

6. Security Testing Overview • Review the security of a system or systems against an established benchmark or “best practice” • Carried out on a variety of levels • Network • OS • DB • Application • Key Concept – Scope!

7. Testing Types • Black-Box • Automated • Manual • White-Box • Automated • Manual

8. Web App Testing Vulnerabilities • Wide variety of things to test for, where to start…. • OWASP Top 10 – 2013. Good list of places to consider • https://www.owasp.org/index.php/Top10#OWASP_Top_10_for_2013

9. Introduction to Burp

10. More than just a Silly Name • Burp is a proxy-based web application testing tool • De-facto standard for manual web app. Testing • Free and paid-for versions available • Other options are available • OWASP ZAP – upcoming Open Source alternative • Telerik Fiddler – Primarily windows based alternative

11. Why Proxies? • Intercept and modify traffic between client and server • Bypass any JavaScript restrictions • Access hidden fields • Modify headers • Modify cookies

12. Burp Tour – SiteMap

13. Burp Tour – Scope

14. Burp Tour Intercept

15. Burp Tour – HTTP History

16. Burp Tour - Spider

17. Burp Tour - Scanner

18. Burp Tour - Intruder

19. Burp Tour - Repeater

20. Burp Tour - Sequencer

21. Burp Tour - Decoder

22. Burp Tour – Options

23. Introduction to Railsgoat

24. Railsgoat • OWASP Project to provide a training application based on Ruby/Rails. • Rails 3.2 application • Has exercises covering the OWASP Top 10 vulnerabilities • http://github.com/OWASP/railsgoat

25. SQL Injection - Overview • One of the most serious security issues you are likely to see in web applications • Impact can extend to the underlying operating system • Have been examples of SQLi in underlying libraries (e.g. ActiveRecord) as well as application code.

26. SQL Injection – Blackbox Testing Basics • Test form fields, form field names, cookies, headers (basically any data that could be used in a query) • Test strings • ‘ – single quote character can show up problems if an error is returned • ‘ OR ‘1’=‘1 – logical true statement • ‘ AND ‘1=‘0 – Logical false statement • Str’ || ’ing – string concatenation (depends on underlying DB) • <int>+1 – numerical addition • Observe responses

27. Exercise 1 – SQL Injection • Set-up the proxy to intercept • Update a user account • Try modifying the user_id parameter…

28. Command Injection • Another input validation/sanitization issue • Possible wherever the application interfaces to the underlying system • Calls to things like system()

29. Command Injection – Black Box Testing • | character • Sample commands e.g. ‘cat /etc/passwd’ • Underlying platform matters (different commands and paths on windows)

30. Exercise 2 – Command Injection • Intercepting proxy again • Testing in the benefits upload section • Where to look for the created directory?

31. Information disclosure • Information gathering is a key piece of testing • Build up a picture for later attacks

32. Information Gathering – Black box • Mainly look for known areas to get information • Username enumeration • Error messages (version info/path info) • Default files

33. Exercise 3 – Username enumeration • Enter an incorrect username • Now enter a correct username with an incorrect password • Could you automate this process? • What can you do with a list of usernames?

34. Password Weaknesses • Passwords are the sole authentication mechanism on almost all sites • Weak passwords cause breaches • Standard part of testing

35. Password Weaknesses – Black Box • Can be very straightforward (disclosed password policy) • Still worth checking • Length • Complexity • Truncation(?) • Reset process

36. Exercise 4 – Password Strength • Easy to test • Try setting your password to some standard values • P • Abc123 • Password • .. • Ties into the username enumeration from the last exercise

37. Cross Site Scripting • Very common issue, results from user supplied input being returned to the browser without appropriate encoding/sanitization • 3 Main variants • Reflected • Stored • DOM-based • Can have quite serious impacts (see the beef project for examples)

38. Cross-Site Scripting – Black Box • Insert test strings into fields on the page • “><script>alert(‘lorem’)</script><“ • ‘); alert(‘lorem’) ; • Look at output for all locations where the output appears. • Is it encoded? • Is it sanitized?

39. Exercise 5 - XSS • Register a new user • Try out some vectors in various fields… • Added Bonus! – DOM XSS • Not an intended exercise in the app. • Vulnerability in the Jquery Snippet library used. • May not work depending on your browser

40. Insecure Direct Object Reference • Terrible name! • It basically refers to places where there’s a weakness in how the application checks authorisation and the object reference is exposed • Rails (and other REST style frameworks are particularly susceptible)

41. Insecure Direct Object reference – Black Box • Usually pretty easy. • Wherever you see a numeric parameter (e.g /users/1) try 2 or 3 etc • Look for paramters in the URL, in hidden fields or cookies. • Watch out for Obfuscated (e.g. base64 encoded) parameters. • Burp encoder comes in handy for these

42. Exercise 6 – Insecure Direct Object Reference • Try going to the Work Info section of the application while logged in • Any way to change the Object being referenced?

43. Sensitive Data Exposure • A “Know it when you see it” vulnerability • Not really findable with automated tools • Covers different types of data • Password (cleartext or hashed) • Credit Card numbers • …

44. Data Exposure – Black box • Review the application for exposed sensitive data! • Watch out for areas where data hiding is done client-side • (e.g. hidden fields, Javascript used to obfuscate data)

45. Exercise – Data exposure • The application has an API • We need to authenticate to it • Token header • Authorization: Token token=1-01de24d75cffaa66db205278d1cf900bf087a737 • Lets see what they store for users /api/v1/users

46. Authorisation flaws • Two general classes of problem • Failure to check that a user is authenticated before providing information • Failure to check that an authenticated user has the right authorisation to the information before providing it • Second one is more common

47. Authorisation Flaws – Black box • Build up a map of functions (spidering, rake routes) • Try all functions unauthenticated • Try privileged functions as low-privileged users

48. Exercise 8 – Authorisation flaw • Easily exploited – Unprotected admin interface • /admin/1/dashboard/ • If you didn’t have the URL how could you find it?

49. Unvalidated Redirects • Quite a specific problem but pretty common • Application takes a URL as a parameter (e.g. for redirect after logon) • Doesn’t validate that the location is within the app. • Useful for phishing attacks.

50. Unvalidated Redirect – Black box • Keep an eye out for URL parameters • Hidden fields, cookies, URL • Modify to another value and see where it takes you 