![]() ![]() ![]() The Zed Attack Proxy (ZAP) is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. This is done with the -zap-import-json-results command-line flag. If you're already running ZAP, and just want to unify your ZAP and Mayhem for API issue reporting, you can also ingest ZAP result json into a run, instead of having Mayhem for API invoke ZAP for you. So: we don't include ZAP results by default, but we make it easy for you to get them periodically. Their results-while interesting and useful!-tend to require developer triage, which (usually) makes them unusable as a CI/CD gate. ZAP, on the other hand, reports on everything it finds that might be an issue. This means we work very hard only to report issues which we are certain are genuine and resolveable. We're committed to making Mayhem for API, out of the box, a tool API developers are happy to use every day, and happy to add as a gating step in their CI/CD pipelines. As a result, by default, we filter these out! You can use the -zap_min_risk_code flag to adjust the default, if it's not what you want. Second, in our experience, the lowest-risk ZAP alerts had a terrible signal-to-noise ratio when applied specifically to an API. To map ZAP results into our model, therefore, we create an endpoint-associated issue for each distinct "instance" of each ZAP alert. Mayhem for API, being API-oriented, likes to organize issues by endpoint. In order to fit the Mayhem for API data model, we transform and filter the raw ZAP results in a couple of ways.įirst, ZAP issues are organized differently: there are alerts (roughly analogous to Mayhem for API "rules") and there are one or more "instances" of each alert. While Mayhem for API supports several authentication methods, only -header-auth is currently propagated correctly to ZAP. ZAP hasn't yet implemented OpenAPI 3.1 support.Īny other spec format accepted by Mayhem for API (OpenAPI 2.x, OpenAPI 3.0, Postman and HAR) should work, but if your spec is using OAS 3.1 features, ZAP won't work with it until they update their support. it's not a requirement for running Mayhem for API in general. Our integration with ZAP relies on a working Docker environment (it's just the easiest way, by far, for us to manage all of the transitive dependencies of the ZAP toolchain.) This dependency is specific to the -zap flag, i.e. The full ZAP suite looks at web applications as a whole ZAP API Scan and Mayhem for API are more narrowly focused on API back-ends. It's worth pointing out that the tool we've integrated with, ZAP API Scan, isn't the full ZAP suite: it is a subset of the ZAP suite which, like Mayhem for API, is driven by an API specification. Read on if you want some of the technical details, or more advanced options, but really: that's it. Just add a -zap flag to your existing invocation: mapi run -zapĪnd you should see ZAP issues reported alongside Mayhem for API issues, like so: The tools complement each other so well, in fact, that we built a super-easy way to run ZAP's API Scan tool alongside Mayhem for API. We believe they're complementary: if you already run ZAP against your API, you'll get substantially deeper coverage using Mayhem for API, and if you already use Mayhem for API, ZAP is likely to report lots of potential problems, especially configuration and operational problems. ZAP's priorities and approach are quite different from Mayhem for API. The OWASP Zed Attack Proxy, or ZAP, is an open-source web app scanner, and the de-facto industry standard for automated security scanning of web applications. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |