Posts: 10
Threads: 3
Joined: Mar 2013
2013-09-10, 01:41:55
(This post was last modified: 2013-09-10, 01:42:28 by tgiadd.)
I have had several hosting companies have problems with deployed GetSimple-based sites' 'components.php' page triggering mod_security blocks (403 Forbidden etc..) when attempting to save new components or save edits to existing ones. The sites were developed locally, and so this problem didn't manifest itself until deployment. Luckily the GS interface has just been for me, and not clients, but until this is 'fixed', I wont be able to recommend for client's usage.
Surely mod_security being enabled can't be that uncommon?
Tim
Posts: 6,266
Threads: 181
Joined: Sep 2011
What specific mod_sec rule ?
What does base64 url encoding have to do with this ?
Posts: 10
Threads: 3
Joined: Mar 2013
Hi Shawn,
I had this feedback from the host:
"You made a number of POST requests to /***/***/components.php that contained the string
'; echo' in one of the parameters. It is most likely a false positive. You should base64 encode your URL parameters before submitting them, and decode them in the receiving script."
This inferred to me that the components.php was wrapping things up incorrectly in an environment where mod_security was enabled...
Tim
Posts: 6,266
Threads: 181
Joined: Sep 2011
Yeah mod_sec is designed to detect xss ( among others things), it probably sees this as a reflected xss attack, since we are sending back code that was sent to the server, which is exactly what we want to do in this case.
base64 encoding it is kind of hacky, but might be an avenue worth looking into, but I believe this is based on a flaw in mod_sec and it will if not already be fixed.
This is a known issue, just no practical solutions aside from disabling mod_sec specific rules for ips or other.
https://github.com/GetSimpleCMS/GetSimpleCMS/issues/517
Download
