Support - Protecting Your Web Forms From Spammers
Last month we discussed "form compromise to send SPAM." In other words, how Web forms that send email from your web site are being increasingly attacked in an effort to use these forms to send email spam to addresses other than the ones you've intended. In this way a spammer can use a high powered server to send out spam and be undetected.
The method is simple. Every email has header info. In the header is the To:, Cc:, Bcc:, From:, and Subject: and the body of an email is just that - Body:, but it's outside of the header info. If a spammer is able to "insert" their own header info into any of your header fields above they can force the mail sending service on a web server (aka mail transfer agent - MTA) to send the email with any content they wish - to anyone.
Here's an example. Let's say that you have a "contact us" form on your web site. This form asks for a From address, allows you to type in your own Subject line and then has a textbox for the message body. The spammer only needs to create his spam email with his malicious headers which include 500 Bcc'd recipients and his message body. This data is now inserted into the form and submitted to the code that you've written to handle the form. Now when the email is sent to the MTA, the server parses down through the email text starting at the headers and prepares to send out the mail. The server reads the normal beginning of the header and continues to read the "inserted" headers as well. At this point the server thinks it's doing the right thing and continues to send the mail to everyone in the headers, and includes the spammer's body text which he also inserted into the From: field.
This is just one example. Any header field can be used to send spam using this method. Additionally, the form itself may not be the page being attacked, but rather the spammer is posting his data directly to the form handler.
How do you fix this? The only way to fix this is to write secure code. Code that accepts user input of any kind has to validate all and any user input. The code that accepts the input for any header fields must validate this input. Common things to check for are:
- User input data cannot contain the string "http," this usually indicates the spammer's use of URLs in the message body.
- The presence of more than one @ character in any input if you expect your email to be to or from only one person.
- The presence of the text string "bcc" or "cc"(in upper and lower case) unless your form is accepting these. This may indicate the spammer is sending to multiple recipients.
These are just some examples of the input validation that is needed to prevent this from happening. If any of these conditions are met, the code should either inform the customer to correct their input or should take no action. Any scripting language is vulnerable to this type of attack. Therefore, there is no way to give specific examples of a fix that will work for everyone.
Do you need help with your code? Or are you concerned this could be happening to you? If you are an Adhost customer, we are available for consultation and programming resources.
Next month we'll talk about specific fixes for SQL Injection.










