403 error when editing in the Manager, mod_security

Hi Folks,
I’ve seen some weird ones, and can generally cope, but this one has me completely confused.

I’m just trying to edit my templates, and I’m getting:

It seems to have something to do with the referer, according to tech support, who was also baffled.

I’m running Evo 1.02 on Liquid Web (great host, have done lots of MODx sites on it) linux, PHP 5+. The site is running under a temp URL with tilde, etc., as it’s not propogated yet. It had run that way fine before. (maybe I need to use a real URL?).

The site had been working great for weeks. Also, I can edit any of the default templates, but not any in my new category for this site. I actually can update one bogus empty template I put under that category. (gee, maybe some code in my template could trigger this?). Other stuff in the Manager edits fine.

I had read in the forum that this can be caused by a Firefox referer setting. I’m already set the way they recommended. Same errors in Chrome. I also heard that antivirus might do something, tried shutting that off, no joy. My client just tried editing, got the same error, so I guess it ain’t me!

Also tried shutting off Validate Referer in config.

I’ve played some with .htaccess in root and /manager/, no joy. I even tried re-installing 1.02. (Maybe I should try 1.03)?

Any good ideas appreciated!
Thanks, Dave

1.0.3 wouldn’t hurt, but this sounds like it’s a server issue. Are you trying to open up manager pages in multiple browser tabs? That can trigger XSS errors. Do you have the manager setting on about checking XCRF headers being validated? You can try shutting that off to see if the behavior changes any, but I suspect it’ll get fixed once your url gets properly propagated.

Quote from: Everett at May 01, 2010, 01:58 AM

1.0.3 wouldn’t hurt, but this sounds like it’s a server issue. Are you trying to open up manager pages in multiple browser tabs? That can trigger XSS errors. Do you have the manager setting on about checking XCRF headers being validated? You can try shutting that off to see if the behavior changes any, but I suspect it’ll get fixed once your url gets properly propagated.

Everett,
Good ideas, thanks. I do have a marked tendency to have another tab open for "Manage Files" so I can edit CSS in a separate window. And I agree, it does seem server-related. The tech fixed someting in mod_security that he thought was awry, no joy yet.

I also am cautiously optimistic that propogation will help.

The last time something this random took place, it turned out to be an upgrade in CPanel did it, requiring a php.ini change as I recall, so I asked them about CPanel or any server upgrades. We’ll see what happens.

I think it’s worth mentioning that when I’ve dealt with LiquidWeb tech support, they been very willing to actively help.

UPDATE: in the end, it was an incorrect server setting on mod_security. They had looked at mod_security, and the 2nd fix they made was the charm. Once again, Liquid Web’s awesome tech support came through for me. I had also copiously described the problem and the steps I took, which likely helped things along. I won’t even mention how many messages were involved! My thanks to them.

Thanks again!

Hi,
I’m hoping that this may be helpful for people getting 403 (security) errors while editing various types of content in the Manager. I also had marked this as SOLVED, but IMO, it no longer is.

As can be seen in the thread above, I had thought that the problem was solved when the tech made changes to a setting in mod_security.

But I ran into the problem again today on the same box. On the bright side, the tech fixed my own problem immediately! But when I found out what he did to solve it, that’s what concerned me. This time around, I got a little nosier and asked what he had changed.

I had hoped that he would have simply turned off mod_security for that one folder, or at least that he would have given me permission to use the milder mod_security rule overrides that one can find in the MODx wiki and elsewhere.

Apparently he looked at the errors that I was getting, and white-listed some content words. This is a spam filtering component of mod_security, and they’re casting a wide net, IMO. The words involved were "online" and "prescription", not exactly words that are rare or particularly dangerous. I envision some geek locked in a room must be doing statistical analysis of spam words and just chucking them into the mod_security spam filter.

So the problem could occur again whenever an editor bumps into more of these words. It’s lame, IMO, to do a manual fix every time this happens. Anecdotally, I am seeing this problem more and more often on pretty much any CMS system. The cure being as bad as the disease.

Some of you won’t have this limitation. If you’re in charge of the server as root, then you can shut off mod_security if it comes to that. Or you can at least do surgical strikes on where it’s applied, and what it’s doing, for more security safety.

I have also heard that running SUEXEC can help with this, although I don’t know details.

And on many hosts, you can do commands such as "SecFilterScanPOST Off" in .htaccess in the offending folder and have it work, just as advised here. http://wiki.modxcms.com/index.php/What_is_mod_security_and_how_does_it_affect_me
On Liquidweb shared hosting, evidently this is not allowed.

With any dedicated hosting, I’m guessing that this is easily corrected. But the budgets of my clients are generally not big enough to use dedicated.

Hope this helps someone. When all else fails, I have gone into the database itself to make the updates with the desired content.
Dave