ModSecurity: Access denied with code 403 & SQL injection Detected

I have a wordpress plugin that is attempting to save information but is being blocked. This may be a false positive I’m not sure. How can I enable one specific plugin to bypass whatever rule is causing it to be blocked?

Below is the error code my host is throwing at me.

Read More

[Tue Sep 29 08:50:45 2015] [error] [client xxx.xxx.xxx.xxx] ModSecurity: Access denied with code 403 (phase 2). Operator GT matched 15 at TX:sql_injection_score. [file "/etc/httpd/modsecurity.d/modsecurity_crs_49_inbound_blocking.conf"] [line "51"] [id "4049002"] [msg "SQL Injection Detected (score 20): XSS Attack Detected"] [hostname "xxxxx.com"] [uri "/wp-admin/admin.php"] [unique_id "VgqJJWjP6lgAAEaaTogAAAAZ"]

It’s an already existing plugin. It is called WP Social Invitations – wordpress.org/plugins/wp-social-invitations To be completely honest most of this is above my head. I’m not sure what code I would even need to show you. The developer told me that they use the wordpress default wp_options table to store data, so this error shouldn’t occur

Related posts

1 comment

  1. For a start view here to see some more information about ModSecurity:
    “ModSecurity Access Denied” in logs. I don’t understand what its telling me.. Should I be concerned?

    The error you’ve given shows that, for some reason, ModSecurity has flagged the request and blocked it.

    The rule that has fired (4049002) is saying that a threshold has been passed. This must mean previous rule(s) have set that variable. So you need to give us the details on the previous errors that have set the sql_injection_score – presumably on the lines just above the one you’ve given.

    Alternatively, you could just add the following config to your Apache config (e.g. .htaccess file) to prevent this rule firing at all:

    SecRuleRemoveByID 4049002
    

    However this removes the protection that rule gives you for SQL injection attacks. So the better option is to find the original rule(s) that caused this to fire and to see if you can whitelist just the cause of that, rather than the blanket whitelisting of this entire rule.

Comments are closed.