Feature Request: Support Authentication Declarations in Web Fuzzing Commons (WFC) Format

[arcuri82]

Hi,

we are the authors of Web Fuzzing Commons (WFC) (https://github.com/WebFuzzing/Commons).

We are contacting the authors of all the major fuzzers for web APIs (at least 100 stars on GitHub) that are still maintained (ie, a new release in the last 12 months), to see if they want to join us in defining a common standard for declarative configuration of authentication information in fuzzing REST APIs.

Instead of authentication scripts, the idea is to provide info in YAML/TOML configuration files, and then let the fuzzers make the actual authentication calls.
This has few advantages: scripts can be reused between different fuzzers (useful for empirical comparisons) and require no coding skills for the users (e.g., testers). It also simplifies supporting test suite outputs in different formats (e.g., Python and Java).
A common standard agreed on by the main fuzzer developers would be beneficial.
Right now, we use it for the fuzzer EvoMaster. The authors of Schemathesis and CATS have joined WFC as well (e.g., see an example of discussion here)

cheers

WFC Team

[grebnetiew]

Hi! Looking at the examples, this seems doable, we already support authentication configuration files in yaml format, so we'd mostly broaden the accepted format :)

Browsing through the examples, I don't see one with explicit refreshing mechanics. We do have PUTs that require this (their login endpoint hands out tokens that last shorter than a fuzzing session, requiring us to query a different refresh endpoint when the expiry time is near). Could you show/add an example that shows this?

For reference, this is the documentation for the current format we use to specify this kind of authentication.

OAuth authentication

Wuppiefuzz supports OAuth authentication. You can configure it as shown below.

The username and password are sent (as a POST body) to the access_url endpoint, which should then supply the access and refresh tokens by setting a cookie.

The access token is parsed under the assumption that it is a JWT, and the expiry timestamp is checked before each request the fuzzer makes. If the access token is about to expire, the refresh_url endpoint is sent a POST request with an empty body, and the tokens as cookies. It should set a new access_token cookie.

mode: oauth
configuration:
  access_url: http://localhost:8081/token
  refresh_url: http://localhost:8081/token/refresh
  username: AdaLovelace
  password: VeryStr0ngPa$sw0rd
  extra_headers:
    - name: Referrer
      value: http://localhost:8081/
    - name: ClientID
      value: 1234abcd
  mode: Cookie

The mode parameter can be set to cookie, if the access token should be sent as a cookie with each request, or authorization_header, if it should be a Bearer token. Refreshing is done via cookie in both cases.

[arcuri82]

hi @grebnetiew,

great to hear it ;) Among the developers of WuppieFuzz, will you be the representative? (in the past I had some chats with @ThomasTNO ). I can add (ie send invitation to join) just you, or both of you, to WFC. Let me know what you prefer.

Regarding refreshing mechanics, no, it does not look like we do support it in WFC specs. That would be a great first contribution ;) ie, you could propose a change to WFC specs file via a PR, and then we can discuss among the different fuzzer developers (if you agree)

[grebnetiew]

Excellent. You can add Thomas and myself both, this improves the bus factor if we ever take vacations :) I've done work on auth in the past, so I'll probably take this particular issue / investigate what's needed on our end to support WFC specs.

[arcuri82]

invitations sent ;)

[arcuri82]

@grebnetiew @ThomasTNO great to hear it ;)

btw, at a certain point, i would like to do some study on the use of WFC in different fuzzers that implement/support it. this could lead to a joint academic articles if you are interested

[grebnetiew]

Great! Definitely keep us posted :)

[ThomasTNO]

@grebnetiew @ThomasTNO great to hear it ;)

btw, at a certain point, i would like to do some study on the use of WFC in different fuzzers that implement/support it. this could lead to a joint academic articles if you are interested

I would definitely be interested to contribute