One emoji gets blocked while another doesn't

, ,
1

Hi folks!

We use Airlock Microgateway versions 4.1 (prod) and 4.2 (test) in our k8s environment.

With both version I observed something I don’t quite understand: one emoji gets blocked while another doesn’t.
This one gets blocked:

...
"query":"subject=nochmals%20ruf%20emoji%20%F0%9F%99%8B%E2%80%8D%E2%99%82%EF%B8%8F"
...
"deny_rules":{"matches":[{"threat_handling_mode":"block","rule_id":7,"blocked_data":{"parameter":{"name":"subject","value":"nochmals ruf emoji 🙋\u200d♂️"}},"rule_key":"SANITY","level":"standard"}]}}
...

This emoji seems to be allowed: :thinking:
Here the URL parameter “subject” in my test is: "The 2 - Mit emoji im Betreff :thinking: "

Why do some emojis trigger the SANITY rule while others don’t?

Thanks,
Markus

1 Like
2

Hi Markus

Thank you for reporting this block which we are currently analysing. Maybe the deny rule is a bit too aggressive. Because of that one of your emoji is blocked. In case that we come to the conclusion that the deny rule is too aggressive we will update our rules in a future version.

For the time being simply configure a deny rule exception.

Cheers
Stefan

3

Hi Markus

Your string is not blocked because of an emoji, but because of the code point 200D, which is E2 80 8D in UTF8 (U+200D Zero Width Joiner (ZWJ) Unicode Character). The filter sanity rules block all non-printable characters except whitespaces and some other special cases. Non-printable characters can be dangerous as they can be used to bypass other filter rules.

We will review the use of 200D and determine if the code point is dangerous. If not, we will relax the rule. In the meantime, please configure an exception as Stefan wrote.

Update: 200D seems to be a special character to combine multiple emoji. Therefore, you are right that the problem is related to emojis.

Thank you for the report
Reto

4

Great. Thank you both!

Cheers,
Markus

—-von unterwegs—->