Composr Supplementary: ModSecurity
Written by temp1024 and Chris Graham (ocProducts)
ModSecurity is an "application firewall" which is often installed by Linux-based webhosts.It's a mixed blessing. By its very nature, it provides limitations on what web systems can do. So in some sense, it breaks standards-based behaviour of web servers. It does this though to raise security, by blocking what it perceives to be malicious server requests, and that's a good thing.
The problem we need to deal with is false-positives – i.e. ModSecurity thinks something is an attack, when it is in fact normal behaviour.
Table of contents
-
Composr Supplementary: ModSecurity
- 300018 / 340165 – URLs inside URLs
- 340007 / 340095 / 340113 / 340118 / 340128 / 340147 / 340148 / 340149 / 340157 / 340159 / 350147…
- 340014 / 390904 – Commandr
- 300076 / 340007 / 340011 / 340014 / 340016 / 340017 / 340021 / 340027 / 340029 / 340095 / 340118…
- 340016 / 340149 / 350147 / 350148 / 390707 – Translate/rephrase Composr
- 340095 – XML Import
- 380800 – PHP-info
- 340009 – Site options
- See also
ModSecurity v1 could be disabled by a .htaccess file, but ModSecurity v2 cannot. ModSecurity is designed for use in enterprise environments, and the makers support it as such – but it is deployed by a lot of webhosts. This leads to an unfortunate problems of responsibility. The ModSecurity authors think that the people managing the servers have control over what runs on them. The webhosts just want to layer in some extra security, and often have little understanding of how ModSecurity works, or what systems their customer's will install. Therefore unfortunately users are sometimes stuck in the middle. Your webhost has a responsibility to provide the service they advertise, so if Composr gets blocked, you have every right to insist that they unblock whatever is stopping it.
Composr will try and work around ModSecurity-style systems in common areas where false positives happen, but we cannot guarantee perfection.
Composr itself contains its own inbuilt firewall, which also blocks many malicious requests. Composr is also built with proper data management APIs and internal layers so that most vulnerabilities aren't possible. This said, as long as ModSecurity is configured right, it is a good thing to have both.
It is not usually easy to know if ModSecurity is blocking you. You will usually see some kind of Apache error message, such as the very generic '500 Internal Server Error'/'402 Forbidden' message. ModSecurity does not explicitly state the problem so that hackers have less clues to why they are blocked. Apache error logs usually contain the full reason, however.
ModSecurity works by a rule set, and rules are typically given a unique identifying number. There are various rule sets out there. An official one is maintained, but also some organisations maintain their own rule sets for 'value add' within their own firewall products based around ModSecurity. What follows is an explanation of common false-positives that Composr can trigger…
300018 / 340165 – URLs inside URLs
This rule blocks URLs being passed as parameters within URLs. Composr regularly does this when you need to be redirected back to where you were at when performing an action. For example, if you are logging in, it encodes where to redirect you back to via a URL parameter. The recommend page facility also uses it.300018 only occurs if not running a URL Scheme, because the rule works by detecting .php, and it won't do this with URL Schemes.
340165 may apply more broadly.
We could probably work around this problem in Composr by encoding the parameter so that it no longer looks like a URL, but this would be messy and have to work across both JavaScript and PHP within Composr, so the complexity cost is too high.
340007 / 340095 / 340113 / 340118 / 340128 / 340147 / 340148 / 340149 / 340157 / 340159 / 350147 / 350148 / 380006 / 380018 / 390708 / 390727 / 973331 – WYSIWYG editing, template editing and code editor
It is possible to get JavaScript code into the WYSIWYG editor. This will then trigger this rule.To workaround you could manually remove the code from the editor's source view, if the code was not intended to be there.
It is likely that there are rules out there that block the WYSIWYG editor completely, but IDs for these aren't known at this time.
We try and automatically 'scramble' the more problematic pages via a special encoding scheme to workaround this.
340014 / 390904 – Commandr
Commandr has a virtual unix filesystem, and stores the current directory in a cookie. If you enter the "/etc" directory, this rule will think you are trying to hack into the server's real filesystem.We try and automatically 'scramble' the more problematic pages via a special encoding scheme to workaround this.
300076 / 340007 / 340011 / 340014 / 340016 / 340017 / 340021 / 340027 / 340029 / 340095 / 340118 / 340128 / 340131 / 340133 / 340144 / 340147 / 340148 / 340157 / 340164 / 350147 / 350148 / 380006 / 380018 / 380019 / 380020 / 380021 / 390709 / 390715 / 390801 / 390810 / 393449 – Code Editor
This occurs when using the code editor to edit php code. If you try and save code changes (by pressing the edit button at the bottom of the code editor) and you do not receive a confirmation pop-up message, then this is the most likely cause. Your browser development tools (network tab) will report this as a 403 or 500 error for http://yourbaseurl/code_editor.php?type=edit.340016 / 340149 / 350147 / 350148 / 390707 – Translate/rephrase Composr
Using the Translate/rephrase Composr feature.We try and automatically 'scramble' the more problematic pages via a special encoding scheme to workaround this.
340095 – XML Import
Importing XML data via Admin Zone > Tools > XML data management > XML Import.We try and automatically 'scramble' the more problematic pages via a special encoding scheme to workaround this.
380800 – PHP-info
Using the Tools > PHP-info feature.340009 – Site options
Saving changes on Admin Zone > Configuration > Site options page.We try and automatically 'scramble' the more problematic pages via a special encoding scheme to workaround this.
Instead of disabling these rules, most issues can be avoided by the host removing the appropriate line from their configuration.
For hosts using ModSecurity v1, remove:
Code
SecFilterScanPOST On
Code
SecRequestBodyAccess On
ModSecurity has this off by default, but turning it on causes most of the problems because it probes into request data rather than just URLs (basically).
See also
Feedback
Please rate this tutorial:
Have a suggestion? Report an issue on the tracker.