Web Application Testing: PortSwigger Burp Suite vs OWASP ZAP

Both OWASP ZAP and Portswigger Burp Suite are exceptional tools designed to identify vulnerabilities in web applications. I’m one of those oddballs that prefer ZAP over Burp Suite. Most (95%) of penetration testers and application security engineers prefer Burp. We’ll dive into the history and differences below.

History

OWASP ZAP is an open-source web application security scanner. Ideal for beginners and intermediate users, it offers an intuitive user interface and a wide range of features. ZAP is particularly known for its active and passive scanning capabilities, spidering, and a powerful REST-based API. Being a community-driven project, it's continuously updated with new features and security tests.

I started using ZAP when I was asked to stand up an application security program for an agency I was employed at in South Carolina. I knew nothing about application security but quickly found the Open Web Application Security Project (OWASP) and a free tool for testing applications the Zed Attack Proxy (ZAP). With the tool I found my first vulnerability, blind SQL injection, which kick started the application security program at the agency. Nearly a decade later the developers are still using ZAP to test their applications prior to it going to production.

According to ChatGPT:

Burp Suite, developed by PortSwigger, is a more comprehensive suite of tools. It includes an advanced set of features like detailed manual testing tools, automated scans, and the ability to save and resume sessions. Burp Suite comes in various editions, with the free version offering basic functionalities, and the professional version providing more advanced capabilities.

This is the view of most professionals within the testing space of security that I’ve interacted with. A lot of this comes from the history of ZAP which was a fork of another open-source proxy called Paros Proxy. Development is no longer done on Paros but ZAP is still being developed and has a lot of community support.

A lot of the features mentioned about by ChatGPT ZAP has as well. The tools are 90% the same with some slight nuances in functionality. Either tool will test an application sufficiently.

ZAP vs Burp

ZAP was written by a developer named Simon Bennetts. I had the pleasure of having Simon on for the eighth episode of Exploring Information Security. I’ve used Burp throughout my career. First as part of training courses such as Tim Tomes’ Practical Web Application Penetration Testing (PWAPT). I tried it as part of my day-to-day work but I would usually fall back to ZAP. I found the interface of ZAP more user friendly and I’ve heard people who prefer Burp confirm that they liked some of the organization of the interface.

Burp is still a fine tool it just takes a little more time to get used to the interface. Having used ZAP that was just my preference. I’ve used both in assessments and found the findings very similar. The plugin ecosystem is a more robust but ZAP has plugins and they are kept up-to-date regularly. Both are well documented tools and easy to go through and learn. Portswigger offers a lot of free online resources for learning how to use the tool better and is probably a large reason why a majority of testers use it.

I like ZAP for developers because it was written by a developer and it’s free. Burp has a community version but it’s automated scanning is rate limited unless you have the paid version. You can get the testing done it just takes longer. One of the features I’ve heard proponents of ZAP appreciate is the Forced Browse feature which does a good job of finding directories in an application.

Final thoughts

Either tools is good for testing web applications. It really comes down to preference and the situation a person is in. If you’re looking to get developers more involved in testing ZAP is a great fit. If you’re looking for a specific plugin for testing Burp will probably have it. Results are going to be very similar.

What’s your preference for web application testing tools?

This blog post first appeared on Exploring Information Security.

Created with the help of ChatGPT

Pragma and Cache-Control

I’d like to start posting more on my website. One of the ideas I had for doing that is to write about some of the more obscure things in application security. My career has been almost entirely on the job training. This comes with the challenge of trying to understand explanations that sometimes don’t state obvious ideas and concepts. I’d like to cover some of those obscure topics and really dig into them. In the process I’d like to try and answer them in a way that my younger self can understand. I’m hoping this will provide others with a simpler explanation while helping me to better understand the concept.

To kick it off, I’d like to cover pragma and cache-control. The reason why is because I see this regularly in reports from ZAP, “Incomplete or No Cache-control and Pragma HTTP Header Set.” It’s a low or information finding and it usually shows up in a lot of places. I did some research to better understand the finding several weeks ago.

What is pragma and cache-control?

Both are header settings for the browser. Before we get to far, I guess I should explain what are HTTP header settings. These are settings that the application will communicate to the browser to determine how they interact together. In the case of pragma and Cache-control the application is telling the browser not to cache any content or don’t keep any content pulled down in the browser after leaving the site. The reason is so that sensitive information doesn’t get stored in the browser for a malicious actor to take advantage of if the person’s computer is compromised. For a more in depth explanation on HTTP headers check out this article, HTTP Headers for Dummies.

Pragma is an older header setting for HTTP/1.0. Cache-Control is the newer header setting for HTTP/1.1. What that means is that pragma is used to control cache for older browsers. If older browsers are being supported by the website or application then setting that is important to ensure sensitive information isn’t being stored. If older browsers are not support then just cache-control is used. In some cases you may have both. The Mozilla Developer Network has a pretty good explanation. There’s also a good explanation and discussion on Stack Overflow if that’s your thing.

How and where to set pragma and cache-control?

Where the header settings will depend on the application and what is being sent as content to the browser. The only setting for pragma is no-cache. Cache-control has more directives to set for flexibility. Max-age and revalidation are two directives that can be set. The browser will have to stick to those settings. The recommendation I’ve seen is to set pragma with no-cache and cache-control with no-cache, no-store, must-revalidate, and private.

These settings are set in either code or on the server. How implementation is done depends on the language and technology used by the application. Google is a good place to look for how to set these settings based on those factors.

Simple as that.

Hopefully, this clears up some confusion for people. Writing this down has helped me understand it a little better. I hope to do more of these types of articles in the future. I would love feedback on this post. Also feel free to drop a comment if I missed something in the explanation.

References:

• https://code.tutsplus.com/tutorials/http-headers-for-dummies--net-8039

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Pragma

• https://stackoverflow.com/questions/10314174/difference-between-pragma-and-cache-control-headers

• https://github.com/zaproxy/zaproxy/issues/2405

• http://www.bitordertech.com/resources/blog/73-how-to-use-the-zap-scanner-tool-a-practical-example

This blog post first appeared on Exploring Information Security.