Web Design Master Series Article

Web Design Master Series Article is syndicated from Web-Source.net.

Syndicated articles are written by independent authors and the contents represent the author's views. The content of the article does not necessarily represent the views of Company Web staff and management.

---

Master Series How Spammers Hijack Your Forms By William Bontrager This week we'll talk about how any of your forms may be vulnerable to hijacking, not just the scripts mentioned last week. Form processing programs that allow the insertion of a linefeed character into any of the outgoing email header lines can be hijacked. Any form you might have that is processed by a program with that vulnerability could let spammers send their spew from *your* server and, possibly, get you in trouble with your hosting company. I'll explain about the "linefeed character" in a bit. First, this exploit was used with FormMail. Many hosting companies now prohibit or strongly discourage using FormMail, or at least certain versions. Thus, spammers found it harder and harder to find open FormMail installations. According to what I've read, what spammers are doing now is trying any form they find. If they find it exploitable, they add the form processing program to a list. They have programs to automatically cycle through the list to send their spew, a few at each one on the list so as not to cause alarm. The scenario is supported by our own observations. One of our forms seems to be on that list because it experiences three to five hijacking attempts every day. This follows an eleven-hour hijacking by what appeared to be an automated spamming program. (See "The Hijacking of Master Form" at http://willmaster.com/a/22t/pl.pl?art221a for more information.) How It's Done When someone fills out a form on a web page, the information is generally emailed somewhere. If any of the form field's information is used in the email header of the outgoing email, that form field might be a security hole. First, let's see what an email header looks like: --------------------------------------- From: "username" <[email protected]> To: [email protected] Subject: I want more Blah, blah, blah Blah, blah, blah --------------------------------------- Note that the first blank line separates the email header from the email body. It's always that way. Once a blank line is encountered, the software assumes everything else belongs to the email body. Now, suppose a form field asked for the user's name and email address. It might also ask for a subject. Any one of those can be used to see if a security hole exists in your form processing program. As an example, let's try the user's name. Notice that the user's name is in the From: header line of the email being sent out. This allows the webmaster at [email protected] to simply click reply when answering the form user. A hijacker might build a program to submit to your form processing program. Instead of a user's name in the username form field, the hijacker might put a line feed character (which is simply a character that software sees as a signal to start a new line), then "Bcc:" followed by hundreds of @aol.com (or other) email addresses. Now, the above email would become: --------------------------------------- From: " To: (any address on your domain) Bcc: (hundreds of @aol.com addresses go here) Subject: Spammer's subject goes here The spammers email body goes here. --------------------------------------- See what happened? The entire email was hijacked. One would think that the rest of the email header lines would then show up at the bottom of the email being sent out. It would, except the hijackers' work I've seen usually includes a "multi-part" header line. With that, the email reader of the person receiving the email discards anything that's not within the boundaries of the codes indicating the beginning and ending of the email body "parts." (An email body part could be an image, plain text, HTML text, etc.) So the rest of the email header lines don't show up because they're not between part boundaries. (The three-part "How To Send Email With Perl" tutorial linked from http://willmaster.com/a/22t/pl.pl?archives contains information about multi-part emails that may be useful for increasing understanding of how this works.) Determining if Your Program is Being Hijacked Hijackers tend to put hundreds, maybe a thousand or more, email address into the Bcc: header line. There will probably be bounces from at least a few of those addresses. When an email bounces, the returned email usually has the full headers of the email being returned. There is only one thing I'm aware of that will let you know with certainty whether or not your form processing program had been hijacked. And that is to search the Received: header lines to determine the source of the email. The Received: header line looks something like this: Received: from example1.com by example2.com for [email protected]; Mon, 13 Oct 2003 15:20:12 -0600 (MDT) (Whenever a Received: header spans more than one line, there will be at least one space at the beginning of the second and subsequent lines.) The above example Received: header line is sparse. In a real one, there will be IP addresses and other information. But the above is the basic idea. It says which domain received it, which domain sent it, and who the email is for. The email address of the domain that sent the email can be spoofed, but the IP address of the sending domain rarely is. So believe the IP address more than the domain name. If the email you're studying has only one Received: line and the sending domain's IP address is yours, it was sent from your server. If you didn't send it, then one of your form processing programs was hijacked. If the email you're studying has more than one Received: line, you'll need to determine which Received: line came first. The date/time in the received line comes in handy when doing this. However, Received: lines can be spoofed, too, so determining the first Received: line might be somewhat hard to do. If you'll stick with IP addresses rather than domain names, then you'll probably get it right. Note that your email address in the From: line of returned email does not mean your form processing program was hijacked. Spammers tend to use other people's email addresses in their From: header lines, which causes some ISPs to return the email to that address. Use the above method to determine whether or not it really was a hijacking. Testing Your Form Processing Program For Vulnerability Unfortunately, the vulnerability can't always be determined by submitting the pretend hijacking lines with a browser. The browser may encode certain characters, such as newline characters, before sending the form submission to the processing program. Therefore, I've made a special script that you can use to test your own forms. (Probably hijackers use something similar.) If you want to use it, you'll need to go to http://willmaster.com/a/22t/pl.pl?sht and provide your email address and the URLs of the form processing programs you want to test. When you submit the form, you'll receive an email with further instructions and information. The database of those allowed to use the special script will be manually updated. And the test itself will be hard coded in the special script. The test can not be guaranteed to uncover any vulnerability that may exist. But if it does uncover one, you'll at least be in position to do something about it. Will Bontrager About the Author: Copyright 2003 Bontrager Connection, LLC William Bontrager Programmer/Publisher, "WillMaster Possibilities" ezine mailto:[email protected] Are you looking for top quality scripts? Visit Willmaster and check out his highly acclaimed Master Series scripts. Some free, some for a fee. Content Provided By:

More Master Series Articles...

• Cascading Style Sheets
• Changing Dropdown Content On The Fly
• Counting And Math With Javascript
• Disabling Enabling Form Fields Dynamically
• Dropdown Navigation Menu Generator
• Dynamic Subordinate Listbox
• Easy Iframe Slide Show
• Encoding Text For Web Pages
• Form Input Validation And Correction
• Form Submissions Without Submit Buttons
• How Spammers Hijack Your Forms
• I Made A Form What Do I Do Now
• It Kicks In When Visitors Leave Your Site
• Latin 1 Entities
• Many Actions With One Form Submission
• Master Page Landing Notice
• Master Password Generator V1
• Master Series Template
• Moving Cgi Scripts To A New Server
• Pre Fill Forms From Last Use
• Secure Servers
• Simple Clickbank Authentication
• Snooping Around
• Spring Cleaning Your Web Site
• The $49 Web Site Replicator
• When A Browser Refuses To Provide Referrer Information

Frontpage, NT are Trademarks of Microsoft Corporation. CompanyWeb Site Copyright (c) 1998 - 2003, CompanyWeb.net Site Development Service Group.