The ZAP Blog

ZAP 2.11.0 (also known as the OWASP 20th anniversary release) is available now.

Major changes include:

Alert Tags

Alerts can now be tagged with arbitrary keys or key=value pairs - this can be done via the desktop GUI and the API.

Overview

File upload is becoming a more and more essential part of any application, where the user is able to upload their photo, their CV, or a video showcasing a project they are working on. The application should be able to fend off bogus and malicious files in a way to keep the application and the users safe. Generally file upload functionality is quite complex to automate and has huge attack surface hence there is a need to automate the process and also secure it. So the FileUpload add-on has scan rule which is used to find vulnerabilities in file upload functionality and this blog explains on how to use it.

With the popularity of JSON Web Tokens (JWTs) there comes the need to secure their use so that they are not misused because of bad configuration, older libraries, or buggy implementations. So the JWT Support add-on is used to find such vulnerabilities and this blog explains on how to use it.

GraphQL Schemas can be very large and testing them can be a very time-consuming process. Currently, there is a lack of tools that allow developers to launch and automate attacks on these endpoints. The GraphQL add-on for ZAP intends to fill this gap.

The add-on is still in an early stage, so the range of its functionality is limited. However, you can combine it with existing ZAP functionality to abuse GraphQL endpoints in many different ways.

ZAP full scan GitHub action provides free dynamic application security testing (DAST) of your web applications. DAST is also known as black-box testing, which allows ZAP to identify potential vulnerabilities in your web applications. We previously introduced the ZAP baseline scan GitHub action to passively identify potential alerts in a web application. However, unlike the baseline scan, ZAP full scan attacks the web application to find additional vulnerabilities.

Did you know that you or your company/organization could customize the generic details of the alerts that ZAP raises?

Alerts raised by ZAP contain a variety of information, some generic, some specific to the issue at hand. Specific details may include things such as URL, parameter, values, etc. While generic details include things like a description, solution, and links to related background material and resources.

With the increasing number of web application security breaches, it is essential to keep your web application secure at all times. Furthermore having security integrated into your CI/CD pipeline (DevSecOps) will become a lifesaver if you are actively developing the application. To cater to this need ZAP provides a baseline scan feature to find common security faults in a web application without doing any active attacks.

I’ve stated that ZAP is the world’s most popular free and open source web application scanner on stage at security conferences around the world for many years. No one has ever contradicted me so it must be true :)

However I’ve started to wonder if ZAP is actually more popular than most if not all of the commercial scanners as well?

Some vulnerabilities can only be found by sending payloads that cause a callback to the tester. One example is XXE vulnerabilities when the XML rendering result is not available to the user. ZAP can find these vulnerabilities that depend on SSRF detection but the target system needs to be able to reach the ZAP callback endpoint. In many cases the computer running ZAP is behind some kind of NAT and doesn’t have a public IP so it will not receive the expected callbacks and miss some of the existent vulnerabilities.

We release ZAP every week: https://www.zaproxy.org/download/#weekly

We’re happy to announce that this week’s release includes the first steps towards an all new dark mode for the ZAP Desktop UI:

It’s early days - not all screens use suitable colours, but it should be mostly usable. To enable it in the weekly release:

OK, OK, it’s been a long time since the last ZAP blog post. But we certainly have not been idle - since that last blog post we’ve published 3 full ZAP releases, well over 100 weekly releases and a shiny new web site: https://zaproxy.org/

Because we now have a new website we’ve decided to move our blog from https://zaproxy.blogspot.com/ to https://zaproxy.org/blog/. As part of that move all of the old blog posts have been moved to the new site and updated to fix some of the links that had broken.

We have just released a new feature for ZAP that allows you to launch browsers from within ZAP. The browsers are automatically configured to proxy via ZAP and ignore certificate warnings, making it much easier for people to get started with ZAP as well as for more experienced users who want to use ZAP with a variety of browsers. You can install and use Browser Launch right now via the ZAP Marketplace, which can be accessed via the ‘Manage Add-ons’ button in ZAP:

The previous ZAP blog post explained how you could Explore APIs with ZAP.
This blog post goes one step further, and explains how you can both explore and perform security scanning of APIs using ZAP from the command line.
This allows you to easily automate the scanning of your APIs.

APIs can be challenging for security testing for a variety of reasons.
The first problem you will encounter is how to effectively explore an API - most APIs cannot be explored using browsing or standard spidering techniques.
However many APIs are described using technologies such as:

• SOAP
• OpenAPI / Swagger

These standards define the API endpoints and can be imported into ZAP using 2 optional add-ons.

As modern web applications are increasing their reliance on JavaScript, security tools that do not understand JavaScript will not be able to work effectively with them.  ZAP already has components like the Ajax Spider and DOM XSS scanner that work by launching browsers and controlling them via Selenium, and we are planning to make much more use of browsers in the future.

Using ZAP during the development process is now easier than ever. We are proud to present the Jenkins plugin, it extends the functionality of the ZAP security tool into a CI Environment.

The process explained

1. A Jenkins CI Build step initializes ZAP
2. Traffic flows (Regression Pack) through ZAP (Web Proxy)
3. ZAP modifies requests to include Vulnerability Tests
4. Target Application/Server sends Response back through ZAP
5. ZAP sends reporting data back to Jenkins
6. Jenkins publishes and archives the report(s)
7. Jenkins creates JIRA tickets for the alerts

The ZAP Jenkins plugin makes use of the readily available and diverse ZAP API, allowing you to use the same session files and scan policy profiles between ZAP and the Jenkins plugin, so they can be interchangeably loaded.

