for the Script-Form Attack
Today we live in an electronic era, with the use of the Internet
growing by leaps and bounds. Along with this growth, we have unfortunately
witnessed an increase in the distribution of viruses, denial-of-service
(DoS) attacks, and the break-in and modification of home pages on
Web servers operated by government agencies, commercial organizations,
and academia. The purpose of this article is to acquaint readers
with a relatively new type of network-based attack that can cost
your organization money. I will describe what I call a "script-form"
attack; I will first examine how this attack can occur, and some
The Web has changed the way many businesses operate. The Web is
a valuable place to obtain information and to shop. In addition
to mailing brochures, many organizations highly automate their Web
presence. Thus, brochure requests generate lists of mailing labels
that require little human intervention. When you consider the cost
of postage, it is quite possible that every form filled out by an
Internet surfer winds up costing more than five dollars when the
cost of the brochure, the envelope, and the postage are included
While it is often difficult to explain the logic behind network
attacks, we know they occur and although I'm hard-pressed to
determine why anyone would cause an organization to spend needless
funds shipping brochures around the world, it is a vulnerability
to consider. Because we live in an era of automation, the repeated
completion of a form by a script using a database of names and addresses
represents a "script-form" attack and is the focus of
I examined several Web sites offering books, brochures, and other
literature. The creation of a script to execute a form was easy
to accomplish. According to the FBI, because no break-in to a computer
actually occurs, this attack may not be punishable under existing
computer law. However, various postal regulations and local fraud
statutes may be violated when the value of mailings reaches a level
defined by a statute. In any event, rather than depend up the law
for a remedy after the fact, taking some appropriate steps now can
result in preventing your organization from becoming the victim
of a script-form attack.
How the Attach Operates
I considered several Web sites for my examples. Because the motto
of Lexus is "in the relentless pursuit of perfection",
I thought the Lexus Web site would be a good test location. Thus,
I've used that site to illustrate the fundamentals of the attack
method and see whether the site was programmed to avoid this type
Figure 1 illustrates the top portion of the form generated by
the Lexus Web site when a surfer requests a brochure. The visitor
enters a name, email address, and can then select up to two brochures.
Clicking on the button labeled "Request Brochure" results
in a new screen, which uses some of the previously entered information
to fill entry boxes. The visitor is required to enter a mailing
address, indicate whether they wish to be contacted via email, and
provide information about the vehicle currently owned, and which
vehicle they are considering. The top portion of the second screen
is shown in Figure 2.
In Figures 1 and 2, note that many fields and the selection of
entries from drop-down menus are optional. To complete this form,
I used the name of my dog, "Gizmo", giving him the last
name "Best". Because my dog does not have an email account,
I clicked the box to decline future emails. If you scroll to the
bottom of the screen shown in Figure 2, you will see the "Reset"
and "Submit" buttons. Clicking on the latter results in
the submission of the forms and the arrival of two brochures for
Gizmo to sniff and use for training beyond the subject of this article.
Now that I've described how to complete a form to request
a brochure, I'll discuss how this apparently safe and harmless
promotion of products can result in an opportunity for hackers.
Assume someone decides to create a script and a database of ten
names, addresses, and fake email addresses. Because most Web forms
represent a front-end to a back-end database, most Web sites simply
either compare the name and address entered on the form to the entries
on the database, or perform a matching operation based on an email
address. Thus, it is not too difficult to fool the Web site database
and request multiple brochures.
Returning to the hacker's database, suppose the script cycles
through it, selecting one name and then using each of the addresses
and email addresses to generate ten brochure requests. Next, the
second name in the database is selected, and each of the ten addresses
is used to create ten additional brochure requests. By the time
the last name cycles through the address-matching algorithm, the
ten names and addresses can be used to generate 100 requests. If
instead of 10 names 100 or 1000 were used, the number of unique
requests can considerably increase.
What happens if the database also checks email addresses? Wouldn't
this put a stop to all requests after the first ten? Yes, but note
that it is very easy to perform string manipulation. Thus, the first
time through the cycle each email address could include a numeric
prior to the "at" (@) sign that separates a user's
email name from the domain name. A simple algorithm then could be
used to update each email address so that it would appear to be
unique (e.g., firstname.lastname@example.org, email@example.com, and so on).
Another area that deserves a bit of elaboration is address checking.
Some organizations implement address checking to ensure that multiple
brochures are not sent to the same address. Thus, changing "Gizmo"
to "Bismo" would preclude a new set of brochures being
mailed to a common address. Unfortunately, there is a very easy
method that can be used to bypass pure address checking. Since addresses
are commonly compared as strings, the suffix of an apartment number
can be used to throw off the entire address checking mechanism.
To verify this fact, I modified the apartment number associated
with my dog's address and approximately one week later received
a sufficient number of brochures to paper train a family of pets.
Thus, the relentless pursuit of perfection does not appear to have
Because the hacker may not care if all the brochures are actually
delivered, another addressing technique is incremental addressing.
Under incremental addressing, the attacker foils address checking
by incrementing house numbers, such as 4736, 4737, 4738, and so
There are many form-processing loopholes that make a script-form
attack a viable tool for a hacker, but let's look at prevention
measures. In doing so, we can start off with some common sense.
A script-form attack can be highly successful and cause financial
distress when a company loses sight of how its operations perform.
For example, if your organization receives an average of 50 brochure
requests per day and suddenly that number jumps to 1000 or more,
something may be amiss. Thus, daily reports concerning brochure
requests or an exception report indicating when requests exceed
a certain predefined threshold can serve as a good warning mechanism.
A second important area is the mechanism used to ensure your organization
has a brochure request database and to correctly check that database
prior to electronically fulfilling the request. For example, some
organizations that I researched either do not maintain a brochure
request database or, if they do, their software does not access
the database. At one site, I submitted a dozen requests for a brochure
using the same name and address and approximately a week later watched
the mailman try to squeeze 12 packages into my mailbox.
Although there are numerous variations that can be used in a script-form
attack that can drive a programmer mad, there are certain checks
that can negate the potential effect of this type of attack. One
method to consider is an IP address check between successive requests
occurring in a short period of time. For example, assume the IP
address 188.8.131.52 is used for issuing a series of brochure requests.
While possible, it's unlikely that the use of the Dynamic Host
Control Protocol (DHCP) by an organization that is assigned the
Class C network address of 184.108.40.206 dynamically assigned that
address to two Web surfers that just happened to request a brochure
from your organization. Instead, successive brochure requests using
the same IP address but different names or mailing addresses can
be suspected of a script-form attack.
While IP address checking between successive brochure requests
is a valuable weapon, it is not foolproof. A person could take advantage
of DHCP and disconnect from the Internet after each brochure request,
then re-dialing and reconnecting to the Internet would result in
a new IP address. Someone capable of programming a script-form attack
probably has sufficient knowledge to place the script within a program
that initiates an Internet connection, issues the brochure request,
disconnects, and then repeats the sequence again and again. Thus,
a bit more effort may be required to minimize the vulnerability
of your organization to a script-form attack.
Because every form to request a brochure requires a name and address,
those variables represent the best form entries to check. Assuming
your organization maintains a brochure request database, coding
should be developed to check the street address using string manipulation.
For example, assume the hacker entered address if 4736 Oxford Road
Apt 21. Through string manipulation, you should temporarily strip
any address entry after Road, Circle, Drive, or any normal single
family address. Then, your software should perform a search of the
database against the entries "4736 Oxford Road" and "Oxford
Road". That search should be case-insensitive to prevent any
moving sequence of capital letters adversely effecting the matching
If a match occurs against the current brochure database for 4736
Oxford Road, it is possible the address is an apartment or an office
building. Thus, a good program would incorporate a checking algorithm
that continues the scan of the database when a match occurs. Because
it is possible that several people in a large apartment complex
or office building could request brochures, you probably want to
allow some repeated requests from the same basic address. However,
if those requests become excessive, it might be a good idea to either
generate an exception report or place a limit on the number of brochure
requests that will be sent to a basic address. Similarly, suppose
you obtain a match for "Oxford Road" in the same zip code.
While it's possible two or more people on Oxford Road with
the same zip code request a brochure on the same day, what is the
probability of ten requests, or a hundred, or more? Thus, another
cutoff when a street name match occurs within the same zip code
is recommended. However, instead of simply not letting the requested
proceed, a message asking them to call in their request might be
The script-form attack does not appear to violate current Federal
security laws because there is no actual break-in into a computer
system. However, a sufficient number of brochure requests could
violate both local and postal statutes as it represents a fraud
upon the Web site operator. Rather than waiting for legal representation
to determine your organization's rights in the wake of an attack,
it is best to consider preventative measures to minimize the potential
for such an attack. Thus, as the old adage states, "proper
planning prevents poor performance", and in the case of marketing
on the Web, it can also save your bottom line.
Gilbert Held is an internationally known award-winning author
and lecturer. Gil is the author of over 40 books and 250 technical
articles. Some of Gil's recent publications include Cisco
Security and Cisco Access List Field Guide, both co-authored
with Kent Hundley and published by McGraw Hill. Gil's new book,
Bulletproofing TCP/IP Networks, will be published by John
Wiley & Sons during the first quarter of 2001. Gil can be reached
via email at: firstname.lastname@example.org.