Make output more clear if the endpoint is or not vulnerable

[nrathaus]

At the moment the outcome of endpoint testing is very "human" oriented and very "grammar" sensitive, meaning that a person needs to read each sentence and use logic to understand if the endpoint is or not vulnerable, for example: Parameters are not vulnerable to SQLi Payload

vs One or more parameter is vulnerable to SQL Injection Attack

While this is very human way of describing the outcome, going over a report that has a few hundred or thousands of endpoint and trying to find which one are vulnerable is not an easy task

May I suggest two things:

1. Add a config option that allows returning only endpoints that have a vulnerability (it seems OFFAT returns everything)
2. Make the outcome True/False rather than textual, result returns True when not vulnerable is the opposite of what people would expect, maybe changing this to vulnerable field and returning True/False or adding a new field called vulnerable that will return True/False when its vulnerable

[dmdhrumilmistry]

Currently, OFFAT uses the same payload for every supported parameter while testing for SQLi and other tests. It may be difficult to come to a conclusion programmatically at the moment about which parameter caused it.

Initially, I thought It could help users to parse results, compare those and infer which APIs are vulnerable since they'll know their APIs. I'll implement a new tag -ov/--only-vulns which will only store vulnerable results.

Adding a new field vulnerable seems like a better option to me, since there are several components of the project which is dependent on the result.

[nrathaus]

You misunderstood me, today the way to know whether you are or not vulnerable is by text comparison, I suggest to just add a variable that says vulnerable to the end point

Regarding knowing which variable is vulnerable, instead of placing the payload on all the fields, we can do it one field at a time, yes it will add complexity and testing time - not necessarily a bad thing - but will allow you to better know which variable triggered the vulnerability

[dmdhrumilmistry]

You misunderstood me, today the way to know whether you are or not vulnerable is by text comparison, I suggest to just add a variable that says vulnerable to the end point

Regarding knowing which variable is vulnerable, instead of placing the payload on all the fields, we can do it one field at a time, yes it will add complexity and testing time - not necessarily a bad thing - but will allow you to better know which variable triggered the vulnerability

We already have the result (test result) variable which indicates whether the endpoint is vulnerable or not. I can add a variable but it'll be redundant and it'll also increase the results output size of JSON and other formats.

JSON Output:

CLI Output:

To make it more clear, what we can do is consider data leak in the overall test result.

[nrathaus]

I though result was whether the regex was successful or not, not necessarily that it is vulnerable

I think the word result word should be changed to vulnerable as it conveys better what it is - or change the UI to show vulnerable vs immune as failed and passed don't state that it is good or bad

At least that is my opinion

[dmdhrumilmistry]

Since people might get confused with the terms. I'll change result to vulnerable.