Add a way to specify combinations of OpenAPI parameters to fuzz via extension field

[mpoindexter]

I am not sure if this is the best way to go about this, but I'm opening this PR to see if you think this is a good idea. Basically, the problem I am trying to solve is that some REST APIs I am trying to test have certain combinations of parameters that are valid. This means that the current approach of filling in all the parameters that are discovered in each operation won't work, as the testing never gets past the validation phase.

My solution to this: add an extension field to the operation in the Open API spec, that if present will further refine the request that w3af creates. A good example is in the test case I added, but basically the extension parameter x-w3af-request-templates contains a list of overrides to the operation it is contained in. When this is encountered, each override is applied, and a separate fuzzable request is generated for each one.

As an example, say I have an API that is available at http://www.example.com/products/search. This API can take exactly one query string parameter from the set of {name, description, price} to search by the specified parameter. If you specify a search by multiple criteria a validation error will occur. Right now there's no way to teach w3af about this (or many other restrictions that are described in text but not expressible in swagger like dependencies between parameters, etc). With this change I can write something like:

<snip>
"/products/search": {
  "get": {
    "parameters": [
      <definition for name, required=false>,
      <definition for description, required=false>,
      <definition for price, required=false>
    ],
    "x-w3af-request-templates": [
      {"parameters": [<definition for name, required=true>]},
      {"parameters": [<definition for description, required=true>]},
      {"parameters": [<definition for price, required=true>]}
    ]
  }
}

to teach w3af about the combinations of parameters that can work together.

[mpoindexter]

@artem-smotrakov you seem to have worked a lot on the Open API stuff in w3af, curious what you think about this.

[artem-smotrakov]

@mpoindexter I think it's a valid case, and it's good to have such a feature.

I would suggest to define combination of parameters in a separate file, so that a user doesn't have to modify the original spec. You can check out #17339 which introduces a way how a used can can provide custom values for parameters in a separate YAML file. But that PR doesn't allow to set valid combitations of parameters. Unfortunately it's not merged yet.

[mpoindexter]

@artem-smotrakov - maybe it would be good to support both reading this out of the open api spec and from an external file? For me I'm either putting it in the swagger spec when I generate it, or I've already got to clean up the swagger some before feeding to w3af and it's easier to just put it in then, but I can see how having it as an external file is better for some people.

[andresriancho]

I try to do my best with PRs, but got limited time, sorry for the delays, will try to review this one during the week.

[andresriancho]

@mpoindexter could you please resolve the conflicts? I believe they appeared after merging another PR