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!
INTRODUCTION TO WEB APP TESTING
WARNING!
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
INTRODUCTION TO BURP
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
WHY PROXIES?
• Intercept and modify traffic between client and server
• Bypass any JavaScript restrictions
• Access hidden fields
• Modify headers
• Modify cookies
BURP TOUR – SITEMAP
BURP TOUR – SCOPE
BURP TOUR INTERCEPT
BURP TOUR – HTTP HISTORY
BURP TOUR - SPIDER
BURP TOUR - SCANNER
BURP TOUR - INTRUDER
BURP TOUR - REPEATER
BURP TOUR - SEQUENCER
BURP TOUR - DECODER
BURP TOUR – OPTIONS
INTRODUCTION TO RAILSGOAT
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
– …
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)
EXERCISE – DATA EXPOSURE
• The application has an API
• We need to authenticate to it
– Token header
– Authorization: Token token=101de24d75cffaa66db205278d1cf900bf087a737
• 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 
EXERCISE 9 – UNVALIDATED REDIRECT
• url parameter for logins…
WHITE BOX TESTING
• As mentioned not all vulnerabilities are findable using black box
techniques
• Automated Scanning or manual code review required
CONFIGURATION OPTIONS
• If you have access to source code always worth checking
• N.B. testers/attackers will often check for config. Errors as part
of reconnaissance
QUESTIONS?
CONTACT - @RAESENE, RORY.MCCUNE@SCOTSTS.COM MARION.MCCUNE@SCOTSTS.COM