Directives

It seems these particular regular expressions are very good at finding bugs in GitHub's markdown, take the code blocks with a grain of salt and refer to the actual file when in doubt.

<Files .htaccess>
Order Allow,Deny
Deny from all
</Files>

Denies outside access to the .htaccess file itself. Should always be in your .htaccess file.

IndexIgnore *

Disables direct browsing of directories. Not always crucial, but more often then not you want to disable directory browsing.

RewriteCond %{QUERY_STRING} (environ(?!ment)|localhost|mosconfig)
RewriteCond %{QUERY_STRING} (menu|mod|path|tag)\=\.?/?
RewriteCond %{QUERY_STRING} boot\.ini
RewriteCond %{QUERY_STRING} echo.*kae
RewriteCond %{QUERY_STRING} (length\(.*\)|length%28.*%29|len\(.*\)|len%28.*%29)

Block attempts with the phrases "environ" (but not "environment"), "localhost", etc. If you attempt to write some kind of article, blog post, comment, etc with these words in the body or title you may have difficulties submitting or viewing your content. These largely block malicious attempts at scanning your web environment. Blocked urls are of the type example.com/?menu=./, example.com/?boot.ini, and example.com/?length(x).

RewriteCond %{QUERY_STRING} \.\./

Block attempts at mucking around in your directories. Trying to post some kind of directory structure via plain text might meet with failure. Blocked urls would include something of the kind example.com/?../../../.

 RewriteCond %{QUERY_STRING} (\\\s*?=\s*?\\\\|%5C(%20)*?%3D(%20)*?%5C%5C) [NC,OR]

Blocks attempts of the type "\=\\" and it's variants. This is largely used for probing to test if a system is vulnerable. Blocked urls look like example.com/?\=\\.

RewriteCond %{QUERY_STRING} (\'[0-9]\'\s*?=\s*?\'[0-9]\'|\'[0-9]\'\s*?%3D\s*?\'[0-9]\')
RewriteCond %{QUERY_STRING} ([0-9]\s*?=\s*?[0-9]|[0-9]\s*?%3D\s*?[0-9])

Block attempts at sql injection testing of the kind "x=y" (and the "'x'='y'" variant), with x and y being some kind of integer. Would block any attempt at something similar in legitimate content. Blocked urls might include example.com/?0=9 or example.com/?'0'='9'.

RewriteCond %{QUERY_STRING} (user%2Bchar%28[0-9]*%29|user%2Bchar\([0-9]*\)|user\+char\([0-9]*\)|user\schar\([0-9]*\)|user%2520char\([0-9]*\)|user%20char\([0-9]*\))

Block queries of the kind "user char(x)" and their variations (specifically "user+char(x)") where x is some integer. Would block something similar in legitimate content. Blocked urls would resemble example.com/?user char(9).

RewriteCond %{QUERY_STRING} (group_concat\(.*\)|group_concat%28.*%29|version\(.*\)|version%28.*%29|database\(.*\)|database%28.*%29)

Blocks a series of functions that people shouldn't be poking at.

RewriteCond %{QUERY_STRING} (\*|\[|\]|:|\^|%5B|%5D|%3A|%5E) [NC,OR]

Blocks any use of the "*", "[", "]", and ":" character. May be a little extreme in some instances, but prevents a large range of sql injections and attempts at injection scanning. Though, this could cause problems if you're trying to use the characters legitimately via plain text.

RewriteCond %{QUERY_STRING} (aND|SELECT|XoR|SeAo1)

Blanket rule for various sql injections. These can be hard to target, as they tend to be common words, but I've seen a lot of strange capitalization that is easily targeted (so make sure not to use the "NC" tag). I suspect this happens because of some widely distributed injection script with lazy capitalization, so the effectiveness of this rule may be temporary. "SeAo1" is a small exception as I have no idea what it actually does (if anything, I suspect it is only some dummy text attached to injections, but we can still block it).

RewriteCond %{QUERY_STRING} (<script>|%3Cscript%3E)

Block attempts at injecting javascript via the "<script>" element. If you attempt to write some kind of article using with a plain text encoded "<script>" element you may have difficulties with your content. Blocked urls would resemble example.com/?<script>.

RedirectMatch 403 (https?|ftp|php)\://

Block attempts at referencing various protocols. Blocked urls would resemble example.com/?http:// or example.com/?php://, etc.

RedirectMatch 403 /(cgi|https?|ima|ucp)/

Similar to the previous. Blocker urls resemble example.com/?/http/ or example.com/?/cgi/, etc.

 RedirectMatch 403 \.(cgi|asp|aspx|cfg|dll|exe|jsp|mdb|sql|ini|rar)$

Block access to specific file types. Blocked urls include example.com/?file.cgi, etc.

RedirectMatch 403 /(contac(?!t)|fpw|install|pingserver|trackback)\.php

Block access to specifically named php files (contac.php is blocked, but not contact.php). Some of these may be legitimate pages (trackback.php for example) and you may want to delete them from the statement. This particular rule can be somewhat temporary, it could be that sometimes you want to block a page and sometimes you don't (install.php, for example, might not be something you want to allow access to after it has served it's purpose). Additionally this statement is based on the popularity of certain naming conventions and trends, it's effectiveness might be minimal or even nonexistent. Blocked urls include example.com/?fpw.php, etc.

RedirectMatch 403 (base64|crossdomain|localhost|wwwroot)

Block access to certain questionable phrases, usually used to probe your system. Blocked urls are of the type example.com/?base64, etc.

RedirectMatch 403 (eval\(|\_vti\_|\(null\))

Similar to the previous, but a little more javascript flavored. Block urls of the type example.com/?eval(, example.com/?vti, example.com/?(null).

RedirectMatch 403 /\..*$

Block attempts at hidden files and version control repositories (and their contents). (Be aware that this blocks access to both the repository and it's contents, there are other expressions circulating that only block access to the repository but not the contents. Be sure you're using something of this form if you're using version control.) Blocked urls would resemble example.com/?.hg/.