Server Error 500 with Filesmatch and Header

Followed the syntax by the book...

[g1smd]

What's wrong with this?

<FilesMatch "\.(php多tml多tm地sp夸sp地spx夸spx圭fm如l)$">
Header set imagetoolbar "no"
Header set MSSmartTagsPreventParsing "TRUE"
</FilesMatch>

I get Internal Server Error 500 every time. Syntax is as per the book.

Server uses Apache 2.0.54.

.

This does not cause an error...

<FilesMatch "\.(php多tml多tm地sp夸sp地spx夸spx圭fm如l)$">
# Header set imagetoolbar "no"
# Header set MSSmartTagsPreventParsing "TRUE"
</FilesMatch>

...so it is the Header lines that appear to be the problem.

[jdMorgan]

Well, you could either add an exception to the rule, or refine its current pattern, for example by adding a semicolon in front of "set" to make it ";set".

Understand that the anti-SQL-hack rule was a hack itself, posted when the attack was only a few days old. The patterns can be refined in the light of 'history' since the early days.

Jim

[g1smd]

I haven't seen the hack out in the wild, so all I know about is what has been posted here at WebmasterWorld.

I might comment about this in the original thread, as it is an important point.

[jdMorgan]

It sort of goes without saying that any pattern as "permissive" as this will have to be "verified" against all valid query strings to the site on which it is installed...

Here's an "in the wild" appearance (so far today) :

71.230.209.24* - - [21/Sep/2008:06:21:56 -0400] "GET /?';DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434C415245204054207661726368617228323535292C4043207661726368
6172283430303029204445434C415245205461626C655F437572736F7220435552534F5220464F522073656C65637420612E6E616D652C
...
544348204E4558542046524F4D20205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F
437572736F72204445414C4C4F43415445205461626C655F437572736F72%20AS%20CHAR(4000));EXEC(@S); HTTP/1.1" 403 666 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)"
...
71.230.209.24* - - [21/Sep/2008:06:21:57 -0400] "GET /?;DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434C415245204054207661726368617228323535292C4043207661726368
6172283430303029204445434C415245205461626C655F437572736F7220435552534F5220464F522073656C65637420612E6E616D652C
...
544348204E4558542046524F4D20205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F
437572736F72204445414C4C4F43415445205461626C655F437572736F72%20AS%20CHAR(4000));EXEC(@S); HTTP/1.1" 403 666 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)"

Jim

[g1smd]

I guess that testing for two of those words to be present would make it less likely to trigger on real URLs.

An alternative is to test if there are any brackets in the query string, or semi-colons, or the @ symbol - anything that would never appear in a real query string used within the site.

Also, testing that the query string itself is more then a certain length looks like a useful thing to do.

.

Would this work as a test?

RewriteCond %[QUERY_STRING] !^([A-z0-9&=.+-]{1,30})$

Test fails if the query string is more than 30 characters long and/or contains stuff other than A-Z characters 0-9 numerals and the & = . + - symbols.

[jdMorgan]

and/or is not a Boolean logic operator, so you need two RewriteConds:
If ( (Length > 30) OR ( contains anything except [a-z0-9&=+.\-] [NC] ) ) Then Deny

RewriteCond %{QUERY_STRING} declare.+char.+;set [NC,OR]
RewriteCond %{QUERY_STRING} .{31,} [OR]
RewriteCond %{QUERY_STRING} [^a-z0-9&=+.\-] [NC]
RewriteRule .* - [F]

One of a million ways to do it. Webmaster's choice... :)

Jim

[g1smd]

I'll use a combination of different things, but that lot is a good start.

Thanks.

[g1smd]

False matches hadn't been a concern before. On previous sites none of those words would have ever matched any of the parameter names, and all of the parameter values were always numeric.

It is just this current site that uses words, and multiple words, in parameter values. However that parameter is no longer going to be exposed out to the world once the navigation bar is redesigned using PHP and CSS, instead of the current partial-JavaScript implementation.

The site will then no longer use parameters, but will use URL rewriting instead. Most of that is already done. There's just a small number of tweaks to do, regarding the internal filenames on the server.

[jdMorgan]

Yup, and that is why there is no "one-size-fits-all" solution to most URL-rewriting problems. The attributes of efficient, compact, and simple code are mutually-exclusive with universal deployment. So the "right answer" strongly depends on the "URL-set" of the given site, and universal solutions are rare.

Jim

[g1smd]

I see you stress that fact every time someone asks for some code, but were a bit vague as to what they want that code to do: rewrite vs. redirect, and the format of incoming URL requests that it should work, and not work, for.

Even after writing down what I thought I needed, testing (with 1100 test URLs fed into XenuLinkSleuth) revealed that I had only covered about 80% of what needed to be done and had mis-specified several things. I also discovered that I needed to add another few dozen test URLs to my test list.

Indeed, last night, one final little clean up I implemented was something like:

RewriteRule ^pages?(\.php)?[b]/[/b][clxvi][b]+/[/b]c(alendar她ntact)\.(html?如hp)$ http://www.example.com/c$3.html? [R=301,L]

and I thought I was being clever to use the + to ensure that at least one character must be present.

After installation, the site went haywire, and more than a quarter of my test URLs failed in some way: either generating a 404, or redirecting somewhere unwanted, and then mostly generating a 404 at that late stage.

It turns out, after some experimentation and further thought, that what I really needed was:

RewriteRule ^pages?(\.php)?[b](/[/b][clxvi][b]+)?/[/b]c(alendar她ntact)\.(html?如hp)$ http://www.example.com/c$3.html? [R=301,L]

Subtle difference, big change in the results.

It now does what it should for expected URLs and for the range of unexpected URLs that I have now tested it for.

[g1smd]

Just to finish this off. I went with this in the end:

# Deny Hacker Query Strings Looking to Exploit Database Features:

 RewriteCond %{QUERY_STRING} declare圭har存et圭ast圭onvert圬elete圬rop圯xec夷nsert妃eta存cript存elect宇runcate守pdate [NC]
 RewriteCond %{QUERY_STRING} [^a-z0-9&=+.-]  [NC,OR]
 RewriteCond %{QUERY_STRING} .{31,}
 RewriteRule . -  [F]

It blocks access when a banned word appears with non-valid punctuation, and it blocks access when a banned word appears in a query string which is more than 30 characters long.

It assumes that when the word appears in a short query string with regular punctuation, then there is no problem with the URL. I hope I got my logic all correct.