Doing some searching, I find that adding [FONT=“Courier New”]SecFilterEngine Off[/FONT] to the .htaccess file simply turns off mod_security. That doesn’t seem the wisest move. So, what should I be using to enable things that aren’t working?
Here’s the deal I found yesterday: In my client’s CMS-based site, I could update a page, but I couldn’t include a link. If the submitted text included “h ttp://” then I got a 403 error. (BTW, without the space in http I couldn’t post this message, so the mod_security restriction affects this forum server, too!)
Would putting [FONT=“Courier New”]SecFilterSelective “POST_PAYLOAD” “h ttp://” “allow,nolog”[/FONT] into my .htaccess leave me open to some attacks? My client certainly wants to be able to post links on her site. Is there something better I should put?
Psoft, better get it together so we can upgrade and able to get PHP5. We weren’t be having all these freaking problems if we were updated, these new scripts work better on php5.
We’ve had problems with one site so far but I haven’t been through to check them all. The problem was in a version of Gallery2; the latest version is fine.
JodoHost’s advice is to check log files for 403 errors which should be fun :rolleyes:
It may be useful if anyone who does identify apps that break to drop a note here with possible fix.
e.g.
App: Gallery2 ver 2.0.2
Problem area: Return URL’s posted in query string
Fix: disabled in modules/core/classes/GalleryUrlGenerator.class line 400 (a better option would be to change to use relative URL’s as per later versions of G2)
Side effects: none known yet
Here’s a weird one… something in the combination of these words (without the “_” becuase otherwise I can’t post here) being posted in a text box causes a 403:
“constantly need to up_date and revamp it to reflect the job market and your skill set”
The word up_date (without the “_”) on it’s own doesn’t do it so it must be in combination with one or more of the other words, possibly ‘set’ and/or ‘constant’.
Pretty crazy and a huge waste of my time narrowing down even this far!
mod_security needs a bit of time to be able to adapt to (one time investment).
You can enable error log and can see hints on what was blocked and what rule matched. Or can ask support to help. But this seems like an ideal situation that can’t be applied to existing sites (i will recommend to go this way for new sites.)
This leaves you vulnerable to code/spam injection.
I’m not really sure how much difference PHP5 can make here.
Unless on web9 you may be now seeing least of these errors. web9 is the alone server running all rules right now. If you wish to analyze by yourself, you can use something like Live HTTP headers. Also enable error logs for the domain so you can see a hint on what URL and what rule is being hit.
You can get more details from the support team.
You may try as stated above if you wish to resolve by yourself or just create a ticket and support will create necessary exclusions for this.
We can also share possible exclusion rules and if generic enough, we can add them server side.
My clients want to be able to post links to other sites on their web pages and I can’t tell them no. Most of the CMSes my clients are using include measures to prevent injection attacks. We’ll have to take the risk I guess.
Well, I have a site on web3 and I can’t post any messages that include “h ttp://” (minus the space of course). And are these forums running on web9? We can’t post certain things here because of the mod_security restrictions. The rules must be more broadly applied than to just web9.
I’m not upset that these changes were made and I’m not asking for them to be removed. I understand the need to provide strong security. But, can you please forewarn us? After fielding the complaint call from my client, it took me hours to troubleshoot the problem and find out why she couldn’t post a message containing a link when a month ago she could. I looked incompetent when I had to tell her it was a new security setting that I hadn’t forewarned her about. Please, give us this information up front!