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.
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:
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.
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:
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.
So let’s get started with a quick guide on testing Permissions Policy Header configurations with ZAP.
This guide will include:
Let’s get to it.
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.
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.
In general, manual scans are best for small applications, and automated scans are best for large applications.
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.
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.
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.
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.