PostHole
Compose Login
You are browsing eu.zone1 in read-only mode. Log in to participate.
rss-bridge 2023-06-14T20:29:00+00:00

SE Radio 568: Simon Bennetts on OWASP Dynamic Application Security Testing Tool ZAP

Simon Bennetts, a distinguished engineer at Jit, discusses one of the flagship projects of OWASP: the Zed Attack Proxy (ZAP) open source security testing tool. As ZAP's primary maintainer, Simon traces the tool's origins and shares some anecdotes with SE Radio host Priyanka Raghavan on why there was a need for it. They take a deep dive into ZAP's features and its ability to integrate with CI/CD, as well as shift security left. Bennetts also considers what it takes to build a successful open source project before spending time on ZAP's ability to script to provide richer results. Finally, the conversation ends with some questions on ZAP's future in this AI-powered world of bots.

Simon Bennetts, a distinguished engineer at Jit, discusses one of the flagship projects of OWASP: the Zed Attack Proxy (ZAP) open source security testing tool. As ZAP’s primary maintainer, Simon traces the tool’s origins and shares some anecdotes with SE Radio host Priyanka Raghavan on why there was a need for it. They take a deep dive into ZAP’s features and its ability to integrate with CI/CD, as well as shift security left. Bennetts also considers what it takes to build a successful open source project before spending time on ZAP’s ability to script to provide richer results. Finally, the conversation ends with some questions on ZAP’s future in this AI-powered world of bots.

Show Notes

SE Radio Episodes

  • Episode 467: Kim Carter on Dynamic Application Security Testing
  • Episode 474: Paul Butcher on Fuzz Testing
  • Episode 427: Sven Schleier and Jeroen Willemsen on Mobile Application Security
  • Episode 387: Abhinav Asthana on Designing and Testing APIs
  • Episode 474: Paul Butcher on Fuzz Testing
  • Episode 514: Vandana Verma on the Owasp Top 10
  • Episode 475: Rey Bango on Secure Coding Veracode

References

Twitter: @jit_io

LinkedIn: https://www.linkedin.com/company/jit/

Transcript

Transcript brought to you by IEEE Software magazine.

This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.

Priyanka Raghavan 00:00:16 Hello everyone, this is Priyanka Raghavan for Software Engineering Radio, and today we’ll be discussing OWASP ZAP, which stands for Zed Attack Proxy, a security testing tool with our guest, Simon Bennetts. Simon is a distinguished engineer at Jit and released ZAP in 2010. He has worked on nearly every part of ZAP’s code base and he’s given several talks and tutorial on ZAP, which are available on the official documentation page. You can probably hear a lot of excitement in my voice because I’m a big fan of his work. So it’s great to have you on the show and welcome.

Simon Bennetts 00:00:53 Thank you very much. Thank you for inviting me. It’s a pleasure to be here.

Priyanka Raghavan 00:00:57 We have done two episodes on OWASP and dynamic application security testing, episode 467 with Kim Carter on Dynamic Application Security Testing and episode 514 with Vandana Verma on OWASP Top 10. So maybe we can start right at the top, Simon. And the first question I wanted to ask you is, what is dynamic application security testing, which we can keep talking about and does ZAP fall under this category?

Simon Bennetts 00:01:36 So yes, ZAP is a dynamic application security testing tool, otherwise known as DAST. And there’s quite a few different types of security testing. As you well know. There’s static security testing and that’s where you’d look at the source code and you can see certain, there’s types of vulnerabilities you can find that way. ZAP doesn’t work in that way. ZAP doesn’t look at the source code at all. It actually looks at the running application. So this is, I wouldn’t say that DAST is better than SAST or vice versa, they’re just different ways of approaching the same thing. What we’re trying to do is find vulnerables in applications. ZAP is focused on web applications and what ZAP does, it interacts with the application via http, https, web sockets, all those web technologies. So, ZAP does attack your application if you tell it to — it’ll only do what you tell it to do — but in some ways you can think of it like it’s trying to do the same things as a malicious attacker. So somebody who knows about web vulnerabilities and tries to attack your application. Now ZAP tries not to do any damage, but I have taken out many websites in the past, unintentionally. So we don’t try and delete data from databases, but ZAP can put quite a lot of strain on websites, particularly if they’re not used to a lot of traffic. So it can be tricky. So you should, we should stress, you should only use ZAP on applications that you have permission to test or that you yourself own.

Priyanka Raghavan 00:03:04 Yeah, I think that makes a lot of sense. And also a good warning to our users that definitely try to make sure that you have permissions to test what you’re producing. Maybe as a software engineer it’s probably okay to use ZAP, but then make sure it’s only in the dev environment. Okay. The other thing I wanted to ask you was, I was reading somewhere in one of these blogs that said that ZAP was actually born out of a need for testing an application that you were working on. So can you tell us a little bit about that?

Simon Bennetts 00:03:36 Sure. So my background is software development. So this is in 2009. I was a developer and team lead. It was a small team, and we were developing an online application for a FTSE 100 company in the UK. So that’s one of the top 100 companies. And we knew it was security critical. So we planned around that and we implemented the service and a couple of weeks before it was supposed to go live, we got the penetration testers in just to — the whole idea was this was as far as I was concerned, yeah, it was a tick in the boxing just to prove we’d done everything right. It didn’t quite work out that way. So, got a couple of guys in and explained everything about the service because I knew they’re on our side. We wanted to find any vulnerabilities before it went live, obviously. Put them in a room, explained everything and let them get on with it.

Simon Bennetts 00:04:27 And went back an hour later just to see if I could explain anything, if there’s anything they didn’t understand. And I still remember walking into that room and seeing one of the pen testers logged into the admin console with my credentials. They shouldn’t have had those, they had, he had got super user access to the service. That was a problem. It was actually worse than that because although it wasn’t actually a vulnerability in the service I developed or my team developed, that actually cracked the single sign-on service for the whole company. This is a FTSE 100 company. They had cracked the single sign-on service in one hour. This was a bit of a wakeup call. It’s at that point I thought, okay, this week is not going to go the way I hoped. And at the end of the week, it seemed like a car crash.

[...]

Original source

Reply