October: Cannot edit pages in backend

Created on 17 Jun 2016  路  17Comments  路  Source: octobercms/october

image

I installed Octobercms successfully into hosting server but when I go to backend and try to edit home page or even create and save a new page it pops up a 403 page in HTML. what might be the problem?

Completed Maintenance

Most helpful comment

adding this to my .htaccess file solved it for my hoster (cyon)

<IfModule mod_security.c>
  SecFilterEngine Off  
</IfModule>

All 17 comments

Is the theme's pages storage dir writable by your web server (or by PHP, if you're using PHP-FPM)?

This is kind of a known error with some hosts, such as GoDaddy, which hosting provider are you using?

@daftspunk HostForWeb. @gblair the theme's pages storage file has 0644 permissions but when I changed permissions to 0744 same problem.

"403 forbidden" is 99% problem with too restrictive ModSecurity rule on a shared host. Talk to your hoster.

@Eoler just checked alot of forums and discovered the same. There is no solution unless I talk to hosting company. Thanks.

Leaving this open so we add HostForWeb to the list of affected hosts in the KE article.

I'm on Greengeeks re-seller hosting (shared hosting) and am having this same issue. I'll give a little detail into what I've been seeing.

  • Occasionally, the problem can be resolved by making adjustments and whitelisting some rules in Apache's mod_sec module. This error doesn't seem to be limited to Apache (unconfirmed) but adding some rules to white list (I have a list of potential culprits) can sometimes help.
  • Other times the error only occurs on only specific pages, with specific text. For example, I was unable to save a partial with an <input> element, and when that tag was removed, it saved just fine. Further testing may be required (I'm willing to help) to pinpoint culprits.
  • And on even other times, waiting it out can resolve the issue.
  • These errors don't appear to be recorded either in OctoberCMS, or in my cPanel error reporting system.
  • I have not seen this issue replicated with the StaticPages plugin, but have experienced it with almost all other parts of the CMS (pages, layouts, partials, assets).
  • I talked to my hosting company multiple times, and we have a fairly long list (15-18) of rules to whitelist, but I still occasionally get the error.
  • I've heard from other people that this error only started after an OctoberCMS update.

This is all from about ~1 month of testing and trying to figure it out. Now I just pop open FTP whenever it happens so I can continue working.

EDIT: Just got a similar edit using <button> elements, but only when the onclick selector was in the element

Added Greengeeks re-seller hosting to the list of affected hosts. This information aligns mostly with what we have already, the server doesn't like some HTML tags from being posted to the server. We had <form>, it also appears to occur with <input> based on what you're saying. Thanks

Same Here.
I am using UK2 hosting provider.

Please help with this,i don't want to use FTP whenever i need to change something

This issue has been documented in article KE-1

http://octobercms.com/support/article/ke-1

adding this to my .htaccess file solved it for my hoster (cyon)

<IfModule mod_security.c>
  SecFilterEngine Off  
</IfModule>

Dutch hosting provider "D-Hosting" (relative small hoster) also is affected by ModSec issues. Does anyone which rules are to be whitelisted?

@CptMeatball Daniel on Slack said he was looking into it a while ago

Hoster disabled following codes:

340147
340148
340149
350147
350148
350149

It doesn't mean all of these need to be disabled, but that are the rules they have disabled for us.

I have only had this issue appear recently, but my host looked into it and said the developer needed to fix it, this is the error they returned to me.

"[Thu Mar 15 09:26:38 2018] [error] [client 222.154.232.237] ModSecurity: Access denied with code 403 (phase 2). Pattern match "(?i)([<\\xef\\xbc\\x9c]script[^>\\xef\\xbc\\x9e]*[>\\xef\\xbc\\x9e][\\\\s\\\\S]*?)" at ARGS:markup. [line "14"] [id "212000"] [rev "3"] [msg "COMODO WAF: XSS Filter - Category 1: Script Tag Vector||www.(my domain).nz|F|2"] [data "Matched Data: <script src=\\x22assets/javascript/jquery-2.1.0.min.js\\x22> found within ARGS:markup: <!doctype html>\\x0d\\x0a<html>\\x0d\\x0a<head> \\x0d\\x0a\\x09<meta charset=\\x22utf-8\\x22>\\x0d\\x0a\\x09<meta name=\\x22keywords\\x22 content=\\x22\\x22>\\x0d\\x0a\\x09<meta name=\\x22description\\x22 content=\\x22\\x22>\\x0d\\x0a\\x09<meta name=\\x22viewport\\x22 content=\\x22width=device-width, initial-scale=1.0, viewport-fit=cover\\x22>\\x0d\\x0a\\x09<link rel=\\x22shortcut icon\\x22 type..."] [severity "CRITICAL"] [tag "CWAF"] [tag "XSS"] [hostname "www.(my domain).nz"] [uri "/backend/cms"] [unique_id "WqnLzmdD62AADQpoVakAAAAO"]"

Can someone with more insight or understanding of the above suggest a solution?

Just a follow up on my above post.

My host finally disabled Mod Security and now its solved. I assume that whitelisting is the best way to go from a security perspective?? Or doesn't it matter much?

I think the save action generates an iframe which is seen as malicious bij Mod_Security. In the error you can see something that a reg_ex matches an iframe pattern (or something like that).

Was this page helpful?
0 / 5 - 0 ratings