OWASP ZAP - example

Within this post I would like to launch a few automated attacks, both passive and active using ZAP and provide examples.

 

I will attack my own live web service, which is currently not in use. Website was prepared for an attack, ensuring that my activity could cause no harm, while some security measurements are lifted or modified for the test.

As ZAP's library of add-ons is extremely rich, for this example I will use fresh installation of version 2.11.1 - newest at the point of creating this post, with no additional modules installed.

 

The easiest way of using ZAP is browser proxy.  It allows to browse web service via a modified browser, performing passive tests on data transferred between browser and server. This may lead to identify vulnerabilities of web service. All security risks are displayed in ZAP HUD in section marked 1 in screenshot below. Risks are displayed by severity - from informational (blue flag) to severe security risks (red flag). 

ZAP has also Attack mode disabled by default. By enabling attack mode and launching active scan (marked 2 on screenshot below) ZAP is able to detect more serious vulnerabilities and potential attack vectors for further penetration of the system. It is extremely important to ensure all services in attack scope are owned or user has permission to test as ZAP is performing real attack that might and should be detected by its target. 

In example above ZAP detected two medium risk (orange flag) vulnarabilities. As active scan was launched, software crawled through the entire website, being able to detect risks on different sub-sites, including those hidden or with no permission to use. 

As example above shows, contact form accessible from subsite /contact.html has no anti-CSRF token, which means is vulnerable to Cross Site Request Forgery attack. We could assume that forms within authorised users' panel section also following this pattern, revealing first possible attack vector: CSRF. Also, this form could be vulnerable for spam bots.

At the sime time, my service raised 3 alerts about ongiong attacks: hidden service scanning (300+ requests), parameter pollution attempts (on every accessed sub-page) and 8 CSRF/spambot attacks. This highlights that even most basic ZAP attack could be detected if target software is able to log and report threats to its safety.

Returning to contact form with no anti-CSRF token. Accessing it through ZAP browser reveals hidden form field:

 

After couple attempts is easy to guess that hidden field is related to anti-bot measurements. Before submitting form, customer need to solve easy mathematic problem, providing answer from 1 to 6. Question is randomized, but software is providing right answer via hidden form field, with numbers are changed for letters, e.g. 3+3=6=e. While this could prevent spambots from attack, security is too weak for targeted attack when hacker could create easy script to bypass this measurement.

Using only most basic ZAP functionalities at this point there is identified potential attack vertor that is able to give attacker unauthorised access or control over service, and one certain exploit that could be used to extensively disrupt service e.g. by sending big amount of spam messages over website forcing owners to disable the form or make them unable to respond on customers messages.