By robmorin on

Hello all.... My hosting provider added mod_security2 to their web server an dnow i get errors when trying to edit a page the error is....

[Wed May 16 14:41:44 2007] [error] [client 206.248.146.164] ModSecurity: Access denied with code 400 (phase 2). Pattern match "\\\\%(?![0-9a-fA-F]{2}|u[0-9a-fA-F]{4})" at ARGS:body. [id "950107"] [msg "URL Encoding Abuse Attack Attempt"] [severity "WARNING"] [hostname "www.stupidguytalk.org"] [uri "/?q=node/24/edit"] [unique_id "s7B7cH8AAAEAAGlCZFYAAAAA"]

The Hosting people are great they tried to help me out buy adding an exclude rule to mod_security's exclude.conf file like this...


SecRuleRemoveById 960015
SecRuleRemoveById 960032
SecRuleRemoveById 950107

However i still keep getting the same errors...

Can anyone help, please....

I am using Drupal 5.1

Thanks...
Rob
Montreal, Canada

⋅ Categories: Drupal 5.x

Comments

czarphanguye’s picture

czarphanguye commented

I also run ModSecurity2 and Durpal v5. Due to a few issues I had to add the following exclude(s) to my httpd's conf file. In this example below, Project-release-settings was causing 

[Tue May 22 15:32:16 2007] [error] [client xx.xx.xx.xx] ModSecurity: Access denied with 
code 400 (phase 2). Pattern match "\\\\%(?![0-9a-fA-F]{2}|u[0-9a-fA-F]{4})" at ARGS:proje
ct_release_default_version_format. [id "950107"] [msg "URL Encoding Abuse Attack Attempt"
] [severity "WARNING"] [hostname "example.com"] [uri "/admin/project/project-release-s
ettings"] [unique_id "8grcIUVBKIcAAFlzEjIAAAAA"]

Grab the path from your apache's log.

<LocationMatch "/admin/project/project-release-settings">
        SecRuleRemoveById 950107
</LocationMatch>

Restart httpd, all better. ;-)

P.S. I notice you are not using clean URLs... So perhaps LocationMatch may have to be set to /index.php which might FUBAR the entire point of modsecurity. *shrugs*

MadTogger’s picture

MadTogger commented

Hi,

I am suddenly having these issues.

What I would like to know if possible is that the fix here can be done by myself or does it need to be done server side by my host?

Regards..,

K

freddym’s picture

freddym commented

It's an old post but I think adding more info to it may help people who are facing this problem today :)

In order to reproduce/test this error try to enter the following text when creating content or in a text filed of a webform: "select a shoe from the store where you are" (this should trigger an sql injection rule and then trigger a 500.shtml page not found error)

MadTogger: you will need your host administrator to help you make this changes in the server.

For those who have root access in Linux here is the solution that worked for our installation (Drupal 6 on CentOS 5 with Apache 2 hosted by LiquidWeb in a dedicated server) IMPORTANT: we are NOT using clean URLs so we had to disable these rules for the whole domain. If you are using clean URLs you may fine-tune your LocationMatch as czarphanguye mentioned above.

1) Find the comment line that references the include file for your domain for customizing mod_security, that line is located in the section of the conf file for the virtual host of your hosting account in /etc/httpd/conf/httpd.conf. The line will read something like:

# To customize this VirtualHost use an include file at the following location
# Include "/usr/local/apache/conf/userdata/std/2/<MYACCOUNT>/www.<MYSITE>.com/*.conf"

NOTE the actual values of <MYSITE> and <MYACCOUNT> in this line, you will need them.

2) Create an include file to configure the mod_security for www.<MYSITE>.com so we can get rid of the sql injection rules that do not allow creating text that have patterns that look like an SQL instructions "select xyz from ppp" or "insert xyz into ppp". You may need to create some sub-directories too.
The new file is located in "/usr/local/apache/conf/userdata/std/2/<MYACCOUNT>/www.<MYSITE>.com/", the file name is itxmodsec2.conf and its content is:
<LocationMatch "/">
SecRuleRemoveById 300013
SecRuleRemoveById 300015
SecRuleRemoveById 300016
</LocationMatch>
3) Delete the comment that references this include line in the conf file for the virtual host of this account in /etc/httpd/conf/httpd.conf (remove the '#' before the Include) Then the lines should look something like:
# To customize this VirtualHost use an include file at the following location
Include "/usr/local/apache/conf/userdata/std/2/<MYACCOUNT>/www.<MYSITE>.com/*.conf"

4) Restart Apache

Test again to try to reproduce the error. It worked for us.

IMPORTANT: your account will not be protected by Mod_security against SQL injection attacks. As usual, make sure you follow good secure coding standards for your custom modules: http://drupal.org/writing-secure-code

Regards,
Freddy

jakeschlachter’s picture

jakeschlachter commented

After doing an hour of web research on this, here's what I think is going on.

mod_security on Dreamhost (and possibly other hosting providers) ships with default rules that will intermittently bite Drupal users. Each of these rules is just a regex match on text in a node, or the URL being requested. The rule is triggered intermittently - a reload usually solves the problem (and fails to trigger the rule).

The "page" that is "not found" is not actually the page the user is looking for. It's internal_error.html that is to be served when PHP dies prematurely, on account of being blocked by mod_security for this request. Creating the internal_error.html file in the Drupal root should fix that problem.

You can add the rules above to your .htaccess file for your site, if you don't have root permissions on your server. Instead of using LocationMatch, which is not valid for .htaccess, use this instead:

<IfModule mod_security.c>
SecRuleRemoveById 960010
SecRuleRemoveById 960015
SecRuleRemoveById 960032
SecRuleRemoveById 950107
</IfModule>

Hope that helps. I have just made the change on my web server, and am waiting to see if any additional mod_security errors will be generated. (They look like "Premature end of script headers" in the httpd error.log)

jakeschlachter’s picture

jakeschlachter commented

Several users on my site have reported that the problem is ongoing. I'm adding the additional rules listed above,

SecRuleRemoveById 300013
SecRuleRemoveById 300015
SecRuleRemoveById 300016

and I'll see if I have any better luck. After that, I will likely turn on mod_security logging to see which rule(s) are being triggered, and add them.