Securing FormMail scripts against spambots
Takeaway
This is a technical article about securing a Perl "FormMail" script against spammers who attempt to hijack these scripts for use as spam relays. For those not in the know, FormMail, written in the "Perl" scripting language, is one of the original mailer scripts freely available for general use on websites. It is used by millions of webmasters to send email from a web page form. However, unbeknown to many webmasters, older versions of FormMail are totally insecure and can be exploited as spam relays.
History of FormMail
The original version of FormMail was written in 1995 by Matt Wright and was made available for free on his website: Matt's Script Archive. Unfortunately, the early versions of his FormMail script were very insecure and easily turned into spam relays. This fact was seized upon in 2002 by spammers who used bots to scour websites in search of these exploitable scripts, by name or variations thereof. In response, on April 19, 2002, Matt rewrote his FormMail script to secure it better and released it as version 1.91. This was to become the final version of Matt's FormMail. It remains mostly insecure to this day, yet is in use by website owners around the World who haven't learned about the exploits targeting FormMail.
Several years ago I wrote an in depth web article describing the vulnerabilities in Matt's FormMail, partially titled: FormMail Security Vulnerabilities and Solutions, in which I also recommended a drop in secure replacement script known as NMS FormMail, which was developed by a group of calling themselves the London Perl Mongers. My article is still a valuable resource and will bring most webmasters up to speed on what they need to do to protect their websites from FormMail exploiters. Following my recommendations will certainly help to secure any FormMail scripts you may be using. It will also protect your email account(s) from being harvested by creating alias numbers for them, in NMS FormMail, instead of using plain text addresses to submit to. But, there's more you can do that wasn't covered in my original article.
Securing FormMail - 101
One of my recommendations was renaming your FormMail script to something other than its default spelling: formmail.pl. While this makes it a little harder to locate the script for hostile bots it is useless at protecting it against human spammers. All they need to do is to read the source code of your contact, or feedback pages to get the name of the script that processes your forms and mails comments to you. Then they can go after that script by its new name to try to exploit it for use as a spam relay. If it really is an insecure version of Matt's FormMail it will be used as a spam relay! If you are running your website on an Apache web server, as most of us are, there are special codes, called Mod_Rewrite Directives, that can be applied to a particular server file named .htaccess to completely hide the name of the renamed script, protecting it from being used as a spam relay. If you are allowed to add these directives you can make your FormMail script invisible to spammers.
Read the rest of the details in my extended comments.
About .htaccess
All Apache based web servers use a special access control file named .htaccess. This file's name begins with a period which Apache servers interpret as a server control file. The contents of a .htaccess file have to conform to exact specifications to (1) work as intended, and (2), avoid causing a Server 500 lockout error. Yep, it's that touchy! In my extended comments I will demonstrate how you can apply particular "directives" to your .htaccess file to hide your renamed FormMail scripts from the prying eyes of form spammers and their bots.
Note, that the instructions for hiding the actual script will not prevent spammers from filling out your forms with spam comments and submitting them to you. They will prevent your FormMail script from being used as a spam sending relay without your knowledge. You will need to contact your web hosting company to find out if you have permission to create a custom .htaccess file, or to modify an existing copy using "Mod_Rewrite" directives. Most good web hosts allow custom .htaccess files and Mod_Rewrite directives. If your web host doesn't allow you to use custom .htaccess directives you may want to consider finding another hosting company for your websites, like my current host, Bluehost.
How to hide your FormMail Perl script from spammers
Assuming you have a properly configured and secure version (NMS) of FormMail, that will actually send you an email when a form is properly submitted, here is the process to use to conceal it from spammers wishing to use it as a spam relay. These codes must be used in your public web root .htaccess file, which is only available on an Apache web server hosted website. Windows Server hosted websites cannot use this system unless the web host has, or is willing to install a commercial rewrite conversion script that translates .htaccess directives into a form recognized by Windows IIS servers.
The nitty gritty details of concealing FormMail scripts
First, rename the script to something that doesn't contain either the word "form" or "mail" - like p9pwdfj.pl (or .cgi) (don't use my example names!). Just pick a name or set of characters that has nothing in common with "form," "mail," or any combination or alteration of either word. Spammers have dispatched automated scripts (bots) to search publicly accessible websites for Perl and PHP scripts containing the words form, mail, email, mailer, etc. If they find such a script it will be probed to see if it can be exploited as a spam relay, using your website's SMTP mail server as the spam engine. That will probably get your hosting account suspended if they are successful.
Second, create an alias name for the action when a contact form is submitted. This would be on your HTML or PHP contact, or feedback web pages. Normally, this action line would resemble this stripped down renamed example:
<form action="cgi-bin/changed-script-name.pl" method="POST">
To protect your changed FormMail script name from being scraped from this form, change the action to an alias name, like this example:
<form action="cgi-bin/sub" method="POST">
We can now use a special .htaccess "Mod_Rewrite" directive to translate this aliased action to point to the renamed FormMail script. Learn more about Apache v2.2 .htaccess directives here (read about other releases here).
Download your .htaccess file from your website and open for editing in Notepad, or your preferred plain text ASCII editor. You can download it either via your FTP program, or your web control panel's file manager. You may have to unhide the normally hidden .htaccess file to see it on the remote server side. You can do this in most FTP programs by issuing a "Remote File Mask" command of -al, or by checking a box to show hidden server files using your web site's control panel file manager.
With the .htaccess file downloaded to your hard drive, open it in a plain ascii text editor (e.g: Windows Notepad, TextEdit in Mac OS X, Fookes NoteTab Pro, or CoffeeCup Direct FTP, etc). The entire contents is in plain "ascii" text. If you do not already have a .htaccess file you can create a new one for this purpose. Open a new text file in your plain text editor and save the following directives, carefully observing the spaces where they exist (copy and paste for safety sake, then edit), substituting the action alias and the name you have given to your cloaked FormMail file:
Options +FollowSymLinks
RewriteEngine On
RewriteOptions inherit
RewriteBase /RewriteRule ^cgi-bin/sub$ cgi-bin/changed-script-name.pl [L]
Testing and dealing with Server 500 errors
Save the modified .htaccess as (using Save As) htaccess.txt. Now rename the original file to .htaccess1 and then rename the modified file to .htaccess and upload it to your Apache server website's public_html or web root folder. Immediately, try to open a page on your website in a browser. If you see a "Server 500" error you must upload the original file to the server, rename the bad one to .htaccess2, rename the original/good one, if any existed, to .htaccess, then look for typos in your modified file. Look for text comments you may have typed or copied that are not preceded with a # symbol (a comment directive), or spaces where none should be, or unescaped spaces in directives. Spaces in .htaccess Mod_Rewrite directives must be escaped with a backslash before a space. Other reserved characters, like parenthesis and periods must also be escaped if they are to be interpreted literally, not as code. Read the Apache Documentation for details about allowed directives in .htaccess files.
If you have copied and pasted then edited my example and still get a server 500 error, contact your web host's support department to see if they disallow one of these .htaccess directives.
If your web host requires Perl scripts to end in .cgi, change the renamed extension from .pl to .cgi, then change the directive in .htaccess to match it. If your renamed FormMail starts giving you access denied errors, you may need to assign the proper permissions to it on the server. The required server permissions are "755" - which translates into Owner = Read, Write and Execute, Authenticated Group = Read, Execute, Everyone else = Read and Execute.
Wrap-up
Matt's old FormMail scripts are all vulnerable to hacking exploits. By using NMS Formail, not Matt's FormMail, by renaming the script, then using a .htaccess Mod_Rewrite alias for the action you will prevent automated spam bots from turning your FormMail script into an open spam relay.
If you like this article please share it.
The content on this blog may be reprinted provided you do not modify the content and that you give credit to Wizcrafts and provide a link back to the blog home page, or individual blog articles you wish to reprint. Commercial use, or derivative work requires written permission from the author.