Sunday, April 2, 2017

How to use ZAP proxy to find vulnerabilities in WebGoat

So you're starting to become a "Penetration Tester" or "Web Application Security Expert"? Maybe you first look at how to discover a XSS-vulnerability? That's great and all necessary, but learn to use existing tools to your advantage and save yourself from repetitive work. Introducing ZAP proxy from the magnificent OWASP-community. It's "is one of the world’s most popular free security tools" so you better know how to use it! Another very popular alternative is Burp Suite, but I prefer to use open-source tools where possible.

Let's take a look how to use a tool like ZAP to find vulnerabilities in a purposefully vulnerable demo project: WebGoat is another project by OWASP which "designed to teach web application security lessons". In this case we're using NodeGoat since I'm currently focusing on Node.js development.

Install and start ZAP, which automatically starts a local proxy at port 8080. Configure your browser or your operating system to use that for both HTTP and HTTPS.
Configuring a proxy on Ubuntu 16.10
Now we're ready to rumble. Before ZAP can start with the hard work we'll have to show it around the webapp we want to attack. Open your own instance of NodeGoat in a browser and trigger all available pages and features once: signup, login, logout, changing profile, etc. You should end up with a "sitemap" in ZAP now. If not, you didn't configure your browser to use the proxy!
sitemap generated by ZAP after visiting NodeGoat in a browser
While you were browsing NodeGoat, ZAP inspected all traffic and looked for possible vulnerabilities. This passive scan should mostly uncover some missing security-related HTTP headers. You can see those under "Alerts" in ZAP.

Our part is done now, let's get ZAP working! In order to start an active scan, right-click on the entry of your webapp in the sitemap, click "Attack" and "Active Scan". You can fine-tune the scan by clicking "Show advanced options" and looking at all available options. Since we're using our own instance of NodeGoat it's safe to crank up all settings. Most importantly, enable "HTTP Headers" and "Cookie Data" under "Input Vectors". This tells ZAP to try known combinations of headers in order to exploit a vulnerability.
starting an active scan in ZAP
configuring an active scan in ZAP

Again, inspect the "Alerts" tab for an explanation of all problems discovered so far.

What we found so far are mostly vulnerabilities for the public-facing side of our webapp (read not authenticated sections). This is great for starters, but there's so much more potential to find a vulnerability in authenticated sections of a webapp! Unfortunately this is quite hard to scan in ZAP because it involves some more configuration on our end. If you're interested in how to do that, check out this video: ZAP Tutorial - Ajax Spidering authenticated websites