Web Security Techniques Using Apache .htaccess

Introduction to SQL Injection, Code Injection, and Apache Input Fields

SQL injection and Code Injection are common hacking techniques used to maliciously harm websites and promote spam.  This post will describe methods for detecting SQL and Code Injection attempts using the Apache .htaccess file and detail how to forward traffic identified as suspicious to your honeypot.

Software bugs, poor programming practices, and outdated software have the potential to expose your website to SQL and Code Injection vulnerabilities. Injection attacks are performed by inserting malicious code into website input fields that are then processed and stored on your server.  Using .htaccess we can review these input fields for signs of malicious code and prevent that code from reaching your web application or database.

There are multiple HTTP server input fields that could be used to deliver a SQL Injection or Code Injection attack.  This post will cover the HTTP QUERY_STRING input field, and subsequent posts will cover additional fields including:

• HTTP_USER_AGENT
• HTTP_REFERER
• HTTP_COOKIE
• HTTP_FORWARDED
• HTTP_PROXY_CONNECTION
• HTTP_ACCEPT
• HTTP:X-FORWARDED-FOR
• HTTP:X-FORWARDED-HOST
• HTTP:X-FORWARDED-SERVER

The above list is not comprehensive of all input fields that could potentially contain injection code.  It is important to keep in mind that there are multiple ways a SQL Injection or Code Injection attack can affect your website.  The configuration of your website will determine the different input fields that could be used to deliver an attack. 

The QUERY_STRING input field passes data to your web server through the Universal Resource Locator (URL).  The data this field contains begins after the ”?” in standard URL format.  For example, if the URL is www.mywesite.com/index.php?foo=foobar, the QUERY_STRING variable would contain “foo=foobar”.

We will use the Apache RewriteCond command to scan the QUERY_STRING variable for character strings that resemble SQL language commands.  A basic understanding of the SQL language is required to understand these commands and an advanced understanding is helpful in identifying advanced SQL Injection attack methods in the QUERY_STRING. 

The SQL language was designed to be easy to understand, and many of the commands resemble common English words.  Common language commands present a challenge in distinguishing between false positives and actual SQL Injection attacks.  Your specific website use cases and configuration will help you to determine if any SQL command character strings require exclusion from the SQL Injection scans because they potentially generate false positives.

.htaccess Code to Block SQL Injection Attacks in QUERY_STRING

We will start with the .htaccess file we created in the previous blog.  The new code we create uses the framework introduced in the previous post to send suspicious traffic to our honeypot webpage using the Project Honey Pot system.  

The code below uses the RewriteCond command to scan the QUERY_STRING variable for common SQL language commands including union select, cast, declare, drop, md5, benchmark, table, column, distinct, substr, concat, schema, hex, truncate, convert, exe, passthru, system, popoen, proc, load, between, null, delay, char, sleep, schema, and unhex.

The [NC] switch is used with RewriteCond to indicate that the string is not case sensitive.  If a positive match is found the command RewriteRule is used to direct suspicious traffic to your honeypot.  The [L] switch is used with RewriteRule to indicate that Apache should stop processing additional rule sets.

Hackers have adapted their methods to disguise or obfuscate SQL Injection and Code Injection commands from web application firewalls using character encoding.  The below code uses the same framework as above but tests for character encoding in the QUERY_STRING input variable and suspicious traffic is sent to the honeypot.

To block Code Injection attempts we will scan the QUERY_STRING variable for common programmatic commands that are not used in standard written English.  Unless your website is focused on programming, it would be highly suspicious to see these strings in normal a webform submission.  The below code uses the same framework as the previous two code snippets but tests for programmatic commands in the QUERY_STRING input variable and suspicious traffic is sent to the honeypot.

The working file is available for download here.  We welcome questions, comments, and thoughts on these techniques, reach out to the PCCS Labs Team at This email address is being protected from spambots. You need JavaScript enabled to view it..