Web Security Techniques Using Apache .htaccess

Advance the spam detection capabilities of your low-cost web application firewall (WAF) by integrating Apache .htaccess with Project Honey Pot. This post describes a combination of techniques using both of these tools to reduce spam traffic hitting your website.

Project Honey Pot is a tool for identifying spammers and spambots targeting your website.  One off-label use for Project Honey Pot is integrating it with .htaccess to create a combined low cost web application firewall and honeypot solution.

Webmasters interested in participating in Project Honey Pot are required to register and then upload a Project Honey Pot provided spam trap webpage to their web server.  After installing the Project Honey Pot software, .htaccess is used to point spammers to your honeypot.  Additionally, many popular content management systems such as WordPress, Joomla, and Drupal have plug-ins that can be configured to use Project Honey Pot's spam blacklist.  Combining your honeypot with the blacklist will further enhance your ability to stop spammers and spambots visiting your website.

For websites that already have a Web Application Firewall through a Content Distribution Network, the .htaccess can be used to supplement or increase the level of security provided by the CND WAF.  The below diagram details the reference architecture.

Creating Your First Spam Trap With .htaccess

To get started, register and install the Project Honey Pot software on your website following their instructions. Once installed you will have a unique webpage file name that serves as your honeypot.

Creating your first spam trap using .htaccess is easy and we will start with the previous .htaccess file we created in the last blog.  Our previous file looks like this:

The code for your first spam trap starts after the last line of the previously created file.  For this blog, we will use the filename "honeypot.php" to refer to the honeypot file installed from Project Honey Pot.

To catch potential spammers, we are going to examine the USER_AGENT variable that HTTP traffic is sending your website. The command RewriteCond will be used in conjunction with RewriteRule to test a condition and execute an action on your web server using the .htaccesss file. 

We will test USER_AGENT using RewriteCond for common strings that spam bots have included in their USER_AGENT variable.  The strings to be tested include “Wget”, “curl”, and “apache”. If our test is positive, the command RewriteRule forwards the tested HTTP traffic to the honeypot for evaluation by Project Honey Pot. 

It is critical to ensure that the HTTP traffic is not the traffic that was already tested and redirected to the honeypot.  To test this, we will use the command RewriteRule on the REQUEST_URI variable. 

The .htaccess code to perform USER_AGENT string evaluations for “Wget”, “curl”, and “apache” and forward positive tests to the honeypot is listed below:

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..

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..

This is the fourth post in a blog series describing how to build a Web Application Firewall (WAF) using the Apache .htaccess file and Project Honey Pot to help reduce spam traffic hitting your website. 

The Blue Plate WAF is for small websites on basic hosting plans that lack access to more sophisticated web security tools.  These basic plans are often used to host content management systems such as WordPress, Joomla, or Drupal which are ideal for small organizational websites.

Web browsers such as Chrome, Firefox, Internet Explorer, and Safari identify themselves by passing along their version information in the HTTP_USER_AGENT variable to the Apache HTTP Server.  By examining the HTTP_USER_AGENT variable, we can determine if a valid web browser version was submitted. 

PCCS Labs has observed that countless spam bots identify themselves as invalid or very out of date browser versions even though it is easy to spoof this information. Validating the browser version passed in HTTP_USER_AGENT filters out a significant amount of spam and bot traffic.

Getting Started with Browser Version Validation Using .htaccess

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

Legacy Browser Versions

The code below uses the RewriteCond command to scan the HTTP_USER_AGENT variable for web browser versions that are very out of date.  These versions are so out of date that an actual person would not be browsing with them.  If a real human were actually using these browser versions, you would not want them visiting your website because these browsers have significant security vulnerabilities.

The code below scans for the following legacy browser versions:

•  Mozilla Code Base Versions 1-4
• Chrome Versions 1-9
• Firefox Versions 1-9
• Internet Explorer Versions 1-6
• Opera (Opera uses the string “OHR”)

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

Invalid Mozilla Code Base User Agents

The below code uses the same framework as above but tests for Mozilla code base strings in the User Agent that do not follow Mozilla’s standard format and therefore invalid.

Invalid Chrome User Agents

The below code uses the same framework as above but tests for Chrome User Agent strings that do not follow Google’s standard format and therefore invalid.

Invalid Firefox User Agents

The below code uses the same framework as above but tests for Firefox User Agent strings that do not follow Mozilla’s standard format and therefore invalid.

Invalid Internet Explorer User Agents

The below code uses the same framework as above but tests for Internet Explorer User Agent strings that do not follow Microsoft’s standard format and therefore invalid.

 The working file is available for download here.  Send your questions, comments, and thoughts on these techniques to This email address is being protected from spambots. You need JavaScript enabled to view it..

This is the fifth post in a blog series describing how to build a Web Application Firewall (WAF) using the Apache .htaccess file and Project Honey Pot to help reduce spam traffic hitting your website. 

The Blue Plate WAF is for small websites on basic hosting plans that lack access to more sophisticated web security tools.  These basic plans are often used to host content management systems such as WordPress, Joomla, or Drupal which are ideal for small organizational websites.

Web browsers such as Chrome, Firefox, Internet Explorer, and Safari identify the operating system that they are running on by passing along their version information in the HTTP_USER_AGENT variable to the Apache HTTP Server.  By examining the HTTP_USER_AGENT variable, we can determine if a valid operating system version was submitted. 

PCCS Labs has observed that spam bots often identify themselves as invalid or very out of date operating system versions even though it is easy to correctly spoof this information. Validating the operating system version passed in HTTP_USER_AGENT helps to filters out spam and spam bot traffic.

Getting Started with Operating System Version Validation Using .htaccess

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

Legacy Operating System Versions

The code below uses the RewriteCond command to scan the HTTP_USER_AGENT variable for operating system versions that are very out of date.  These versions are so out of date that an actual person would not be browsing with them.  If a real human were actually using this operating system version, you would not want them visiting your website because these OS versions have significant security vulnerabilities.

Wikipedia maintains a history of Windows versions which can be used to determine which operating system version to block based on the version age or improper version string. The code below scans for legacy Windows NT release version numbers NT 1.0 through NT 4.0 and sends traffic identifying as those versions to the honeypot:

Invalid Operating System Versions

The code below scans for non-existent Windows release version numbers and sends traffic identifying as those versions to the honeypot:

The code below scans for two digit or more non-existent Windows release version numbers and sends traffic identifying as those versions 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..