I’ve always had side projects but at that time I had never contributed to open source. I decided it was a good time to start contributing, so I looked around for an open source security tool with an active community.
Unfortunately I couldn’t find one.
OWASP had WebScarab, but I didn’t really get on with that, and in any case development on that seemed to have stopped. The tool I most liked was called Paros Proxy - it was simple, effective and did what I needed. It was also written in Java so it wasn’t long before I pulled it into Eclipse and started making some tweaks.
In 2009 I was a Java developer / team leader and led a small team which developed an online service for a major accounting software company.
As this service was considered to be security critical I insisted that an external pentest team was hired to ensure the software was suitably secure. To be honest I wasn’t too worried as we had seriously considered security throughout the process so I was fairly confident that the report would just show what a good job we had done.
While I was still finalising the first ZAP release someone else beat me to it 😟.
After years of being neglected, Paros was also forked by Axel Neumann who called his version AndiParos.
I’ll have to admit that I was very disheartened and seriously considered abandoning my plans for ZAP.
I find naming things hard. It is easier if the tool has a very specific purpose, but ZAP has lots of uses.
When I was a developer I always wrote command line scripts. If I thought I might need them again then I would call them something sensible, something that would help me find them again. But I also wrote one off scripts that I knew I would never use again. I always ended up calling those scripts “zap” or “pow” - think of cartoons: “ZAP! POW!” I struggled with names for my fork of paros proxy and I kept on thinking of those two options.
ZAP 2.11.0 (also known as the OWASP 20th anniversary release) is available now.
Major changes include:
Alerts can now be tagged with arbitrary keys or key=value pairs - this can be done via the desktop GUI and the API.
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?
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:
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.
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.
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.
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.
Welcome to a slightly delayed February newsletter - we were holding on for some expected news that will now have to wait until next time ;)
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.
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.
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:
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.
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.
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: