Regex needed to match certain request uri's

Stopping hacker injection attempts using .htaccess

[Snoader]

Let's say, I want to block a request when a request URI is something like this: /forum/index.php?board=http://0xg3458.hub.io/pb.php?

I need to do this with a "setenvifnocase request_uri" entry in the .htaccess.

I've tried a lot of regex's, but I cannot find a regex that 'catches' the URI above. I've tried things like this (complete .htaccess file):

ErrorDocument 401 /401.php
ErrorDocument 404 /404.php
ErrorDocument 500 /500.php

AddOutputFilter INCLUDES .html
AddOutputFilter INCLUDES .htm

AddType application/x-httpd-php .html

setenvifnocase request_uri pb\.php\?$ bad_uri

<Limit GET POST>
Order Allow,Deny
Allow from all
Deny from env=bad_uri
</Limit>

(end of .htaccess)

Also a regex like "^(.*)pb\.php\?$" didn't work.

Can anyone help me with this one please?

Another example of an URI which I want to block: /forum/index.php?board=http://basink.web.id/n?

[jdMorgan]

I need to do this with a "setenvifnocase request_uri" entry in the .htaccess.

You didn't make clear why you need to use SetEnvIf, but if you want to test the query string, you'll need to use mod_rewrite.

This sets the bad_uri variable as does SetEnvIf, or you could use an [F] flag on the rule to directly respond with a 403-Forbidden response:

RewriteCond %{QUERY_STRING} pb\.php\?$
RewriteRule ^forum/index.php$ - [E=bad_uri:1]

Jim

[edited by: jdMorgan at 7:55 pm (utc) on Oct. 30, 2007]

[Snoader]

The reason I don't use the mod_rewrite module, is because I couldn't get this working:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^libwww-perl [OR]
RewriteCond %{HTTP_USER_AGENT} ^Wget
RewriteRule ^.*$ - [F]

While the following does work:

SetEnvIfNoCase User-Agent "^libwww-perl" bad_bot
SetEnvIfNoCase User-Agent "^Wget" bad_bot
<Limit GET POST>
order allow,deny
allow from all
deny from env=bad_bot
</Limit>

So I have two options: fixing the code which uses mod_rewrite, and use the solution which you provided, or block bad URI's the SetEnvIfNoCase-way. :)

So, is there anything wrong with the two RewriteCond-lines above?

[edited by: Snoader at 8:21 pm (utc) on Oct. 30, 2007]

[jdMorgan]

Nothing wrong that I see. How, specifically, did it "not work"? What did you get in the access log and error log when you tested it? Do any other simple rewriterules work?

SetEnvIf will be difficult/impossible to use, because it can't 'see' the query string attached to the URL.

Jim

[Snoader]

How, specifically, did it "not work"?

Clients with user-agents we were trying to block, were not stopped by the .htaccess. I didn't have access to the server log-files, so I couldn't check any error messages. But on my local Apache-server, I didn't get any errors.

But, for some strange reason, it does work now! Maybe after complaining, the virtual host provider changed (corrected) something without telling us.

Anyway, thank you very much for your help, especially your remark about the query string. :)

Cheers,
Sander

[jdMorgan]

It's also quite possible that you forgot to completely flush your browser cache after changing the code -- and thus were served a 'stale' response by your browser, instead of the request being sent to your server.

Over the long term, consider moving to a host that provides full access to all log files -- It may save you countless hours of frustration and/or revenue loss.

Jim