Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We've moved the forum!

Please use forum.silverstripe.org for any new questions (announcement).
The forum archive will stick around, but will be read only.

You can also use our Slack channel or StackOverflow to ask for help.
Check out our community overview for more options to contribute.

Hosting Requirements /

What you need to consider when choosing a hosting provider and plan.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

mod_security modification for SilverStripe


Go to End


2 Posts   2892 Views

Avatar
keeny

Community Member, 48 Posts

14 October 2009 at 4:19pm

Hi Guys,

We've just recently upgraded our server and have mod_security installed. We've noticed that the default rules are pretty strict and cause errors when trying to save certain content through the SilverStripe CMS.

In particular, if content contains the '%' character or 'iframe', you are unable to save because mod_security denies the request...

% - URL Encoding Abuse Attack Attempt
iframe - Cross-site Scripting (XSS) Attack

It seems a bit of a shame to turn off mod security or allow certain rules through. What's the point of having it installed in that case!

Does anyone know how these rules could be re-written to be compatible with SilverStripe?

Cheers,

Barry

Avatar
OwenW

Community Member, 45 Posts

16 October 2009 at 1:05pm

Hi Keeny,

Just looking at the two particular mod_sec rules that are getting in your way, there is not really a way to actually recode them as such to remove the false positives without essentially removing the functionality that they provide.

In the case of the URL encoding Abuse attack, you have a choice of either removing the '%' from the match, or making the action that is completed on match to be something other than a block.

With the Cross-site scripting (iframe) rule, it is essentially looking for an iframe anywhere in content and if that is matched, it will then block the rest of the request. Again with this one you have the option of changing the action that the rule executes to be something other than block and if so desired add a log action to it.

With both of these rules, you are really looking at having to remove a component of the rules functionality to make Silverstripe behave properly.

Part of the idea with the default rules of mod_sec is to pick and choose those that will fit your particular situation as there are always going to be false positives across various applications.

Something that would be cool out of this would be a set of known good rules for Silverstripe :)

Cheers

Owen