How to Test Permissions Policy Header Configuration with ZAP
Updated November 5, 2024.
60% of web apps are vulnerable to cross-site scripting attacks. Let that sink in, more than half.
Access controls, specifically policy header misconfigurations, are a significant contributor to these vulnerabilities, an exploit included in the OWASP top ten list of vulnerabilities, despite being a known attack vector for nearly 20 years.
A joint study by Nato and Spanish Joint Cyber Defense Command found that a mere 4% or so of targets used secure policy headers from a sample of one million websites. That’s pretty scary, and this can easily be you, us, or anyone.
This is particularly troubling when the average data breach cost is around $9.44 million per breached organization in the United States. With this in mind, do you know how secure your digital assets actually are?
But fear not! This article will guide you through how to test your Permissions Policy Header configuration with OWASP ZAP, a best-of-breed open source tool, so you can better protect your organization.
What is OWASP ZAP?
The Open Web Application Security Project (OWASP) is a nonprofit organization that works to improve software security. One of its flagship projects is the OWASP Zed Attack Proxy (ZAP), a free and open-source web security scanner.
OWASP ZAP is an easy-to-use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed for people with a wide range of security experience, from beginners to experts. As such, it is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners and tools that allow you to find security vulnerabilities manually.
Here’s a quick list of some of the features provided by OWASP ZAP:
- Intercepting proxy server
- Traditional and AJAX Web crawlers
- Automated scanner
- Passive scanner
- Forced browsing
- Fuzzer
- WebSocket support
- Scripting languages
- Plug-n-Hack support
These together constitute some of the most common attack vectors for web applications today and can provide a pretty good understanding of your application's security posture and how to improve it.
Benefits of Using OWASP ZAP
We at Jit are big fans of open source security tools and make it our mission to make them easier to adopt and integrate into your CI/CD and common stacks. One of our favorite tools is OWASP ZAP, which provides so much value as a free and open-source tool. Some of these include:
- Ease of use. OWASP ZAP has a user-friendly interface and a comprehensive user guide that makes it easy to get started and derive value from OWASP ZAP.
- It is well-maintained. An important factor when selecting an open source tool is its maintenance. The OWASP ZAP community is a very active one, continuously working on new features and updates, so this tool is continually improving.
- It is cross-platform. OWASP ZAP runs on Windows, Linux, and macOS, so no more flame wars!
- You get a lot out of the box. We mentioned above the many features that OWASP ZAP comes with out of the box; this means that you can use OWASP ZAP for various testing activities with a single tool and not need to change the context or have too much tooling and dashboard fatigue.
- It is well-documented. Aside from having an active development roadmap, which is a critical piece when selecting OSS tools, it’s essential to know that it also has a good developer experience. OWASP ZAP provides extensive documentation, including tutorials and a user guide. You can find all the information you need to learn how to use OWASP ZAP pretty quickly and self-serve.
What is a Permissions Policy Header?
Now that we know why we should use OWASP ZAP let’s see how it works with a real-world and common use case like Permissions Policy Header configuration. A Permissions Policy Header is an HTTP response header that specifies a policy for using permissions in a web page or application.
Using these headers, developers can specify which permissions and privileges their applications should have and restrict which permissions and rights are granted to other web applications. This helps ensure that only the most trusted and well-behaved web applications can access sensitive data and functionalities.
If a malicious user can exploit a broken Permissions Policy Header, they can potentially gain access to sensitive information or even execute malicious code on the server.
Major exploits relating to vulnerable permission policy headers include password reset poisoning, the ability to bypass authentication, routing base SSRF, and web cache poisoning, which can lead to severe data leakage or other types of dangerous attacks on our systems.
Testing Permissions Policy Header configurations with ZAP
So let’s get started with a quick guide on testing Permissions Policy Header configurations with ZAP.
This guide will include:
- How to quickly set up ZAP
- A Quick-Start Guide
- Using its spider capabilities
- Manual permission review
- Inspecting the results
Let’s get to it.
Setting up ZAP
The first step is downloading OWASP ZAP from your operating system's source.
Once that's completed, run the installer and configure it based on your system requirements. If you need a more detailed explanation (as we said - ZAP comes with excellent tutorials), you can check out the docs here to get yourself set up with ZAP.
Starting ZAP
When you first start OWASP ZAP, you will see a screen that looks like this:
On this screen, you have two scanning here options to choose from, either the manual or automated scan.
The main difference between a manual and an automated scan is the user's level of control over the scan. The user can select which URLs to scan and manually review the results with a manual scan.
On the other hand, automated scans will automatically scan all URLs in the application and can be configured to perform more comprehensive scans.
Both manual and automated scans have their advantages and disadvantages.
Manual scans:
- Great for quick and easy scans
- The scan can be time-consuming if the application is extensive.
Automated scans:
- Great for comprehensive scans
- Can miss some vulnerabilities if not correctly configured.
In general, manual scans are best for small applications, and automated scans are best for large applications.
Spidering the web application
Spidering is the process of automatically crawling through a website to find all the links and sub-links. This method is used to find vulnerabilities in policy headers by looking for links that are not adequately secured.
OWASP ZAP's scans include the ability to detect insecure headers and provide you with meaningful snapshots of where the vulnerabilities are. Since we want to demonstrate the quickest way to mitigate this vulnerability, we’ll take the happy path and get started by selecting the ‘Automated Scan’ option on the welcome screen.
STEP 1: Add your target URL, which can be your local host if you target your own app.
Once you complete this step, you can begin the scanning phase.
STEP 2: This phase will allow ZAP to traverse and spider through the various domain paths and flag any vulnerabilities in red.
Exploring the Permissions Policy Header Manually
There are two types of scanning with OWASP ZAP - passive and active scanning.
Passive scanning does not interact with the target application, while active scanning does.
You can use passive scanning to identify issues such as unlinked resources and unhandled error codes. In contrast, active scanning can identify problems such as SQL injection and cross-site scripting.
Active scanning is generally more accurate than passive scanning, but passive scanning can identify issues that active scanning can’t, such as unlinked resources.
STEP 3: To inspect and explore issues discovered, click on the Alerts tab, expand the Alerts folder, and you will see a list of vulnerabilities found.
Inspecting the Test Results
Once we have completed the actual scan, we can then take a look at the findings OWASP ZAP uncovered in our application by attaching flags to each URL it encounters. The color code indicates the severity of the issue, with orange being medium severity and red chiming in for critical issues.
In the example above, the header was not set and posed a medium risk to cross-site scripting and data injections. These attacks are often associated with data theft and site defacement. OWASP ZAP also goes further and explains why it is a vulnerability and how to fix the issue.
With the help of OWASP ZAP, the spidering and active scan results returned 170 Content Security Policy (CSP) Headers that were not set, along with many other issues. The issues include missing anti-clickjacking headers, cross-domain JavaScript source file inclusion, and the absence of Anti CSRF tokens.
Make Security Simpler with Jit
Developers know that security should be a priority across the whole software development process, but it often gets sidelined when deadlines press down on the team. OWASP ZAP is helpful to identify and mitigate potential issues, but it is just one of the tools you need to make your application safe at all times.
Jit makes security easy and accessible for all developers by enabling easy access to all the security tools you need across your entire CI/CD pipeline (as well as other layers of your stack––from the code to the infrastructure), along with the expert security knowledge to define and implement an MVS security plan for your company.
Get started today and have Jit do the heavy lifting for you.
