False positive filter does not work

[Miguel]

I haven't found any topic related to this question so if it already has one please let me know.

I have an issue (not sure if it is my problem or a ZAP bug).

I have added some filters in the global alerts to mark false positives but some of the filters seems not to be working.

For example, I have these two filters that are exactly the same except one detail in the attack and in the evidence. One has an extra zero in the attack and in the evidence. When executing the tests one of of the alerts is marked as false positive but the other does not.

Do anyone know why this might be happening?

Filter 1: Attack: case randomblob(100000) when not null then 1 else 1 end
             Evidence: The query time is controllable using parameter value [case randomblob(100000)

Filter 2: Attack: case randomblob(10000) when not null then 1 else 1 end
             Evidence: The query time is controllable using parameter value [case randomblob(10000)

Thank you 

[Simon Bennetts]

We would need to know the details of the filters and the attack and evidence reported.

Details are key here, without them we would just be guessing.

While it could be a bug in ZAP, the most likely thing is that you've made a mistake in your filter definition.

You can test filters in the ZAP GUI...

Cheers,

Simon

[Forrest Eisenschmidt]

Hello, I have also recently experienced this issue and can supply some details. I am trying to create a false positive filter to get rid of an .htaccess alert. The other issues I created filters for were filtered successfully (CSP, Hidden file), but this one will not go away. The section of context file looks like this for .htaccess: 

<filter>true;40032;-1;;false;;false;;false;;false;</filter>

The Attack is on a URL that ends like this: ....../webrt/.htaccess

Parameter field was empty

The Evidence is that the app returns a 200:  HTTP/1.1 200

For the vulnerability itself, I get that the file is still there and returning a 200, so ZAP flags it. That makes sense. 

But if the context file has the filter of 40032, shouldn't it block any instance of htaccess from appearing at all? If the filter was set to global everything?

I did make some observations about filters, namely the version of ZAP makes a difference. If I make a filter in 2.14, its usually not backwards compatible with previous versions.  Even for issues that have not changed between versions. Forwards compatibility has less issues, but I have still seen this happen. I looked for any patch notes about this, but didnt have much luck. Nothing in the context file format has changed recently either, so I am not sure why version has so much to do with it. But this htaccess specifically has not worked in any version. 2.11, 2.12, or 2.14 from what I have tested. Do the labels of issues change much? Was htaccess not always 40032? I am curious to hear your thoughts. 

Also, I always appreciate how active you all are with this community. Rarely have I had to reach out about an issue, usually I find the answer very quickly.

[kingthorin+zap]

The filter you included seems to be missing a trailing semicolon.

The .htaccess rules has always been 40032

The only thing I can think of is that your context isn't actually matching the alert (the include regex.). You'd have to provide more specific details.

[miguel...@acin.pt]

Hi guys, sorry for just answering now.

I have the following  alert with medium level:

Description

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement or distribution of malware. CSP provides a set of standard HTTP headers that allow website owners to declare approved sources of content that browsers should be allowed to load on that page — covered types are JavaScript, CSS, HTML frames, fonts, images and embeddable objects such as Java applets, ActiveX, audio and video files.

URL
https://iv.pt/favicon.ico
Method
GET
Parameter

Attack

Evidence

Other Info

Plugin Id
10038

I have added a global alert like this:

Alert type: Content Security Policy (CSP) Header Not Set (10038)

New Risk Level: False Positive

URL: https://iv.pt/favicon.ico

HTTP Method: GET

Parameter: (nothing in this field)

Attack: (nothing in this field)

Evidence: (nothing in this field)

When running again the attacks this alert is in the list as medium level.

Also, if I add some global filters, some are catched and are marked as false positive, others don't, and I get more alerts than the first time. Is it normal?

Thanks.

[miguel...@acin.pt]

The alert information i have sent it's not from the initial alert for this conversation, because i don't have anymore the information regarding that one.

[kingthorin+zap]

I don't think I've ever seen an HTTP 441 before. I wonder if this is actually not coming from the server but from the browser not being able to deal with whatever the server sent.

Anyway I'll have more of a look at it.

[kingthorin+zap]

When you click "Test" on the filter (after the scans have run) what's the result?

On Tuesday, April 30, 2024 at 4:15:02 AM UTC-4 miguel...@acin.pt wrote:

I will give you this example I have produced yesterday.

Without filters:

With filters:

I have added all SQL injection - SQLite alerts, all Vulnerable JS Library alerts and all Content Security Policy (CSP) Header Not Set to the global alert filters as False positive.

For example, this alert filter did not move the alert from medium to false positive.

This is the alert after running the tests with the filters

[miguel...@acin.pt]

Clicking test i got this.

 

[Simon Bennetts]

"Applied to 0 alerts" - that means the filter did not match any of the existing alerts.

Try removing the fields you have set one at a time to find which one is not matching.

In theory it could be a bug, but its more likely to be a mistake in your configuration.

Cheers,

Simon

[miguel...@acin.pt]

If i have an alert like that has something like this in the attack field 

" field: [pageSize], value [(SELECT UTL_INADDR.get_host_name('10.0.0.1') from dual union SELECT UTL_INADDR.get_host_name('10.0.0.2') from dual union SELECT UTL_INADDR.get_host_name('10.0.0.3') from dual union SELECT UTL_INADDR.get_host_name('10.0.0.4') from dual union SELECT UTL_INADDR.get_host_name('10.0.0.5') from dual)]"

If i add the filter with only part of the attack it will catch the alert? 

Something like this:

" field: [pageSize], value [(SELECT UTL_INADDR.get_host_name('10.0.0.1') from dual union SELECT UTL_INADDR.get_host_name('10.0.0.2')"

Or I need to add exactly what is defined in the alert?

[kingthorin+zap]

Per the docs, it's an exact match unless you've used regex:

https://www.zaproxy.org/docs/desktop/addons/alert-filters/alertfilterdialog/#attack