.
.
This definitely is confusing, but do we really know that it isn't effectively blocking? It's one thing to throw a test at it such as "http:/www.yourdomain.com/?=http://foo.bar" -- because those specific tests aren't going to modify anything on the server / exploit anything in actuality.
A real test would be to actually throw an exploit [that should be blocked by modsecurity] at a site that is truly vulnerable [if mod_security were disabled] and then see if the exploit happens.
I say that because:
- As others have reported, if I have some rewrite rules in an htaccess file [such as the standard Wordpress rewrite rules when using permalinks], it does appear to display the site page rather than an error if I don't have a 403.shtml in the document root.
- mod_security does log it as being blocked
Code:
[Tue Jun 26 10:04:24 2012] [error] [client 1.2.3.4] ModSecurity: Access denied with code 403 (phase 2). Match of "rx ://%{SERVER_NAME}/" against "MATCHED_VARS:" required. [file "/usr/local/apache/conf/modsec_rules/10_asl_rules.conf"] [line "493"] [id "340162"] [rev "274"] [msg "Atomicorp.com WAF Rules: Remote File Injection attempt in ARGS (AE)"] [data "http://foo.bar"] [severity "CRITICAL"] [hostname "www.mydomain.com"] [uri "/"] [unique_id "[email protected]"]
- Apache logs a 403 as well, along with producing the regular page output (item B)
Code:
1.2.3.4 - - [26/Jun/2012:12:37:45 -0400] "GET /?=http://foo.bar HTTP/1.1" 403 51877 "-" "Mozilla/5.0 (Windows NT 6.0; rv:13.0) Gecko/20100101 Firefox/13.0.1"
1.2.3.4 - - [26/Jun/2012:12:37:46 -0400] "GET /wp-includes/css/admin-bar.css?ver=3.4 HTTP/1.1" 304 - "http://www.mydomain.com/?=http://foo.bar" "Mozilla/5.0 (Windows NT 6.0; rv:13.0) Gecko/20100101 Firefox/13.0.1"
1.2.3.4 - - [26/Jun/2012:12:37:46 -0400] "GET /wp-content/plugins/contact-form-7/includes/css/styles.css?ver=3.2 HTTP/1.1" 304 - "http://www.mydomain.com/?=http://foo.bar" "Mozilla/5.0 (Windows NT 6.0; rv:13.0) Gecko/20100101 Firefox/13.0.1"
1.2.3.4 - - [26/Jun/2012:12:37:46 -0400] "GET /wp-includes/js/jquery/jquery.js?ver=1.7.2 HTTP/1.1" 304 - "http://www.mydomain.com/?=http://foo.bar" "Mozilla/5.0 (Windows NT 6.0; rv:13.0) Gecko/20100101 Firefox/13.0.1"
1.2.3.4 - - [26/Jun/2012:12:37:46 -0400] "GET /wp-includes/js/admin-bar.js?ver=3.4 HTTP/1.1" 304 - "http://www.mydomain.com/?=http://foo.bar" "Mozilla/5.0 (Windows NT 6.0; rv:13.0) Gecko/20100101 Firefox/13.0.1"
1.2.3.4 - - [26/Jun/2012:12:37:46 -0400] "GET /wp-content/plugins/contact-form-7/includes/js/jquery.form.js?ver=3.09 HTTP/1.1" 304 - "http://www.mydomain.com/?=http://foo.bar" "Mozilla/5.0 (Windows NT 6.0; rv:13.0) Gecko/20100101 Firefox/13.0.1"
1.2.3.4 - - [26/Jun/2012:12:37:46 -0400] "GET /wp-content/plugins/contact-form-7/includes/js/scripts.js?ver=3.2 HTTP/1.1" 304 - "http://www.mydomain.com/?=http://foo.bar" "Mozilla/5.0 (Windows NT 6.0; rv:13.0) Gecko/20100101 Firefox/13.0.1"
1.2.3.4 - - [26/Jun/2012:12:37:47 -0400] "GET /wp-includes/images/admin-bar-sprite.png?d=20111130 HTTP/1.1" 304 - "http://www.mydomain.com/wp-includes/css/admin-bar.css?ver=3.4" "Mozilla/5.0 (Windows NT 6.0; rv:13.0) Gecko/20100101 Firefox/13.0.1"
And when mod_security is disabled, Apache logs the usual 200 | 304 status:
Code:
1.2.3.4 - - [26/Jun/2012:12:49:18 -0400] "GET /?=http://foo.bar HTTP/1.1" 200 44350 "-" "Mozilla/5.0 (Windows NT 6.0) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5"
1.2.3.4 - - [26/Jun/2012:12:49:18 -0400] "GET /wp-content/themes/journalist/style.css HTTP/1.1" 200 8366 "http://www.mydomain.com/?=http://foo.bar" "Mozilla/5.0 (Windows NT 6.0) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5"
1.2.3.4 - - [26/Jun/2012:12:49:18 -0400] "GET /wp-content/plugins/contact-form-7/includes/css/styles.css?ver=3.2 HTTP/1.1" 200 887 "http://www.mydomain.com?=http://foo.bar" "Mozilla/5.0 (Windows NT 6.0) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5"
1.2.3.4 - - [26/Jun/2012:12:49:18 -0400] "GET /wp-content/plugins/wp-recaptcha/recaptcha.css HTTP/1.1" 200 1739 "http://www.mydomain.com/?=http://foo.bar" "Mozilla/5.0 (Windows NT 6.0) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5"
1.2.3.4 - - [26/Jun/2012:12:49:18 -0400] "GET /wp-content/plugins/contact-form-7/includes/js/jquery.form.js?ver=3.09 HTTP/1.1" 200 14238 "http://www.mydomain.com/?=http://foo.bar" "Mozilla/5.0 (Windows NT 6.0) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5"
1.2.3.4 - - [26/Jun/2012:12:49:18 -0400] "GET /wp-content/plugins/contact-form-7/includes/js/scripts.js?ver=3.2 HTTP/1.1" 200 6630 "http://www.mydomain.com/?=http://foo.bar" "Mozilla/5.0 (Windows NT 6.0) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5"
1.2.3.4 - - [26/Jun/2012:12:49:18 -0400] "GET /wp-includes/js/jquery/jquery.js?ver=1.7.2 HTTP/1.1" 200 94861 "http://www.mydomain.com/?=http://foo.bar" "Mozilla/5.0 (Windows NT 6.0) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5"
1.2.3.4 - - [26/Jun/2012:12:49:19 -0400] "GET /wp-content/themes/journalist/images/top.gif HTTP/1.1" 200 169 "http://www.mydomain.com/?=http://foo.bar" "Mozilla/5.0 (Windows NT 6.0) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5"
1.2.3.4 - - [26/Jun/2012:12:49:20 -0400] "GET /wp-content/themes/journalist/favicon.ico HTTP/1.1" 200 1150 "-" "Mozilla/5.0 (Windows NT 6.0) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5"
When mod_security is enabled and a 403.shtml (or whatever errorpage corresponds to the status code your mod_security is set to deliver upon blocking) is present, the only thing that shows up in the Apache log is:
Code:
1.2.3.4 - - [26/Jun/2012:12:57:31 -0400] "GET /?=http://foo.bar HTTP/1.1" 403 6 "-" "Mozilla/5.0 (Windows NT 6.0) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5"
Notice, the above example is what Apache shows in the log if a ###.shtml errorpage exists. If one doesn't exist, it shows up like "item B" farther up above.
I think a real test of whether it's blocking the malicious / questionable content is, for example, to actually throw a real exploit at a known vulnerable version of Wordpress [where the Wordpress is using permalinks and has the .htaccess file in place].
Either way, this strangeness shouldn't occur. At the very least something is confused. And the worst case is that mod_security is actually bypassed.
Mike