Gutenberg: Clash with ModSecurity AtomiCorp causes White screen on all Gutenberg page and post editors

[steveangstrom]

Describe the bug
When editing a post with Gutenberg 3.8.0 I only see a white screen with no sidebar

(after investigation) THE CAUSE: is a clash with Apache ModSecurity (AtomicCorp) which sees the iFrame JS insertion as a cross site scripting attempt.

To Reproduce
Steps to reproduce the behavior: (edited to reflect new info)

1. Be on a server using ModSecurity with the AtomiCorp ruleset
2. Go to https://MYDOMAIN.com/wp-admin/edit.php?post_type=page or https://MYDOMAIN.com/wp-admin/edit.php
3. Click on https://MYDOMAIN.com/wp-admin/post.php?post=8&action=edit or https://timeshard.com/wp-admin/post.php?post=1&action=edit
4. See error - white screen - no sidebar

Expected behavior
I expect to see Gutenberg

Desktop

• OS: Windows 7
• Browser : Firefox developer edition
• Version63.0b7 (64)
• Wordpress version 4.9.8–en_GB

ALSO

• Chrome : Version 69.0.3497.100 (Official Build) (64-bit)

Plugins:
Gutenberg Version 3.8.0
Error Log Monitor Version 1.6.2 \| By Janis Elsts \|
Wordfence Security Version 7.1.12
WP Super Cache Version 1.6.4
WPForms Lite Version 1.4.9

Console

JQMIGRATE: Migrate is installed, version 1.4.1 load-scripts.php:9:542
Loading failed for the <script> with source “https://MYDOMAIN.com/wp-content/plugins/gutenberg/vendor/wp-polyfill-ecmascript.min.2ae96136.js”. post.php:64:1
ReferenceError: regeneratorRuntime is not defined[Learn More] index.js:12:86582
this.wp.editor</Qn<
https://MYDOMAIN.com/wp-content/plugins/gutenberg/build/editor/index.js:12:86582
this.wp.editor<
https://MYDOMAIN.com/wp-content/plugins/gutenberg/build/editor/index.js:12:86565
n
https://MYDOMAIN.com/wp-content/plugins/gutenberg/build/editor/index.js:1:139
this.wp.editor<
https://MYDOMAIN.com/wp-content/plugins/gutenberg/build/editor/index.js:1:558
<anonymous>
https://MYDOMAIN.com/wp-content/plugins/gutenberg/build/editor/index.js:1:36
TypeError: Object(...) is not a function[Learn More] index.js:12:8067
213
https://MYDOMAIN.com/wp-content/plugins/gutenberg/build/block-library/index.js:12:8067
n
https://MYDOMAIN.com/wp-content/plugins/gutenberg/build/block-library/index.js:1:145
this.wp.blockLibrary<
https://MYDOMAIN.com/wp-content/plugins/gutenberg/build/block-library/index.js:1:564
<anonymous>
https://MYDOMAIN.com/wp-content/plugins/gutenberg/build/block-library/index.js:1:42
TypeError: Object(...)(...) is undefined, can't access property "getBlockSelectionStart" of it[Learn More] index.js:12:15977
INIT/<
https://MYDOMAIN.com/wp-content/plugins/gutenberg/build/edit-post/index.js:12:15977
Ge
https://MYDOMAIN.com/wp-content/plugins/gutenberg/build/edit-post/index.js:12:13961
INIT
https://MYDOMAIN.com/wp-content/plugins/gutenberg/build/edit-post/index.js:12:15955
107/e.exports</</</</<
https://MYDOMAIN.com/wp-content/plugins/gutenberg/build/edit-post/index.js:1:1776
214
https://MYDOMAIN.com/wp-content/plugins/gutenberg/build/edit-post/index.js:12:16946
n
https://MYDOMAIN.com/wp-content/plugins/gutenberg/build/edit-post/index.js:1:141
this.wp.editPost<
https://MYDOMAIN.com/wp-content/plugins/gutenberg/build/edit-post/index.js:1:560
<anonymous>
https://MYDOMAIN.com/wp-content/plugins/gutenberg/build/edit-post/index.js:1:38
TypeError: wp.editPost is undefined, can't access property "initializeEditor" of it[Learn More] post.php:1706:5
window._wpLoadGutenbergEditor</<
https://MYDOMAIN.com/wp-admin/post.php:1706:5

[steveangstrom]

I should mention that previous versions of Gutenberg worked on this site.
Also that I have tried deactivating all plugins listed to see if they are causing conflicts. With only Gutenberg active the error persists.

[agwh]

This same problem -- white screen with no sidebar -- is also occurring for me, for both pages and posts. Gutenberg 3.8.0 is installed. Any idea how a person who is not computer-literate can fix this?

[agwh]

Hah! Gutenberg has made me a liar. It is just really slow to begin to work. Thought I had given it plenty of time, and I had logged off then back on. However, giving it still more time and logging off (then back on) a second time was the magic that made it work.

[steveangstrom]

