Web Application Definition 1.0.0

[psiinon]

I've just published the proposed Web Application Definition 1.0.0 here: https://github.com/ossf/wg-security-tooling/wiki/WebAppDefn

Feedback appreciated - either in this thread or email me: simon.bennetts@owasp.org

[fdegir]

My comment is not about the content of the document but how this type of contributions are expected to be made; I am wondering if they should be sent as a PR (eg. markdown file) to the repo to be reviewed and submitted?

[psiinon]

Yes, I could have done it that way, and would not have a problem doing that in the future. However I did circulate the doc https://twitter.com/irsdl/status/1293524289224941570 to people I knew would be interested - at the moment I doubt this repo has enough people monitoring it for effective feedback. We also discussed this in the last meeting on Tuesday which you attended and using a PR for feedback was not suggested then.
In any case, feel free to include any feedback you would have submited to a PR here instead :)

[fdegir]

Got it, thanks.

[coderpatros]

I think it would be good to support local docker files. And local docker compose files.

[psiinon]

So the local docker file would be an alternative to the docker registry - any tool using this could then build the docker image and run that. I like it :)

[coderpatros]

I'll raise a PR for this if you haven't already started.

[coderpatros]

I think auth could be bit of a showstopper for a lot of folks. If it's not in the initial version I think it needs to be pretty high priority for the next version.

[psiinon]

Thats a huge nut to crack. There are loads of authentications schemes in use and most of them are hard for automated tools to handle. No auth makes things so much easier. We could support some simple auth mechanisms sooner rather than later but I cant see us keeping everyone happy. This is something that should be done in development - make life easier for yourself by making your applications easy to test. At least thats the way I see it :)

[coderpatros]

It is a huge nut to crack. Otherwise this would already be quite simple to handle in my favourite open source DAST tool.

But, I think anyone who is interested in DASTing their app most likely has something being protected by a combination of authentication and authorisation. And testing an app as an unauthenticated user and as an authenticated user is important.

But maybe we can push the complexity of authenticating downstream. As in, here's a way to run something that will drop all the cookies needed for authentication. In a standard format that DAST tools could ingest and use.

I'm thinking something pretty agnostic, like run this script/docker image. And that way it could be anything. Like using selenium to go through the login process, etc.

But it's probably important to have multiple auth options for different users. As in, being able to run as an unauthenticated user, normal user, admin user.

[psiinon]

I'm all for that but I think thats trying to run before we can walk. Lots of people are using ZAP scans unauthenticated right now. If we cant get devs to adopt this without authentication then I dont think we'll be able to convince them to use it with auth, because either it will be really complex to set up or they will need to implement the integration themselves.

[coderpatros]

I don't disagree with you on that. I think it is much better to get something out that is easy to implement and get value from as soon as possible. But I think v1 of this should include handling for auth.

But I'm quite happy to respectfully disagree on that :)

It isn't an easy problem to solve and it shouldn't delay the initial release.

[coderpatros]

I'll open up a new discussion on handling auth.

[coderpatros]

Should there be an option to pass thru environment variables to the docker image too? I guess the stance could be that the image comes with sane defaults, but it would be pretty easy to add to the definition.

[coderpatros]

Although maybe you've got a point that I didn't understand initially. This file should provide the defaults required to test the target.

So maybe it should specify values that override the default values in the image?

[psiinon]

Yeah, I can see how it could be useful to specify values which override the defaults. Even with no-auth it could be possible to specify (for example) a header which authenticated as a specific user, and then being able to parameterise these could allow multiple roles to be tested.
I'm just worried that we could end up trying to solve the wrong problems. I think this version need to be as simple as possible. We can solve the problems people actually report in furture versions, if it takes off :)

[coderpatros]

100% I'm planning to start testing this out next week. Closed source targets, but a nice variety of projects.

Don't want to over-engineer it (that won't go well). Just spitballing.

[psiinon]

Great! I can definitely see how this can be really helpful for closed source targets as well. Thanks for all your feedback and be v interested to see how you get on. Theres nothing like actually trying something out on real world apps for finding holes ;)

[coderpatros]

My current stance on this is now that we shouldn't provide an option to override environment variables that are passed through to the running docker image.

Instead, if specifying a local docker file or docker compose file is supported this can be trivially handled there.

[duplys]

@psiinon , I really like the idea. IMHO it goes beyond web application security. As an example, we are doing quite a lot of fuzzing on various middleware components and other embedded software. And it's exactly the challenge you want to address with the web app definition: for every new project, you first need to find out how to reasonably connect a fuzzer to it, i.e., what functions to wrap and how to wrap them. A definition like the one you're proposing would be of great help. Is there any meaningful way to contribute?

[psiinon]

Thanks for getting in touch! With your involvement we can hopefully get this going again - I'll follow up with you via email...