New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
steveangstrom opened this Issue Sep 20, 2018 · 24 comments

Comments

Projects
None yet
@steveangstrom

steveangstrom commented Sep 20, 2018

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

This comment has been minimized.

steveangstrom commented Sep 20, 2018

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.

@designsimply

This comment has been minimized.

Contributor

designsimply commented Sep 20, 2018

Thank you for including JavaScript console details! This is the important bit:

Loading failed for the <script> with source “https://timeshard.com/wp-content/plugins/gutenberg/vendor/wp-polyfill-ecmascript.min.2ae96136.js”. post.php:64:1

This means it's possible there is a security rule blocking that script in particular. Do you know of any security plugins or server-side security settings which could be blocking that script?

May I ask where your website is hosted?

@steveangstrom

This comment has been minimized.

steveangstrom commented Sep 20, 2018

Hi, when testing I deactivated WP Wordfence plugin to eliminate that as a cause.

The server is a VPS running the latest version of Plesk on CentOS6, with a variety of standard security systems. For example: ModSecurity with the Atomic basic rule set ( https://www.modsecurity.org/ ) also the Plesk Firewall , Cloudflare security shield.

All quite normal stuff and everything was working perfectly well with the previous version of Gutenberg I had on this site, which may have been a 3.6.x

No changes have been made to the server in that time.

@steveangstrom

This comment has been minimized.

steveangstrom commented Sep 20, 2018

Investigating further, there's certainly a 403 on this file. And checking permissions it's set (along with its siblings) as 0644 rw-r--r--. The folder is 0755

I tried the file as 0755 and even 0775 and it didn't improve matters.
I'm unsure what has changed to make the server reject access to this file.

@steveangstrom

This comment has been minimized.

steveangstrom commented Sep 20, 2018

OK, I found the issue,

Many users will have this problem, at least any of those using the Atomiccorp ruleset which is VERY standard

  Apache error

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 "timeshard.com"] [uri "/wp-content/plugins/gutenberg/vendor/wp-polyfill-ecmascript.min.2ae96136.js"] [unique_id "W6O5C38AAAEAAG0jFckAAAAF"]

https://www.atomicorp.com/plesk/

https://wiki.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules

@agwh

This comment has been minimized.

agwh commented Sep 20, 2018

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

This comment has been minimized.

agwh commented Sep 20, 2018

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

This comment has been minimized.

steveangstrom commented Sep 20, 2018

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

This comment has been minimized.

agwh commented Sep 20, 2018

@weaselnerd

This comment has been minimized.

weaselnerd commented Sep 24, 2018

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

This comment has been minimized.

agwh commented Sep 24, 2018

@mannweb

This comment has been minimized.

mannweb commented Sep 24, 2018

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

This comment has been minimized.

Michael-Ashfield commented Sep 25, 2018

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

This comment has been minimized.

steveangstrom commented Sep 25, 2018

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.

@steveangstrom steveangstrom changed the title from White screen on all Gutenberg page and post editors to Clash with ModSecurity AtomiCorp causes White screen on all Gutenberg page and post editors Sep 25, 2018

@mannweb

This comment has been minimized.

mannweb commented Sep 25, 2018

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

This comment has been minimized.

cyphjuh commented Oct 4, 2018

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

This comment has been minimized.

danielmcclure commented Oct 4, 2018

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

This comment has been minimized.

rkosolapov commented Oct 8, 2018

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

@ombion

This comment has been minimized.

ombion commented Oct 25, 2018

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

This comment has been minimized.

HowdyMcGee commented Oct 25, 2018

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

This comment has been minimized.

Contributor

earnjam commented Oct 29, 2018

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

This comment has been minimized.

NHDriver4 commented Oct 30, 2018

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

This comment has been minimized.

peterluit commented Nov 11, 2018

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

This comment has been minimized.

Contributor

earnjam commented Nov 11, 2018

@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.

@earnjam earnjam closed this Nov 11, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment