Web Application Security Testing Hands-On with RailsGoat
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!)
Agenda • Introduction to Web App Testing • Introduction to Burp Suite • Introduction to RailsGoat • Hands-On!
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!
Testing Types • Black-Box • Automated • Manual • White-Box • Automated • Manual
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
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
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
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.
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
Exercise 1 – SQL Injection • Set-up the proxy to intercept • Update a user account • Try modifying the user_id parameter…
Command Injection • Another input validation/sanitization issue • Possible wherever the application interfaces to the underlying system • Calls to things like system()
Command Injection – Black Box Testing • | character • Sample commands e.g. ‘cat /etc/passwd’ • Underlying platform matters (different commands and paths on windows)
Exercise 2 – Command Injection • Intercepting proxy again • Testing in the benefits upload section • Where to look for the created directory?
Information disclosure • Information gathering is a key piece of testing • Build up a picture for later attacks
Information Gathering – Black box • Mainly look for known areas to get information • Username enumeration • Error messages (version info/path info) • Default files
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?
Password Weaknesses • Passwords are the sole authentication mechanism on almost all sites • Weak passwords cause breaches • Standard part of testing
Password Weaknesses – Black Box • Can be very straightforward (disclosed password policy) • Still worth checking • Length • Complexity • Truncation(?) • Reset process
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
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)
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?
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
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)
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
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?
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 • …
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
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
Authorisation Flaws – Black box • Build up a map of functions (spidering, rake routes) • Try all functions unauthenticated • Try privileged functions as low-privileged users
Exercise 8 – Authorisation flaw • Easily exploited – Unprotected admin interface • /admin/1/dashboard/ • If you didn’t have the URL how could you find it?
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.
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