You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Set Content filter profile to default with base64 decoding.
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.
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:
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
For example: if I send arg
<script>
, we see in Event log:The text was updated successfully, but these errors were encountered: