Feature request - Add NOT operator in filters

[gk0us]

Add the NOT operator to use negative expressions such as:
NOT(STATUS == "500" && RESPONSELENGTH == "25")

This expression would hide all requests with a response code 500 AND length of 25.

[CoreyD97]

Hey, thanks for the suggestion!

The next release of Logger++ includes a much more robust parser and grammar for the filters and includes the NOT operator. However this is still in development while I'm fixing some major bugs before the release.

Thanks,
Corey

[CoreyD97]

Hey, I've released a beta release with the new grammar and various new operators and the ability to use NOT/! to invert filters.

https://github.com/nccgroup/BurpSuiteLoggerPlusPlus/releases/tag/v3.11-beta

If you have any issues or questions regarding its use please let me know.

[Shaddy]

Your job is well appreciated @CoreyD97 :)

I understand negating an expression is valuable, but cannot understand whats the difference between

!(STATUS == "500" && RESPONSELENGTH == "25")

and

STATUS != "500" && RESPONSELENGTH != "25"

maybe I'm missing something :/

[CoreyD97]

Thank you! :)

Sorry, not sure if by that question you're asking for the logical difference on why those two filters work differently, or as a design difference on why the negation has been implemented as !( ) also, so I'll answer both questions.

Logically:
!(STATUS == "500" && RESPONSELENGTH == "25")
is equivalent to
STATUS != "500" || RESPONSELENGTH != "25"

• So if your question is why such a filter gives unexpected results then that might be useful to you.

Design:
I decided to allow the use of negation filters like !( ) as well as combining != as everybody views logic differently. So they might be able to create a filter for what they don't want, but can't think how to invert this, so simply wrapping it with !( ) works for them.

Additionally, if you're creating large nested filters, being able to wrap a sub-filter in a negation can make the filter more readable than constructing the inverse filter.

Finally, I haven't yet made it possible to do things like:
Request.Body NOT CONTAINS "example", or Request.Extension NOT IN ["jpg", "png"]
Though a quick negation like:
!(Request.Body CONTAINS "example"), or !(Request.Extension IN ["jpg", "png"]
Give quick inverse results.

Hopefully that answers your question 😃

[Shaddy]

Hey @CoreyD97,

Thanks for your explanation. I was wondering if there was a different behavior because to me seemed the same sentence.

So if your question is why such a filter gives unexpected results then that might be useful to you.

But it does not, right? It should return exactly the same elements with both expressions.

Also, as said, it's valuable to be able to negate an entire expression but precisely the feature you commented is way more important. I mean, I can live without negating expressions but not with a contains comparison.

While negating an expression it's just a matter of thinking, using the expression IN or NOT IN its a significant filter reduction, so thanks for implementing it :)

[CoreyD97]

So the two examples you provided will result in a different output as:
!(STATUS == "500" && RESPONSELENGTH == "25")
is equal to
STATUS != "500" || RESPONSELENGTH != "25"
Note how the second is OR instead of AND. When a logical expression is inverted, the joining logic is also changed. This is one of De Morgans laws and is explained in more detail here.

Is there anything else you would like implementing for the filter?

Thanks,
Corey

[Shaddy]

Sorry, I did the obvious mistake inverting the operands. I pretended to have the || version.

I would only add a thing, but I think this is probably a different feature request.

To be able to describe filtering aliases. I would change Filter Library titles to become aliases instead (or adding a specific field for this).

So one may use, for example, a predefined filter e.g.

title	filter
SuccessfulPost	Request.method == post && Response.status == 200

Then a reference in the filter such as FL#SuccessfulPost can be directly referenced and combined with a more human-readable syntax.

If you find this interesting I can write a feature request as a different issue if you prefer it.

Thanks!

[CoreyD97]

That's a great idea! :)
If you can add that as a new issue I'll look at implementing that when I get the chance.