alertFilter documentation could use some clarification

[mdem99]

Describe the bug
The ZAP daemon analyzes traffic from contract tests in the pipeline and produces a report. We are getting some "false positives" or defects that are already in WIP and would like to declassify them to informational threats.
The alert filter gives a "request: ok" but the filter is not afting the report in any way, ergo, it is not working.

To Reproduce
Steps to reproduce the behavior:

1. Have in a repository a gitlab-ci file with a stage for ZAP, and ZAP running as a GitLab service
2. Set up an infrastructure where you run contract tests or e2e tests, and use a proxy variable to divert traffic to ZAP Daemon
3. After everything is set up, add a script file, before the tests, to configure the filter
4. Add a script with CURL request to save the report
5. Check the report to see that there is no change or affection due to filter alerting

Expected behavior
The alert filter should impact the results of the report and reclassify a threat. In my case, I wanted to classify this threat as False Positive.
The request (with fake URL):
curl -X -4 --retry 2 --retry-connrefused --retry-delay 3 http://zap:8090/JSON/alertFilter/action/addGlobalAlertFilter/?ruleId=10098\&newLevel=-1\&url=https%3A%2F%2Famazonaws.com%2Fapi%2Fv1%2Fpings\&parameter=Cache-Control\&enabled=true\&evidence=
Screenshots

Software versions

• ZAP: Docker stable:latest and/or weekly:latest images (same problem for both)
• Add-on: standard
• GitLab - Pipeline
• Usage: Docker as Gitlab service (reference)

Errors from zap.log file
The zap.log file is not accessible. Reason. I don't have a personal Docker coitaniner running, but I'm pulling a new image every time (since I'm using it a service).
For debugging I am using config "api.incerrordetails=true".

Additional context
My findings:

1. with the error reporting option I only got: missing parameter "newLevel". After hours of troubleshooting I found that actually the problem was escaping (the parameters were concatenated with &, I just added "\ &")
2. I first passed the affected url with the escape, no result. I passed it in "clear" text, no result. So it seems to accept both (or not correctly interpret both)
3. In the local daemon, with my pc, i can choose between get and post methods. So I tried sending a CURL POST request, as a url and as a JSON. Both returned an error ({"code": "content_type_not_supported", "message":"!api.error.content_type_not_supported!"}
4. I'm working with the global filter. I also tried context-based but it requires a real context id which I don't know.
5. From the code of ZAP, it seems that only 2 parameters are actually required: ruleID and newLevel
6. With the Weekly-Relase the report looks different. There is a new field called "parameters" and a new section for false positives. Due to the loss of documentation, I can't figure out if the alert filter is based on the stable image or the weekly image and how to properly set the new parameters.

**Would you like to help solve this problem?
This seems to be a really strange behavior and it would be very important for me to get it working, so yes, I would also like to help if I can.

[kingthorin]

The URL in the command doesn't match the URL is the screenshot. Note the "new2" portion, also the blacked out portion seems to be much longer than simply amazonaws.com/

[mdem99]

As i wrote, i had to mask it because it's a real url that i'm testing here. So i can ensure that the URL is matching ;)

[thc202]

Did you check what is ZAP receiving?

[kingthorin]

I was able to recreate this. I added a Global Filter via the API (with ZAP running in GUI mode) and it didn't apply (even after refreshing the Alerts tree). If I went into Options and Modify > Test it would match 1 alert (as I expected). When I applied from the Modify screen then the alert was actually updated.

Edit: I didn't test reporting.

[mdem99]

The problem is how i can access options etc from docker, should i set something with -config?

[mdem99]

Did you check what is ZAP receiving?

I didn't quite understood the question but the connection ci-zap is working. I get the report and i can send the curl request to set the filter and by doing a query, i got the filter back with my inputs. So ZAP is receiving my commands and traffic correctly

[kingthorin]

You can use the API view globalAlertFilterList to see what's actually been set.

[mdem99]

You can use the API view globalAlertFilterList to see what's actually been set.

as you see from the second screen, the filter is set

[kingthorin]

@psiinon @thc202 I believe in this block: https://github.com/zaproxy/zap-extensions/blob/54417192ee6ea0d92cd60fdf7c1ebc1c90bac2fe/addOns/alertFilters/src/main/java/org/zaproxy/zap/extension/alertFilters/AlertFilterAPI.java#L249-L274 at either 266/267 or 268/269 this needs to do a extension.applyAlertFilter(af, false); (probably the same for the non-Global additions as well).

Do you agree?

[psiinon]

Yeh, def worth trying - good spot

[thc202]

Aren't the alert filters supposed to be applied to new alerts?

Maybe add a parameter or a new endpoint, to keep the expected behaviour.

[psiinon]

thats true, the API wasnt intended to support applying them to existing alerts, although it could be extended to do so

[kingthorin]

Okay I'll add an apply endpoint.

[psiinon]

But that wont solve this issue will it? If the filter is being correctly applied before the alerts are raised then it will make no difference...

[kingthorin]

Will have to test further.