Unit tests are wonderful things, but they are painful to add to a mature project that doesn’t have enough of them. We would love to have more ZAP unit tests, and we are therefore launching a Unit Test Bounty program, where we pay for unit tests for specific areas of the ZAP codebase.

ZAP 2.5.0 is now available.

This release contains a large number of enhancements and fixes which are detailed in the release notes.

API changes

There have been some API changes which are not backwards compatible, and the reason for the version change to 2.5. These are detailed in the release notes.
The API has also been extended to cover even more of the functionality in ZAP, including full access to the statistics.

Introduction

Welcome to the March newsletter, read on for some really good news, details of the new site level stats ZAP now supports and an introduction to scripting.

Introduction

Welcome to a slightly delayed February newsletter - we were holding on for some expected news that will now have to wait until next time ;)

Introduction

Happy New Year!
For the first newsletter of 2016 we have a special feature on a new vulnerability “XCOLD Information Leak” that caught the eye of one of our key contributors, how he found it and how you can use a new ZAP rule to detect it.

Introduction

Welcome to the second ZAP Newsletter.
And apologies for the delay - 2.4.3 took longer than expected, and last week I was away at a Mozilla work week.

Introduction

Welcome to the first monthly ZAP newsletter.
We plan to cover pretty much anything ZAP related in these newsletters, including newly created or updated add-ons, new features just implemented and 3rd party tools.
We also encourage contributions from people like yourself - see the last section for details.
Oh, and please let us know what you think of this newsletter via the Feedback Form!

The first online ZAP Q&A Session was held on Tuesday 13th October.

You can listen to a recording of the session here.

Please leave feedback via this Google Form.

Some links to resources mentioned in the session or related to the questions:

• The DOM XSS add-on
• The Context Alert Filters add-on
• The Revisit Add-on
• The Access Control add-on
• The vulnerabilities detected by ZAP
• How to set up form based authentication
• The community-scripts repo

Note that you can download add-ons from within ZAP via the Marketplace.

At OWASP AppSec EU in Amsterdam this year I announced ZAP as a Service (ZaaS).
The slides are here and the video will hopefully be available soon.

The idea behind this development is to enhance ZAP so that it can be run in a ‘server’ mode.
This is different to the current ‘daemon’ mode in that it will be designed to be a long running, highly scalable, distributed service accessed by multiple users with different roles.

Hello everybody, my name is Alberto Verza, a 23 year student from Spain, and this summer I have participated in Google Summer of Code 2014. My project was the SOAP Scanner add-on for ZAP, in which I worked during all the Program. Let me explain you the features it includes.

Welcome to a series of blog posts aimed at helping you “hack the ZAP source code”.
The previous post in this series is: Hacking ZAP #3 - Passive scan rules

Active scan rules are another relatively simple way to enhance ZAP. Active scan rules attack the server, and therefore are only run when explicitly invoked by the user. You should only use active scan rules against applications that you have permission to attack.
You can also write active scan rules dynamically using scripts, as we will see later in this series, but even then it’s very useful to understand some of the concepts underlying classes available to you.

Welcome to a series of blog posts aimed at helping you “hack the ZAP source code”.
The previous post in this series is: Hacking ZAP #2 - Getting Started

One of the easiest ways to enhance ZAP is to write new passive scan rules.
Passive scan rules are used to warn the user of potential vulnerabilities that can be detected passively - they are not allowed to make any new requests or manipulate the requests or responses in any way.
They typically run against all of the requests and responses that flow through ZAP.
Passive rules run in separate background thread so that they have as little effect on performance as possible.

Welcome to a series of blog posts aimed at helping you “hack the ZAP source code”.
The previous post in this series is: Hacking ZAP #1 - Why should you?

In order to change the ZAP source code you will need to set up a development environment.

Requirements

The following software is used/required to obtain and build ZAP (core) and the add-ons:

Welcome to a series of blog posts aimed at helping you “hack the ZAP source code”.

ZAP is an open source tool for finding vulnerabilities in web applications. It is the most active OWASP project and is very community focused - it probably has more contributors than any other web application security tool. It is being continually enhanced and, unusually for a security tool, has been translated into over 25 languages thanks to over 70 translators.
This series is designed to help newcomers dive head-first into the ZAP source code. However for this first blog post I thought I’d take a step back and give some reasons why you might want to change the ZAP source code in the first place.

We are getting close to releasing the next major version of ZAP.

As there are so many changes we’ve decided to go to version 2.0.0 rather than 1.5, and some of the biggest changes have come about thanks to the Google Summer of Code (GSoC).

This is the first year in which ZAP has taken part in the GSoC, and it has been a resounding success.

I’ve been struggling with the question of ZAP releases.
We’ve made loads of enhancements to ZAP recently, and I want them to be available to as wide an audience as possible.
But I also want to make sure our ‘full’ releases remain as robust and stable as possible.
I want to get the next full release (2.0.0) out of the door asap, but I still want to get a load more features into it.

The OWASP Zed Attack Proxy (otherwise known as ZAP) is a free security tool which you can use to find security vulnerabilities in web applications. My name is Simon Bennetts, and I am the ZAP Project Leader; there is also an international group of volunteers who develop and support it. Future posts on this blog will describe the features that ZAP provides and how you can use them, but this post will concentrate on the philosophy behind ZAP. Some of the ideals that have driven ZAP are listed below and will be expanded upon in the rest of this post: