• I started to create a new page, got as far as a heading and the auto-save failed.
    The website security software — CIDRAM — was blocking Gutenberg because —

    Non-escaped characters in POST

    or to put it another way it would appear that Gutenberg is not sanitizing the POST data.

    I regularly see hackers trying to enter computer code via the Contact-us page, and it is either stopped by the Contact-us page sanitizing the POST data and/or the security software blocks it. This is a common attack vector, and if Gutenberg is not correctly sanitizing it’s POST data then Gutenberg could be a significant security risk.

    Rather that reduce the website security I have disabled Gutenberg, until this is fixed.

Viewing 5 replies - 1 through 5 (of 5 total)
  • Moderator Marius L. J.

    (@clorith)

    Hiya,

    So we have a bit of a Catch-22 here.

    We can’t run sanitizers until the server receives the content that needs sanitizing, which is done by submitting the data via ajax calls to the server, but there’s some setting running that won’t let us reach the sanitizers.

    I’m not familiar with your specific software, but Gutenberg it self is fine in this regard, it just can’t do what it should be doing because it’s being blocked.

    Hi,

    The author of CIDRAM here. ??

    One possible compromise, which would allow you to both keep CIDRAM (and the relevant signatures in question here) running, and keep Gutenberg enabled (at least, insofar as preventing Gutenberg from being blocked when *you* use it), would be to “whitelist” your own IP address in CIDRAM (CIDRAM won’t ever block a whitelisted IP address).

    Of course, if *other* people use Gutenberg on your WordPress installation (e.g., other administrators, moderators, etc; or any users with the necessary permissions to use Gutenberg on your WordPress installation), you mightn’t know what their IP addresses are, and it’s not so easy to whitelist IP addresses when you don’t know *which* IP addresses to whitelist. Another caveat to whitelisting, is that you might need to repeat the process whenever your IP address changes (i.e., if your IP address is dynamic, rather than static).

    The bonus upside to whitelisting, is that it could prevent you from being blocked in the event of possible other, future situations such as this.

    A more restrictive alternative to whitelisting (in order to prevent Gutenberg from being blocked, while still allowing a block event to occur for other reasons) would be to create a “signature bypass”, to bypass the specific signature in question here.

    Reference material:
    CIDRAM WordPress plugin.
    CIDRAM documentation.

    Hope this helps. ??

    Kind regards,
    Caleb M (Maikuolan).

    • This reply was modified 6 years, 1 month ago by Maikuolan. Reason: Forgot to use HTML instead of BB code in my reply (oops). Fixed
    Thread Starter htjoe38

    (@htjoe38)

    Hi Maikuolan
    Long time no see — joe38 from the original zbblock forum.

    Unfortunately I have a dynamic IP so I can’t whitelist it. I could create a bypass as you suggest but …

    It would appear that others are having the same problem when using Sucuri security software.

    So it would make sense to me if the Gutenberg ajax/javascript sanitized it’s POST data before it gets to the server – i.e. at the client end of things, which would be in complete control of the Gutenburg Ajax. This must be better programming / ethos otherwise you are encouraging WordPress to accept non-escaped POST data as the norm and I’m sure that sooner or later the hackers will find a way to utilize this. You are just leaving the security door wide open.

    Thread Starter htjoe38

    (@htjoe38)

    You say that —

    Gutenberg it self is fine in this regard

    and yet isn’t it Gutenberg it self that is generating the code that is being blocked ?
    i.e. it is Gutenburg Javascript / Ajax that is generating the Non-escaped POST data in the first place ?
    That would make it Gutenburg’s problem ?

    Moderator Marius L. J.

    (@clorith)

    I would argue no, Gutenberg can’t know what plugins are interacting with the data before/after it is sent, this is why we run our sanitizers in the back-end before storing it, and not on the front end. This is essentially what we’ve always done, it’s just more obvious now because of the way the REST API is utilized for everything.

    If there are any legitimate security concerns over this that we’re not aware of though, we would love to hear from you over at https://hackerone.com/wordpress where such concerns should be reported, as I don’t intend to sound dismissive, because we can’t know everything ??

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘auto-save failed — Non-escaped characters in POST’ is closed to new replies.