Sanitize challenge field to prevent XSS vulnerability

Sure why not. The chance of this happening is slim, but good to have it covered none the less since it's outputting plain user input.

Agreed, this came up as part of a security audit, so even if normal folks wouldn't find it and exploit it, other security scans might pick up on it.

Correct me if I'm wrong, but what I believe this code is doing is to escape the challenge, and store it escaped in state, and then get the escaped value from state and again escape it... It works fine as long, as the challenge doesn't include anything that gets escaped.. The moment the challenge includes an escpaed character, let's say

hello"goodbye

, it will be stored in state as

hello"goodbye

, then retrieved and the challenge to be displayed would be

hello"goodbye

. Clearly not what we want. I'm not sure if a quote is a valid challenge character, but I don't see any reason why it would not be.

Would be way better to use https://api.drupal.org/api/drupal/core%21modules%21editor%21src%21Editor...

I pushed an update that switches to using Standard::filterXss. I wasn't sure what filter format would make sense to test, since that could vary from site to site, so I just made a dummy one.

The implemention must be the reverse of the current state of the MR. The filterXss must be called ONLY during the setting of the configuration form. That way, no XSS is inserted into the configuration.

When retrieving the value, it is already XSS-free, so nothing needs to be escaped.