Content filter profile - arg with "/" isn't decoded

[olgasobolevsky]

Describe the bug
when I send arg <script> encoded with base 64 the arg is decoded and blocked. But when I send <script>alert()</script> encoded with base64 the arg isn’t decoded and isn’t blocked.
We don’t do decoding for args with “/”.

To Reproduce
Steps to reproduce the behavior:

1. Set Content filter profile to default with base64 decoding.
2. Send request: curl -vv "[url]/t -H "host:default.site" -d "xc=PHNjcmlwdD5hbGVydCgpPC9zY3JpcHQ+"

Actual result: the request isn't blocked, we don't see encoded arg in logs.

Expected behavior

1. The request is blocked by content filter
2. Events Log: we see encoded arg
   For example: if I send arg <script>, we see in Event log:
   

[bartavelle]

Notice how the + has disappeared from the argument value. It has actually been replaced by a space, because the argument is assumed to be url-encoded (base on the content type), so + becomes , and the string is not longer a valid base64 string.

[bartavelle]

If you want to test this, you must use -d "xc=PHNjcmlwdD5hbGVydCgpPC9zY3JpcHQ%2B"