Web server's security rule locking PW

[heldercervantes]

Hey guys.

It's the second time I've collided with this problem recently. Saving a page in PW jumps to a 404 page, and nothing is saved.

The problem is having html in a textfield. My first incident was with a plain textarea (no CK), where the admin was supposed to enter an instagram embed code. Got around that one easily by switching to a text field, user enters only the ID instead of the embed code, and the template would process that.

Now it happened again on another project and this time I can't work around it the same way. It's a CK editor field, and when an image is added to the text, poof!

My hosting provider tells me something is colliding with Firewall: XSS Filter - Category 1: Script Tag Vector rule and sent me the following log:

http_method POST
action_desc Access denied with code 403 (phase 2).
ip  ---.---.---.-
meta_severity   CRITICAL
meta_id 212000
path    /processwire/page/edit/?id=1788
meta_logdata    Matched Data: <script async defer src=\x22//platform.instagram.com/en_US/embeds.js\x22></script> found within MATCHED_VAR: <blockquote class=\x22instagram-media\x22 data-instgrm-captioned data-instgrm-version=\x227\x22 style=\x22 background:#FFF; border:0; border-radius:3px; box-shadow:0 0 1px 0 rgba(0,0,0,0.5),0 1px 10px 0 rgba(0,0,0,0.15); margin: 1px; max-width:658px; padding:0; width:99.375%; width:-webkit-calc(100% - 2px); width:calc(100% - 2px);\x22><div style=\x22padding:8px;\x22> <div style=\x22 ...
meta_uri    
timestamp   2017-05-02 15:46:39
meta_offset 0
meta_msg    XSS Filter - Category 1: Script Tag Vector||www.-----.com|F|2
http_version    HTTP/1.1
host    www.-----.com
justification   Match of "contains google_ad" against "MATCHED_VAR" required.

Has anyone hit this problem? Is there a solution on PW's side that doesn't require lowering this rule on the server?

 

Thx, H

[LostKobrakai]

I mean it's the hosters filter rule, so they can probably best tell how to circumvent it. 

[heldercervantes]

I've asked them to turn it off. Works for now, but I'll have to keep it in mind for future projects.

HTML content in textareas are causing a false positive on an injection checker. We'll probably see more people with the same problem.

The only solution I can think of would mean encoding post content when PW saves.