RewriteCond for banning exploits

Will this htaccess coding work?

[grandma genie]

Hi everyone,

I am planning to include this coding in htaccess. Is this correct?

# BAD BEHAVIOR BLOCK rules to ban exploits
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [NC,OR]
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*(script|iframe).*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [NC,OR]
RewriteCond %{QUERY_STRING} cPath=http:// [NC,OR]
RewriteCond %{QUERY_STRING} /self/ [NC,OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9a-z]{0,2}) [NC]
RewriteRule ^.* - [F]

Grandma_genie

[g1smd]

The use of .* sub-patterns will make the code so inefficient that it will massively slow the page-loading speed for every request arriving at your server.

In many cases, the patterns might be further simplified. The code is correct if it rejects all malicious requests, and allows all non-malicious requests; we could never know for your server what those would be.

[grandma genie]

This idea was a suggestion in the oscommerce forum, since that is open to so many hacking attempts. I have had the following types of hack attempts on the server I am on (hosted):

173.10.91.n - - [25/Oct/2010:09:06:45 -0400] "GET /phpadmin/scripts/setup.php HTTP/1.1" 403 317 "-" "ZmEu"
173.10.91.n - - [25/Oct/2010:09:06:48 -0400] "GET /phpmyadmin/scripts/setup.php HTTP/1.1" 403 319 "-" "ZmEu"
173.10.91.n - - [25/Oct/2010:09:06:51 -0400] "GET /phpmyadmin2/scripts/setup.php HTTP/1.1" 403 320 "-" "ZmEu"

and

210.24.213.nn - - "GET /osc/index.php?cPath=h**p://217.218.225.n:2082/index.html? "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"
210.24.213.nn - - "GET /osc/index.php?cPath=h**p://217.218.225.n:2082/index.html? "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"

I have ZmEu blocked in htaccess, but this type of hack can be used when ZmEu is not, so I want to try to prevent those.

And I don't have an example but I know the base64_encode has been attempted also.

How do you tell the server that if it sees these types of exploits it should serve the offender a 403 forbidden message? These exploits do not necessarily begin the query string but are within it. I tried to find a way to prevent these types of exploits via Google and came up with the example shown. I do not have the expertise in Apache Rewrite rules to be able to edit them. The only part of the code that made sense was this one:

# BAD BEHAVIOR BLOCK rules to ban exploits
RewriteCond %{QUERY_STRING} cPath=http:// [NC]
RewriteRule ^.* - [F]

I have searched the webmasterworld site for ideas and have checked the Apache site and others, but couldn't find examples that applied to my situation. Any suggestions would be more than welcome.

[jdMorgan]

The problem is that the answer to "What is the correct code to block unwelcome requests" always hinges on another question: "What requests do you require to be considered to be unwelcome on your site?"

For example, you could easily block all requests with query strings containing any of
mosConfig, base64_encode, script, iframe, GLOBALS, cPath=http://, /self/, or _REQUEST
with a single RewriteCond, but ONLY if your site doesn't use any query strings containing *any* of those sub-strings for any required function.

If your site uses queries that resemble those, then you need a sophisticated pattern to differentiate good from bad requests. If your site doesn't use queries that look like those at all, then it may not even be worthwhile to detect and block those requests, because they can't possibly do anything on your site.

So the problem in trying to search forums for code that does exactly what you need is that the chances are that it doesn't exist, because no-one else's site is exactly like yours. That's why we emphasize teaching and learning in this forum, because it is impossible to provide code that works for more than a very few sites --much less for all sites-- and because only the site owner can possibly figure out all of the requirements to match the code to the specific site.

Jim

[grandma genie]

Yes, I understand. That's why I checked the oscommerce site for help with hack attempts. They pretty much give out the same advice to all osc users. There are two contributions for securing a site, and one of them was similar to what I was attempting to do, but the original was adding pages to my root folder. I was really just trying to get rid of the same hack attempt that I get all the time and really despise.

210.24.213.nn - - "GET /osc/index.php?cPath=h**p://217.218.225.n:2082/index.html? "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"

This comes in all the time, same referring URL, but different visitor IPs. This 217.218 IP is in Iran. I want to include this one section in htaccess. I have blocked the IP, but it doesn't stop the hackers from continuing to try to do a redirect in the URL.

I would like to add just this in htaccess. I don't think this will mess up the site.

# BAD BEHAVIOR BLOCK rules to ban exploits
RewriteCond %{QUERY_STRING} cPath=http:// [NC]
RewriteRule ^.* - [F]

[g1smd]

The value of cpath is always supposed to be a number, so you can simplify with cpath=([^0-9]+) or similar. If the value isn't digits, fry the request.

[jdMorgan]

Yes, either the "not a digit" pattern g1smd posted above or this more-robust "either http or https" pattern should work just fine.

# Ban attempted cpath=<URL> OS Commerce exploit
RewriteCond %{QUERY_STRING} cPath=https?:// [NC]
RewriteRule ^ - [F]

Jim

[grandma genie]

Thanks much. As for these other terms that might occur in a query string: mosConfig, base64_encode, script, iframe, GLOBALS, cPath=http://, /self/, or _REQUEST, I don't think those would appear in general use clicking on links on my site. They may exist in the PHP code running oscommerce, but should not appear in a query string. I don't think I've actually seen any of those, except the script one, which I believe is a PHP code injection attack. And I see the cPath=http is a RFI (remote file inclusion) attack. I assume Apache looks for those terms in the query string, and if htaccess says "fry" it, it is stopped.