A comprehensive registry of known vulnerable web and mobile applications for legal security testing and training.

A group of OWASP leaders and contributors believe it needs to evolve. Now.

Have you tried using OWASP ZAP? We're focusing on automation and feedback gratefully received. I'm also on the OpenSSF Security Tools Working Group and making security tools easier to use is definitely one of our priorities

First of all great product, I found a lot of XSS when using the GUI. Also I managed to get this scripted with zap-cli with an unauthenticated scan, not too much work. I don't like to complain about specific open source project so please take this as feedback.

I gave up on trying to do an authenticated scan. Docs/ Forum answers always say "First get it to work in the GUI, then try running on command line." Well that's not helping me very much, because "getting it to work in the GUI" is not reproducible and shareable in the same way as a code/script showing clear steps. Secondly, getting authenticated scans to work when your login form is protected by a CSRF token is very much not trivial (don't think I got this to work in any tools). But if your forms are not protected, you have a vulnerability.

My feeling is that the right kind of tool is really a library, so that one can script the login process which may be quite complex with 2FA.

Regarding 2fa - For TOTP there is a Linux command line tool called oathtool. For SMS, set up Twilio. For U2F you can emulate a device with an ECDSA library.

For CSRF you'll want browser automation, like Chrome Headless. Alternatively, you can load a page and extract a token from the DOM in a normal scraper.

>To be honest it feels like vested interests are keeping it that way: professionals want to keep the tools manual so they can charge by the hour;

As a security professional, get out of here with that non-sense. You've run into a challenging problem and still think there is some conspiracy. What we do is highly technical and often customer specific (e.g. automate 2fa due to some weird requirement rather than the customer disabling it for the test account). There is no market in automating a lot of this work, packaging it in a nodejs library for you to use, and writing docs.

My "challenging problem" is that I use CSRF tokens, which is a minimal requirement of any non-toy project.

I haven't tried it in Zap, but there is definitely a Burp add-on that takes care of this for you. Probably several.

Zap is pretty scriptable as well, so there are likely solutions for it also. What have you tried?

There's been an open source option for 10 years - ZAP :)

But seriously, have you ever tried zap against burp? Like all owasp projects, the idea is awesome and there is an excellent community behind it but the execution stopped being anything useful years ago. I really think owasp and ‘free’ are what gives zap it’s base. But a base isn’t the same as relevant.

Burp is with all it’s faults is still so much better in every aspect. If you just discard any technical feature, just the workflow from start to finish shows zap being build BY developers and burp being build FOR hackers. This alone explains why every serious security professional you will ever meet will swear to burp. This doesn’t mean that there is no usecase of course. It’s probably still relevant in the training area and it is included as an ‘automated’ dast/scanner in many cicd pipelines for cheap and preventing low-hanging fruit.

Hetty looks promising so far and competition will drive the overall quality of this niche.

It's called Reverse Tabnabbing on OWASP: https://www.owasp.org/index.php/Reverse_Tabnabbing - lots more details there. Its detected by the ZAP beta passive scan rules: https://github.com/zaproxy/zap-extensions/wiki/HelpAddonsPsc...

Thanks :) Let me know what you think of it - feedback very much appreciated!

Well, burp suite is a bit like some parts of ZAP :) Theres an overlap, but ZAP is completely free and open source. It was originally a fork of Paros (now much extended) which actually predates burp.