There's two threads

here [webmasterworld.com]

and

here [webmasterworld.com]

Thank you wilderness. These threads are great but there is no indication of how to block these requests using .htaccess

I would like to know how implement that.

Thanks

Well, here's one way:

RewriteCond %{QUERY_STRING} [^a-z](declare¦char¦set¦cast¦convert¦delete¦drop¦exec¦insert¦meta¦script¦select¦truncate¦update)[^a-z] [NC]
RewriteRule (.*) - [F]

Note that case variations have been seen, so the [NC] flag is used to make the string comparison case-insensitive.

This code returns 403-Forbidden response to requests for any URLs with any of those command or parameter keywords in the appended query string.

[added] Replace all broken pipe "¦" characters with solid pipe characters before use; Posting on this forum modifies the pipe characters. [/added]

Jim

[edited by: jdMorgan at 6:52 pm (utc) on Aug. 26, 2008]

Thank you Morgan.

If I enter the following in the address bar I don't get blocked.
Is there a different way to handle this?
Thanks

mydomain.com/myfile.php?;DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434C41524520

Do you have other working rewriterules? Did you change the pipes as noted above?

I'm sorry. I didn't noticed the pipes.
It's working like a charm. Wow!

Thanks

I'm getting the same thing, so if I append the above code to a pre exisitng .htaccess file, will this have any effect on what I already have in the file? I would think not, but not being a coder I need to be sure.

I've had a RewriteCond and RewriteRule blocking query strings for DECLARE [NC] for awhile and recently modified it to Jim's suggested RewriteCond. The long string of letters and numbers (eg. CAST(0x4445434C41524520405....) that are included in the query causes the server to give a 406 (Not Acceptable) error instead of a 403 error. This occurred with either my original RewriteCond or Jim's.

If I include the query string without the long string of letters and numbers in a request to test the block, I get a 403 error. (eg. ;DECLARE%20@S%20CHAR(4000);SET%20@S=CAST)

Not sure I should be concerned or not - it's still serving an error.

> if I append the above code to a pre exisitng .htaccess file, will this have any effect on what I already have in the file?

You should place the code snippet "early" in your list of mod_rewrite rules; For example, there is no use in redirecting such abusive client requests to canonicalize the domain name, or in rewriting thsee requests to another filepath.

> 406 (Not Acceptable)

This indicates that MultiViews may be enabled on your server. If you are not using content negotiation, try adding

 Options -MultiViews 

to your .htaccess file (Or you could also add "-MultiViews" to any pre-existing "Options" line).

---

I should also add that this code is really only useful if you use scripts which directly access SQL on your server, and want to protect your site from "outside" requests arriving from the Web. If you don't have mySQL installed, then all this code does is "give you the satisfaction" of issuing a 403 response instead of serving the page that was requested with the injected squery string attached. But it's doubtful that the malicious program sending these injection attempts even bothers to check the target server response -- It's more likely a "fire and forget" kind of thing...

Jim

My root .htaccess file starts with these lines:

ErrorDocument 403 "Error 403 / Access Denied.

Options +FollowSymLinks -Indexes -MultiViews
RewriteEngine on

-Multiviews has been there all along.

Thanks jdMorgan. That worked for us. We had been getting hit with those SQL Injection tests for a few weeks now. I had no clue if they had found their way in or not, but hopefully this will help keep them out in the future.

Thanks Jim, much appreciated. Giving it a whirl right now.

I am getting attacks on pages like this:
myfile.php?pageid=43;DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434C415245204

The code above works for page.php?;DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434C415245204
but doesn't seem to help when pageid=# is included. Is there a way to include both page types?

Thanks.

The code above doesn't care about other parameters, so something else is likely interfering. Check the ordering of this new rule with respect to others which may match the requested URL before this rule can run.

Also beware of Alias, Redirect, MultiViews, AcceptPathInfo, and other factors which can pre-empt mod_rewrite rules.

Jim

Thanks, JD. Regarding the order, I have it listed above any other mod_rewrite rules.

Also beware of Alias, Redirect, MultiViews, AcceptPathInfo, and other factors which can pre-empt mod_rewrite rules.

Sorry. My assumption that if it worked in the one instance it should work for the other was obviously incorrect. Thanks anyway.

Hi Jim, I have tried your rule in my htaccess file on a domain I have and it works a charm - thank you so much.

Just one question - I have several sites on one dedicated server, so I guess I could add these lines to each separate htaccess file (ie on a per site basis), but can it be placed to work server-wide without having to alter each individual htaccess file? ie at some top level htaccess file? If so, where exactly is that file?

Since .htaccess files are per-domain, you can't use .htaccess. But if you have server configuration privileges, you could put the code into the httpd.conf file.

Jim

Thanks, Jim. I was wondering if there is an alternative/additional way to do this in the httpd.conf file, by returning a 403 for any url that was longer than, say 150 characters (depending on what particular set-up one has). Is that possible or even desireable?

Man_in_Poland

> returning a 403 for any url that was longer than, say 150 characters

Possible? Yes, of course:

RewriteRule .{150,} - [F]

Desireable? That would depend on your normal site traffic, and I can not recommend for or against this.

But note that you asked about the URL, and that is not where the problem is here. The problem is in the query string, which is not part of a URL, but rather, data attached to a URL to be passed to the resource at that URL. So the above code probably won't do what you really want. You'd need something like this:

RewriteCond %{QUERY_STRING} .{150,}
RewriteRule .* - [F]

BTW, I've seen mod_rewrite get confused when the quantifier exceeds 250 -- Not 255 or 256, but 250. So if you need more that 250 characters, then use a base quantifier less than 251, and then either include multiple instances, or use nested quantifiers e.g. ".{250}.{250}.{250,}" or "(.{250}){3,}" for a maximum of 750 characters in this example.

Jim

See also the last post on the very last page of [webmasterworld.com...]

@jdMorgan

RewriteCond %{QUERY_STRING} [^a-z](declare¦char¦set¦cast¦convert¦delete¦drop¦exec¦insert¦meta¦script¦select¦truncate¦update)[^a-z] [NC]
RewriteRule (.*) - [F]

We may also just want to touch base on the fact that this write will directly interfere with some Wordpress functions (changing things like skins and removing posts).

Also, it may provide a challenge (by way of 403) to those who would provide sitewide search using any of the terms contained in the write.

Use a RewriteCond to exclude WP and/or search page URL-paths if needed.

Alternately, specify a specific URL-path to which the rule is to apply using the RewriteRule pattern, instead of the ".*" pattern shown above.

There is no "one-size-fits-all" solution.

Jim

Instead of banning the words, you might have better luck banning the punctuation that is required for those injected commands to work (such as parentheses), as long as your own URLs don't use those punctuation characters.