CMS Made Simple Forums

Hi,

I've just had one of my CMS accounts moved to another server at the same hosting company.

I found that some updates I wanted to make to a User Defined Tag were not being saved - giving me a 403 Forbidden error. Even the same code without change would not re-save.

I thought that something had gone wrong with the transfer (and maybe it did), but I did do some further investigation...

* I created a new UDT and put the same code in there - same issue on saving.
* I commented out all of the UDT code and it still would not save.
* Then I removed parts of the text and tried to save until it saved successfully. I narrowed it down to 2 instances that were causing this error - the text "scandir" and "<__script__".

So something is looking for keywords and then preventing the save if found. It seems like this would be a CMSMS thing as it's possible to write to the page sometimes - but I'm not sure how as I did not change my CMSMS instance.

Is there likely to be some other, new, security feature on the new server that is causing this rather than CMSMS?

Thanks,
Neil

tell your host to whitelist mod_security.

They said that they'd disabled mod_security after my support request but it is still behaving the same way.

I'm not sure if disabling is effectively the same as whitelisting - sounds like it could be different so I've asked them to confirm.

I also tried putting this into my htaccess file without any effect:
... changes are most likely disabled.

Thanks,
Neil

I think there's must be something else going on here.

If I put this text into a new UDT then it will save OK:
If I edit it to remove the X then it will not save (giving me the forbidden error from the POST to edituserplugin.php):
However, if I go directly to the MySQL DB using phpMyAdmin and inline-edit out the X (userplugins table entry), then it saves OK.

I don't know the insides of CMSMS but it seems like it may be CMSMS that is stopping the save - is there code that checks/filters UDT text submissions?

Thanks,
Neil

I moved to another host provider and did not have any issues there.
Still don't know what the real issue was.

Neil

As I said... the issue was mod_security.

We've seen similar issues (403 errors, 404 errors) on numerous occasions.

They wanted a test case and I did not know how to do that without them just saying it must be a CMSMS issue. I needed to remove that from the list of variables - hence my subsequent post.

I needed to get up and running so could not wait any longer.

Thanks,
Neil

CMSMS is different from many systems as it allows you to inject php css and html code from within the admin interface. Therefore it tends to puke when your host implements a firewall with arbitrary rules like mod_security.