Hands-On with RailsGoat WEB APPLICATION SECURITY TESTING

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 – Good list of places to consider –

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

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) – +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 – “> alert(‘lorem’) <“ – ‘); 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=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

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