|What about C-T-P-M?
searchers what they want by converting your
knowledge into high-quality, in-demand CONTENT.
|Low Cost Web Hosting
a CompanyWeb recommended web hosting company and
save. Get outstanding hosting
service for $5.00/month or less.
|For Serious Companies
pages of up - to - the - minute research, test
results, examples, case studies, and the newest
and hottest strategies for marketing your
business on the Internet!
|Step by step procedure
than 200 million people a day search on Google
for products and services, and there are less
than 100,000 advertisers. Make money by placing Google
AdWords ads for your affiliate programs.
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.
How Spammers Hijack Your
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
for more information.)
How It's Done
When someone fills out a form on a web page, the information is generally
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" <firstname.lastname@example.org>
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@example.com 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:
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
(The three-part "How To Send Email With Perl" tutorial linked from
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
firstname.lastname@example.org; 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
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
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
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 the Author: