Htaccess Rules to Help Protect from SQL Injections and XSS

This list of rules by no means is a sure bet to secure your web services, but it will help in preventing script-kiddings from doing some basic browsing around.

MySQL injection attempts are one of the most common hacking attacks against PHP websites. If your website is hosted on a dedicated or virtual server, the best solution is to your server hardened with proper mod_security rules. However, if you’re on shared hosting, this is not an option. If you now think that it’s not possible to protect your website against various hacking methods on shared hosting, you’re wrong. Although it’s not possible to use advanced strategies to protect your website, you’re still able to protect it against hacking attempts using .htaccess rules. To implement such a protection, append your current .htaccess file with the following code, or create a new file called .htaccess, if you don’t use any yet, and place it in your website’s main folder):

Beginning of your .htaccess file to set the basics up

# Block access to the .htaccess file
<files .htaccess>
order allow,deny
deny from all
</files>

# No web server version and indexes
ServerSignature Off
Options -Indexes
Options FollowSymLinks

HTTP Headers to Help Secure Your Website

Preventing cross-site request forgery (CSRF) attacks is hard and web applications must be built to prevent CSRF vulnerabilities. The first vulnerability is cross-site scripting (XSS).

Around 70.000 web sites have been catalogued by XSSed as being vulnerable to cross-site scripting (XSS). These attacks leave your users open to cookie theft, information theft, account hijacking, clickjacking and more.

Modern web browsers have some powerful protection build in nowadays but you need to tell the browser that you want those protection mechanisms used for your website. This can be archived by setting specific HTTP headers.

X-Frame-Options

The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame> or <iframe>. This can be used to avoid clickjacking attacks, by ensuring that your content is not embedded into other sites.

This directive is pretty similar to the frame buster code explained in “Double Trouble on Google Images” except that it is only supported in the following browsers:

• Internet Explorer 8+
• Opera 10.50+
• Safari 4+
• Chrome 4.1.249.1042+
• Firefox 3.6.9+ (or earlier with NoScript)

There are three possible values for this header:

1. DENY – This setting prevents any pages served from being placed in a frame even if it is on the same website it originates from. should be used if you never intend for your pages to be used inside of a frame.
2. SAMEORIGIN – This setting allows pages to be served in a frame of a page on the same website. If an external site attempts to load the page in a frame the request will be denied.
3. ALLOW-FROM origin – If the value contains the token ALLOW-FROM origin, the browser will block rendering only if the origin of the top-level browsing context is different than the origin value supplied with the Allow-From directive.

The code below sets the directive to DENY, preventing our pages from being served in any frames, even from our own website.

# drop Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
# optional logging.
#CustomLog insert-path-and-name-of-log common env=bad-range

# Don't allow any pages to be framed - Defends against CSRF
Header set X-Frame-Options DENY

# prevent mime based attacks
Header set X-Content-Type-Options "nosniff"

# Only allow JavaScript from the same domain to be run.
# Don't allow inline JavaScript to run.
Header set X-Content-Security-Policy "allow 'self';"

# Turn on IE8-IE9 XSS prevention tools
Header set X-XSS-Protection "1; mode=block"

MySQL Injection Prevention:

MySQL injection attempts are one of the most common hacking attacks against PHP websites. If your website is hosted on a dedicated or virtual server, the best solution is to your server hardened with proper mod_security rules. However, if you’re on shared hosting, this is not an option. If you now think that it’s not possible to protect your website against various hacking methods on shared hosting, you’re wrong. Although it’s not possible to use advanced strategies to protect your website, you’re still able to protect it against hacking attempts using .htaccess rules. To implement such a protection, append your current .htaccess file with the following code, or create a new file called .htaccess, if you don’t use any yet, and place it in your website’s main folder):

<IfModule mod_rewrite.c>
# Enable rewrite engine
RewriteEngine On

# Block suspicious request methods
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK|DEBUG) [NC]
RewriteRule ^(.*)$ - [F,L]

# Block WP timthumb hack
RewriteCond %{REQUEST_URI} (timthumb.php|phpthumb.php|thumb.php|thumbs.php) [NC]
RewriteRule . - [S=1]

# Block suspicious user agents and requests
RewriteCond %{HTTP_USER_AGENT} (libwww-perl|wget|python|nikto|curl|scan|java|winhttp|clshttp|loader) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (<|>|'|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (;|<|>|'|"|)|(|%0A|%0D|%22|%27|%28|%3C|%3E|%00).*(libwww-perl|wget|python|nikto|curl|scan|java|winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner) [NC,OR]
RewriteCond %{THE_REQUEST} ? HTTP/ [NC,OR]
RewriteCond %{THE_REQUEST} /* HTTP/ [NC,OR]
RewriteCond %{THE_REQUEST} etc/passwd [NC,OR]
RewriteCond %{THE_REQUEST} cgi-bin [NC,OR]
RewriteCond %{THE_REQUEST} (%0A|%0D) [NC,OR]

# Block MySQL injections, RFI, base64, etc.
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=http:// [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=http%3A%2F%2F [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=(..//?)+ [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=/([a-z0-9_.]//?)+ [NC,OR]
RewriteCond %{QUERY_STRING} =PHP[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12} [NC,OR]
RewriteCond %{QUERY_STRING} (../|..) [OR]
RewriteCond %{QUERY_STRING} ftp: [NC,OR]
RewriteCond %{QUERY_STRING} http: [NC,OR]
RewriteCond %{QUERY_STRING} https: [NC,OR]
RewriteCond %{QUERY_STRING} =|w| [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)/self/(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)cPath=http://(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} (<|%3C).*script.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (<|%3C).*iframe.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (<|%3C)([^i]*i)+frame.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} base64_encode.*(.*) [NC,OR]
RewriteCond %{QUERY_STRING} base64_(en|de)code[^(]*([^)]*) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|[|%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|[|%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} ^.*([|]|(|)|<|>).* [NC,OR]
RewriteCond %{QUERY_STRING} (NULL|OUTFILE|LOAD_FILE) [OR]
RewriteCond %{QUERY_STRING} (./|../|.../)+(motd|etc|bin) [NC,OR]
RewriteCond %{QUERY_STRING} (localhost|loopback|127.0.0.1) [NC,OR]
RewriteCond %{QUERY_STRING} (<|>|'|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{QUERY_STRING} concat[^(]*( [NC,OR]
RewriteCond %{QUERY_STRING} union([^s]*s)+elect [NC,OR]
RewriteCond %{QUERY_STRING} union([^a]*a)+ll([^s]*s)+elect [NC,OR]
RewriteCond %{QUERY_STRING} (;|<|>|'|"|)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode) [NC,OR]

# PHP-CGI Vulnerability
RewriteCond %{QUERY_STRING} ^(%2d|-)[^=]+$ [NC,OR]

#proc/self/environ? no way!
RewriteCond %{QUERY_STRING} proc/self/environ [NC,OR]

RewriteCond %{QUERY_STRING} (sp_executesql) [NC]
RewriteRule ^(.*)$ - [F,L]

</IfModule>

Janeth Kent

Licenciada en Bellas Artes y programadora por pasión. Cuando tengo un rato retoco fotos, edito vídeos y diseño cosas. El resto del tiempo escribo en MA-NO WEB DESIGN AND DEVELOPMENT.