snippets and mod_security

I have mentioned this in the templates arena yesterday. Because it seems it could become a major problem with hosting providers I thought this would be a better place to discuss it.

Technically it is not a bug, but it looks like that on certain systems.

I hit the problem when trying to install the andreas01 template on my site (hosted on my boss’s machines). The andreas01 template has a modified DropMenu snippet which has to be installed. First I got a 403 Access Denied. (As I have access to my boss’s machines) I changed the rules a bit and tried again. Then I got a 500 Internal Server Error. Both were caused by mod_security. As the 500 error is a response to a commonly used PHP injection hacking attempt, this was the point to stop altering the rules.

First I thought there was something wrong with the code; then I realized PHP code was sent from client to server which was caught by mod_security. The PHP code being part of the payload doesn’t matter as mod_security cannot distinguish.

As hacking threats are becoming more and more advanced, security will become tighter. My boss has had loads of problems before installing mod_security; afterwards they became minimal.
He is most likely not the only one going for a construction like this, so it will become harder to get snippets from client to server.
The rigourous solution is taking out the rules.
The elegant solution is adapting the code.

I am far from a javascript/PHP expert, but I do know how to look for possibilities. From what I have seen recently javascript is able to change values in fields.
The idea is this: at the point of sending the snippet to the server, have a javascript alter the snippet code field and then send it over. At the server PHP code will alter the snippet code back to it’s original state and continue the original snippet handling.

Alter the snippet code: just a stupid term I introduced here. It would be more sensible to use some encoding technology: rot13, uuencode, crypt, des5, whatever. The encoding would also hide things from those passers-by.

If anyone could point to the locations inside the code where snippets are sent (from client) and received (by server) I would give something like this a try. While I am not the expert pointed out above, I have good general programming knowledge, and a love for hacking around (in the positive sense, i.e. NO cracking).

Regards,

Marb

All of the Manager interface code is in /manager/actions (usually dynamic, static is just for viewing), while the processing code can be found in /manager/processors. I have a lot of fun playing in these areas, although I have found using plugins and modules are much better for add-ons. But for what you have in mind, you’ll definitely need to hack a couple of these files.

Marb,

I am confused -- can you describe the problem in more detail please? Your post seems to imply that PHP code is being passed from the server to the client, which to the best of knowledge isn’t the case since the the client doesn’t know what PHP code is.

Please describe what page this happened on, what the mod_security error was, as well as your mod-security config, so we can diagnose this error as I have never heard of this behavior before.

Thanks,
Victor

When trying to save a snippet, the php code is being passed to the server in the POST. The mod_security setting sees incoming php code in the POST and aborts the page request with an error. So the mutate_snippet_dynamic_actions.whatver.php script needs to encrypt or in some way encapsulate the php code so it can pass the mod_security check, then the save_snippet.processor.php script needs to decrypt or un-encapsulate the POST value to save to the database. Probably need to do the same with TVs.

Victor,

sotwell described very accurate was is happening.
The snippet sent is PHP code. mod_security isn’t too intelligent so it tags everything like PHP code bad, and starts barking.

sotwell: thanks for pointing out where to look. I will try to give it a shot.
I have found some javascript encryption (javascrypt, from fourmilab, Switzerland). It is probably too advanced, although it could be useful in certain circumstances.

marb

Well, I have had a couple of issues with mod_security back at TextDrive with Expression Engine. I got a lot of "Error 412: precondition failed".

You’ll have to tweak your .htaccess a little to avoid those using selective directives. Once you have identified the URL causing problems you add :



If it’s caused by content filtering then you can also tweak things :



Worst case scenario, you can just turn it off :



Check out :
http://www.movalog.com/archives/general/mod_security
and http://kb.textdrive.com/article/disabling-mod_security

Hope it helps !

then you could just use a directive to allow the /manager/index.php to pass without being filtered. If this becomes more common, then a comment section dealing with it may have to be added to the default ht.access file.

davidm:

Yep! it works. By shutting down the SecFilterEngine completely...

Actually I think it is like fixing my car (a 13+ year old Chevy Corsica): as long as it works, it’s fine.

But this isn’t the way things should be fixed with MODx.
Once I have the flow clear, I’ll continue to try to get some encoding in.

Has anything further been done with this?

I’m trying this solution here, but admit to struggling understanding it. Part of it is my lack of coding knowledge but a bit is understanding Javier, who has done well considering I don’t think English is his main language but has left me in the dust.

http://modxcms.com/forums/index.php/topic,4241.0.html

I’ve got it installed as a plugin, and have it set for ontvformsave and onsnipformsave -- if anyone thinks I should set it up differently please let us all know. Details posted on that thread as to exactly how to install might also be a huge help for the next person who encounters the problem. Save some guessing.

I will let you all know if that particular way, or any variation of it solves my problem.

In my case it’s to solve this particular problem here:
http://modxcms.com/forums/index.php/topic,5403.msg48454.html#msg48454

Any further ideas welcome.

No Joy from Javier . . . other ideas welcome.