It will be difficult for you to fix if you do not have access to modify the ModSecurity ruleset exceptions for Apache.

@designsimply has mistakenly tagged this thread as a request for help. This is not correct.
This is a report of a Gutenberg implementation which causes a clash with common server security settings and will trigger Gutenberg to fail in those cases.

The problem is briefly stated as
Gutenberg Polyfill js is detected by ModSecurity as a potential XSS attack leading to Gutenberg failure

This is a new problem with Gutenberg and needs addressing by the Gutenberg team to prevent the rule being triggered (It's detected as an iFrame XSS attack). Many WP site owners do not have access to modify the ModSecurity ruleset, nor the expertise. Consequently, many WP site owners will begin to experience this issue due to the popularity of Plesk resellers running the ModSecurity Atomicorp ruleset.

[agwh]

Appreciate the reply, and I understand that this could be an ongoing
problem. Thank you for the information!

On Thu, Sep 20, 2018, 5:27 PM Steve-Pheriche [e-mail]
wrote:

It will be difficult for you to fix if you do not have access to modify
the ModSecurity ruleset exceptions for Apache.

@designsimply https://github.com/designsimply has mistakenly tagged
this thread as a request for help. This is not correct.
This is a report of a Gutenberg implementation which causes a clash with
common server security settings and will trigger Gutenberg to fail in those
cases.

The problem is briefly stated as
Gutenberg Polyfill js triggers ModSecurity basic ruleset 403 and
Gutenberg failure

This is an error with Gutenberg and needs addressing by the Gutenberg team
to prevent the rule being triggered (It's detected as an iFrame XSS
attack). Many WP site owners do not have access to modify the ModSecurity
ruleset, nor the expertise. Consequently, many WP site owners will begin to
experience this issue due to the popularity of Plesk resellers running the
ModSecurity Atomicorp ruleset.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/WordPress/gutenberg/issues/10075#issuecomment-423339279,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ApcQiE2FvUmhIMxDYtHYDo27CW_4Q-OAks5udAhLgaJpZM4WyfJH
.

[weaselnerd]

Can vouch that ModSecurity caused the white screen issue due to 404 of the wp-polyfill-ecmascript.min.2ae96136.js file with my Site5 hosted site.

Only option available via my cPanel is to completely disabled ModSecurity entirely for the WP domain, as I haven't found any rule configuration options. Obviously non-ideal, but it restored the Gutenberg edit screen. Will probably revert to the classic editor for now instead.

[agwh]

Got it. Thanks! I can probably figure out how to do that, if the problem
persists. I also installed the classic editor as a fallback, and I was
trying Gutenberg on a "practice page." As a non-techie person, I figured I
would need extra time to learn the new system. Thanks again! - Amy

On Sun, Sep 23, 2018, 9:10 PM Sean W [e-mail] wrote:

Can vouch that ModSecurity caused the white screen issue due to 404 of the
wp-polyfill-ecmascript.min.2ae96136.js file with my Site5 hosted site.

Only option available via my cPanel is to completely disabled ModSecurity
entirely for the WP domain, as I haven't found any rule configuration
options. Obviously non-ideal, but it restored the Gutenberg edit screen.
Will probably revert to the classic editor for now instead.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/WordPress/gutenberg/issues/10075#issuecomment-423861758,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ApcQiPlXPPqqMUSpXWxXSVjQ16gsuTRrks5ueDEGgaJpZM4WyfJH
.

[ghost]

From the mod_security log (Web Application Firewall in Plesk):

ModSecurity: [file "/etc/httpd/conf/modsecurity.d/rules/tortix/modsec/50_plesk_basic_asl_rules.conf"] [line "253"] [id "340149"] [rev "152"] [msg "Protected by Atomicorp.com Basic Non-Realtime WAF Rules: Potential Cross Site Scripting Attack"] [data "ecmascript"] [severity "CRITICAL"] Access denied with code 403 (phase 2). Pattern match "(?:< ?i?frame ?src ?= ?(?:ogg|gopher|data|php|zlib|(?:ht|f)tps?):/|(?:\\\\.add|\\\\@)import |asfunction\\\\:|background-image\\\\:|e(?:cma|xec)script|\\\\.fromcharcode|get(?:parentfolder|specialfolder)|\\\\.innerhtml|\\\\< ?input|(?:/|<) ?(?:java|live|j|vb)script!s| ..." at REQUEST_URI. [hostname "..."] [uri "/wp-content/plugins/gutenberg/vendor/wp-polyfill-ecmascript.min.2ae96136.js"] [unique_id "W6hGH38AAAEAH6OVG-4AAAAC"]

[Michael-Ashfield]

I also have this issue, ModSecurity in Plesk like the others.
Classic editor works as a fallback for now, though staging from a local host will still allow you to edit using Gutenberg before you move it to Plesk.

Does anyone know a fix or work around? I only got this error when moving from local dev to my staging server on Plesk.

@designsimply this isn't really a help request but a legitimate implementation error that may affect a large number of users, including those with no ability or knowledge to fix it.

[steveangstrom]

The brutal workaround for those with access to either Plesk or WHM is to deactivate the XSS rule globally for the domain. In Plesk this is done by
1: Login into Plesk.
2: Add ID rule into exception under Plesk > Domains > example.com > Web Application Firewall > Switch off Security rules ( see the IDs box).
The rule ID can be found from the errors. In this case the ID is 340149 and this number should be entered into the security Rule ID box.

Obviously, this is not ideal as it deactivates the ModSecurity XSS rule for the domain.
I believe it's possible to unset and replace rules by ID via the CLI with a custom rule, but I'm too busy to investigate this at the moment.

It's my (possibly incorrect) understanding it's possible to approach AtomicCorp with a false positive and that they will whitelist the file. I may be mistaken on this.

[ghost]

Yes, adding the ID to that area worked here for me, but Steve beat me to posting it here. I don't like this either, but it is better than alternatives like setting the Web application firewall mode to either "Detect Only" or "Off".

[cyphjuh]

If you have access to Plesk Settings for Apache/Nginx for the domain, you can make an exception for just gutenberg instead of setting it off for the whole domain, by using the next code:

<IfModule mod_security2.c>
    <LocationMatch "/wp-content/plugins/gutenberg/vendor/">
        SecRuleRemoveById 340149
    </LocationMatch>
</IfModule>

[danielmcclure]

Just wanted to note that I'm getting white screen errors by default with Gutenberg on Plesk installs now too. This caused even more confusion by repeatedly adding my IP to the ban list before I realised what was happening.

Domain Error Log:

[client 0.0.0.0] ModSecurity: Access denied with code 403 (phase 2). Pattern match "(?:< ?i?frame ?src ?= ?(?:ogg|gopher|data|php|zlib|(?:ht|f)tps?):/|(?:\\\\.add|\\\\@)import |asfunction\\\\:|background-image\\\\:|e(?:cma|xec)script|\\\\.fromcharcode|get(?:parentfolder|specialfolder)|\\\\.innerhtml|\\\\< ?input|(?:/|<) ?(?:java|live|j|vb)script!s| ..." at REQUEST_URI. [file "/etc/apache2/modsecurity.d/rules/tortix/modsec/50_plesk_basic_asl_rules.conf"] [line "253"] [id "340149"] [rev "152"] [msg "Protected by Atomicorp.com Basic Non-Realtime WAF Rules: Potential Cross Site Scripting Attack"] [data "ecmascript"] [severity "CRITICAL"] [hostname "domain.com"] [uri "/wp-content/plugins/gutenberg/vendor/wp-polyfill-ecmascript.min.2ae96136.js"] [unique_id "W7aS7n8AAAEAACgRXicAAAAC"], referer: /wp-admin/post.php?post=8&action=edit

Console Error:

GET /wp-content/plugins/gutenberg/vendor/wp-polyfill-ecmascript.min.js net::ERR_ABORTED 403

Definitely agree that this has potential for a widespread issue as it is the recommended setup inside Plesk. For now the ID exception has helped.

If you are in control of the installation you can set the workaround on a server wide basis...

How to Disable Conflicting Rule Server-Wide

1. Go to: Server Management > Tools & Settings > Web Application Firewall (ModSecurity)
2. Under Switch off security rules add the ID 340149
3. Click OK or Apply button

[rkosolapov]

I've reported it to AtomiCorp: https://support.atomicorp.com/hc/en-us/requests/17815

[ombion]

Exact same problem for me - white editor screen. I have hosting by Site5. When I turn off ModSecurity for the server, problem goes away. I hope the Gutenberg team can rewrite the code to avoid the scenario of Polyfill JS being detected by ModSecurity. There will be lots of users encountering this problem once Gutenberg is dropped in WP core.

[HowdyMcGee]

Same problem here with the nightly build. Would it be easier to just rename the polyfill file?

These AtomicCorp rule IDs also seem to impact loading Gutenberg specific scripts:

• 340149
• 33340149

[earnjam]

I think we need to rename the file. I'm not sure it's reasonable to expect every host to be aware of this and customize their ModSec rules for it prior to rollout.

[NHDriver4]

If you have access to Plesk Settings for Apache/Nginx for the domain, you can make an exception for just gutenberg instead of setting it off for the whole domain, by using the next code:

<IfModule mod_security2.c>
  <LocationMatch "/wp-content/plugins/gutenberg/vendor/">
      SecRuleRemoveById 340149
  </LocationMatch>
</IfModule>

Thanks for this info! Where can I add this for nginx? Does it just go into the "Additional nginx directives" field? The above looks like an Apache directive.

[peterluit]

In Plesk I just inserted the security rule number 33340149 to be ignored, but left the firewall on for all other rules. Gutenberg now works fine.

[earnjam]

@peterluit In #11216 we addressed the ecmascript issue by discontinuing the use of that filename and consolidating to just wp-polyfill. Doesn't look like that change has made it over to the latest in core 5.0 branch yet, but it's in the latest plugin version.