ZAP! Your way into Security Testing!

In today’s digital world, taking security with a light touch is risky, to say the least. Despite the apparent validity of this statement, some industries appear to invest lightly on security within their software development.

From the perspective of Software Development professionals, one would think that the company would ensure that security tasks are tackled within the development teams. Security-related enhancements would pop up within sprint commitments and Agile task boards. It is a fact that various ways and measures can be taken to protect a web application. As an example, networking and infrastructure can have security at the heart of each decision, protecting the system from unauthorized access through comprehensive whitelisting and/or blacklisting. But the application has to be built with the same characteristic in mind because if discovered, one security hole can make the whole system at risk.

Is it part of our job?

Let’s cut to the chase. Does security fall under the responsibilities of QA Engineers? The answer can be debatable and like most answers, it depends. Some workplaces might define it explicitly under the QA’s tasks, while others might not even mention it at all. There are also specific roles which are assigned with this responsibility, such as Security Engineers and IT Security Administrators. These roles not only ensure that systems do not expose any vulnerabilities but also have to prepare for the effect of a natural disaster by developing disaster recovery plans.

Having said that, as a QA, quality is in our heart, and security affects quality as it influences the user experience directly. Since security is another non-functional aspect of an application, its effects do not stand out as much as the user’s direct interaction with the system’s functionality. We need to dig deeper and truly understand the internals of a system under test. However, to be able to do this, testers need to broaden their knowledge and learn about security vulnerabilities.

Where do we begin?

Like every other topic, there is loads of information on the internet. One of the best sources for Security Testing is OWASP. This community is an excellent source of open-source security tools. From blog posts to audio podcasts, to handy open-source tools, they have it all. Another great source which I highly recommend is the Secure Guild conference organized by Joe Colantonio.

There are a lot of relevant tools out there. Paid and free tools with the ability to hook to IDEs and report issues, or scan your code and detect problems. The OWASP ZAP is a dynamic tool which tries to identify security vulnerabilities using a local HTTP proxy. It can actively or passively attack your system and report vulnerabilities. ZAP is part of the OWASP set of tools. In fact, even the Juice Shop which Andrea discussed in a previous post, is also part of OWASP tools.

In this post, I will focus on the ZAP API Scan, which is a script included with the official ZAP Docker images. The only dependency that it has is Docker itself. The API runs an active scan which is tuned to detect vulnerabilities for APIs, therefore excluding checks such as XSS (Cross-Site Scripting) which relies on scripts running within the browser. As a side note, an active scan is an actual attack on the target application, which means that you should be careful of how and where to run it.

Let’s try it out!

For the script to be able to run against your API, it needs the API documentation in the form of either OpenAPI or SOAP, defining it through the -f parameter. If your application is serving another type of API documentation such as RAML, you will need to use a converter. In the case of RAML, one of these converters can be found on this GitHub, allowing you to convert different RAML versions to OpenAPI. You can either specify a local file or point the API to the URL which contains the API specification. Do this by using the -t parameter. You also need to specify which format you are using by setting the -f parameter to either ‘openapi’ or ‘soap’. You can have a look at the complete list of available parameters in this Wiki.

A typical run would look like this:

• First, we pull the Docker image by running this in the terminal:
  docker pull owasp/zap2docker-weekly
• Then we run the actual scan:
  docker run -v /tmp:/zap/wrk -i owasp/zap2docker-weekly zap-api-scan.py -t https://www.yourapp.com/openapi.json -f openapi -r ScanReport.html

At the end of the process, you will be able to access the defined HTML report file where you will see if the scan has found potential risks. The report will not show the full list of risks that the script checks. You can see the whole list (passed and failed) from the terminal.

Alert!

The report itself gives a description of the alerts being raised, together with their risk level. In the screenshot of a sample report shown above, you can see that apart from the explanation of the alert, the report also provides a solution to fix it. Let’s have a closer look at this alert.

The ZAP report mentions that the X-Content-Type-Options header is missing from one or more responses. Setting this header to ‘nosniff’ will prevent the ability of a browser to override the content type through MIME sniffing. This sniffing is intended for beneficial use such as when the browser needs to interpret the content but does not have the necessary information to do so. In this case, it tries to understand what the content is by inspecting the response bytes and detecting the format of the file. However, this can also be used maliciously and expose the app to attacks through MIME-type confusion. Most modern and updated web browsers do not allow sniffing, however, the safer way would be to enforce it explicitly.

What next?

The ZAP automated script might be your first step into security testing. Ideally, the next thing would be to discuss the scan result with your team and figure out which items need changes. After that, you should start getting acquainted with web application security by researching about top 10 security risks, essentially getting familiar with web security technical words. From there, you’ll primarily learn about more tools and more ways; both manual and automated, of how to uncover vulnerabilities.

In the end, having initiative is the best approach to show how invaluable you are as a professional. Plus it adds skills to your testing tool belt!

Originally published at https://testautonation.com on 06/2019.