Workable attacks against E-commerce

Author: Abdollah Shirvani

Shirvani.86@Gmail.com

1st e-commerce security Conference-Ramiran.Co, Tehran, Iran, summer 2008

What is e-Commerce?
E-Commerce refers to the exchange of goods and services over the Internet. All major retail
brands have an online presence, and many brands have no associated bricks and mortar presence.
However, e-Commerce also applies to business to business transactions, for example, between
manufacturers and suppliers or distributors.

In the online retail space, there are a number of models that retailers can adopt. Traditionally, the
Web presence has been kept distinct from the bricks and mortar presence, so transactions were
limited to buying online and delivering the goods or services. The online presence is also
important for researching a product that a customer can purchase later in the store. Recently,
there has been a trend towards multi-channel retail, allowing new models such as purchasing
online and picking up in store.

E-Commerce systems are also relevant for the services industry. For example, online banking
and brokerage services allow customers to retrieve bank statements online, transfer funds, pay
credit card bills, apply for and receive approval for a new mortgage, buy and sell securities, and
get financial guidance and information.

Security overview
A secure system accomplishes its task with no unintended side effects. Using the analogy of a
house to represent the system, you decide to carve out a piece of your front door to give your
pets' easy access to the outdoors. However, the hole is too large, giving access to burglars. You
have created an unintended implication and therefore, an insecure system.
In the software industry, security has two different perspectives. In the software development
community, it describes the security features of a system. Common security features are ensuring
passwords that are at least six characters long and encryption of sensitive data. For software
consumers, it is protection against attacks rather than specific features of the system. Your house
may have the latest alarm system and windows with bars, but if you leave your doors unlocked,
despite the number of security features your system has, it is still insecure. Hence, security is not
a number of features, but a system process. The weakest link in the chain determines the security
of the system. In this article, we focus on possible attack scenarios in an e-Commerce system and
provide preventive strategies, including security features that you can implement.

Security has three main concepts: confidentiality, integrity, and availability. Confidentiality
allows only authorized parties to read protected information. For example, if the postman reads
your mail, this is a breach of your privacy. Integrity ensures data remains as is from the sender to
the receiver. If someone added an extra bill to the envelope, which contained your credit card
bill, he has violated the integrity of the mail. Availability ensures you have access and are
authorized to resources. If the post office destroys your mail or the postman takes one year to
deliver your mail, he has impacted the availability of your mail.

The players
In a typical e-Commerce experience, a shopper proceeds to a Web site to browse a catalog and
make a purchase. This simple activity illustrates the four major players in e-Commerce security.
One player is the shopper who uses his browser to locate the site. The site is usually operated by
a merchant, also a player, whose business is to sell merchandise to make a profit. As the
merchant business is selling goods and services, not building software, he usually purchases
most of the software to run his site from third-party software vendors. The software vendor is the
last of the three legitimate players. The attacker is the player whose goal is to exploit the other
three players for illegitimate gains. Figure 2 illustrates the players in a shopping experience.

Figure 2. The players

The attacker can besiege the players and their resources with various damaging or benign
schemes that result in system exploitation. Threats and vulnerabilities are classified under
confidentiality, integrity, and availability. A threat is a possible attack against a system. It does
not necessarily mean that the system is vulnerable to the attack. An attacker can threaten to
throw eggs against your brick house, but it is harmless. Vulnerability is a weakness in the
system, but it is not necessarily known by the attacker. For example, only you know that you
have left your front door unlocked. Vulnerabilities exist at entry and exit points in the system. In
a house, the vulnerable points are the doors and windows. When the burglar threatens to break
into your house and finds the vulnerability of the unlocked door, he is exploiting the assets in the
house.

Security features
While security features do not guarantee a secure system, they are necessary to build a secure
system. Security features have four categories:
 Authentication: Verifies who you say you are. It enforces that you are the only one
allowed to logon to your Internet banking account.
 Authorization: Allows only you to manipulate your resources in specific ways. This
prevents you from increasing the balance of your account or deleting a bill.
 Encryption: Deals with information hiding. It ensures you cannot spy on others during
Internet banking transactions.
 Auditing: Keeps a record of operations. Merchants use auditing to prove that you bought
specific merchandise.

The criminal incentive

Attacks against e-Commerce Web sites are so alarming; they follow right after violent crimes in
the news. Practically every month, there is an announcement of an attack on a major Web site
where sensitive information is obtained. Why is e-Commerce vulnerable? Is e-Commerce
software more insecure compared to other software? Did the number of criminals in the world
increase? The developers producing e-Commerce software are pulled from the same pool of
developers as those who work on other software. In fact, this relatively new field is an attraction
for top talent. Therefore, the quality of software being produced is relatively the same compared
to other products. The criminal population did not undergo a sudden explosion, but the incentives
of an e-Commerce exploit are a bargain compared to other illegal opportunities.
Compared to robbing a bank, the tools necessary to perform an attack on the Internet is fairly
cheap. The criminal only needs access to a computer and an Internet connection. On the other
hand, a bank robbery may require firearms, a getaway car, and tools to crack a safe, but these
may still not be enough. Hence, the low cost of entry to an e-Commerce site attracts the broader
criminal population.
The payoff of a successful attack is unimaginable. If you were to take a penny from every
account at any one of the major banks, it easily amounts to several million dollars. The local
bank robber optimistically expects a windfall in the tens of thousands of dollars. Bank branches
do not keep a lot of cash on hand. The majority is represented in bits and bytes sitting on a hard
disk or zipping through a network.
While the local bank robber is restricted to the several branches in his region, his online
counterpart can choose from the thousands of banks with an online operation. The online bank
robber can rob a bank in another country, taking advantage of non-existent extradition rules
between the country where the attack originated, and the country where the attack is destined.
An attack on a bank branch requires careful planning and precautions to ensure that the criminal
does not leave a trail. He ensures the getaway car is not easily identifiable after the robbery. He
cannot leave fingerprints or have his face captured on the surveillance cameras. If he performs
his actions on the Internet, he can easily make himself anonymous and the source of the attack
untraceable.
The local bank robber obtains detailed building maps and city maps of his target. His online
counterpart easily and freely finds information on hacking and cracking. He uses different sets of
tools and techniques everyday to target an online bank.
Points the attacker can target
As mentioned, the vulnerability of a system exists at the entry and exit points within the system.
Figure 3 shows an e-Commerce system with several points that the attacker can target:
 Shopper
 Shopper' computer
 Network connection between shopper and Web site's server
 Web site's server
 Software vendor

Figure 3. Points the attacker can target

Common Security Vulnerabilities in

E-commerce Systems
The tremendous increase in online transactions has been accompanied by an equal rise in the
number and type of attacks against the security of online payment systems. Some of these attacks
have utilized vulnerabilities that have been published in reusable third-party components utilized
by websites, such as shopping cart software. Other attacks have used vulnerabilities that are
common in any web application, such as SQL injection or cross-site scripting. This article
discusses these vulnerabilities with examples, either from the set of known vulnerabilities, or
those discovered during the author's penetration testing assignments. The different types of
vulnerabilities discussed here are SQL injection, cross-site scripting, information disclosure, path
disclosure, price manipulation, and buffer overflows.

Successful exploitation of these vulnerabilities can lead to a wide range of results. Information
and path disclosure vulnerabilities will typically act as initial stages leading to further
exploitation. SQL injection or price manipulation attacks could cripple the website, compromise
confidentiality, and in worst cases cause the e-commerce business to shut down completely.
Wherever examples of such vulnerabilities are given in advisories published by Bugtraq, we
have given the Bugtraq ID in square brackets. Details of the vulnerability may be viewed by
navigating to http://www.securityfocus.com/bid/<bid_number>.

2. Vulnerabilities
2.1 Background

There are a number of reasons why security vulnerabilities arise in shopping cart and online
payment systems. The reasons are not exclusive to these systems, but their impact becomes much
greater simply because of the wide exposure that an online website has, and because of the
financial nature of the transactions.

One of the main reasons for such vulnerabilities is the fact that web application developers are
often not very well versed with secure programming techniques. As a result, security of the
application is not necessarily one of the design goals. This is exacerbated by the rush to meet
deadlines in the fast-moving e-commerce world. Even one day's delay in publishing a brand new
feature on your website could allow a competitor to steal a march over you. We've typically
found this in cases where e-commerce sites need to add functionality rapidly to deal with a
sudden change in the business environment or simply to stay ahead of the competition. In such a
scenario, the attitude is to get the functionality online; security can always be taken care of later.
Another reason why security vulnerabilities appear is because of the inherent complexity in most
online systems. Nowadays, users are placing very demanding requirements on their e-commerce
providers, and this requires complex designs and programming logic.

In a number of cases, we've found that e-commerce sites tout their 128-bit SSL certificates as
proof that their sites are well secured. The gullibility of customers to believe in this has reduced
over the past few years, but even now there are thousands of web sites displaying Verisign or
Thawte certificate icons as proof of their security.

The following sections look at common security vulnerabilities that have been discovered in
shopping cart and online payment systems.

2.2 SQL Injection

SQL injection refers to the insertion of SQL meta-characters in user input, such that the
attacker's queries are executed by the back-end database. Typically, attackers will first determine
if a site is vulnerable to such an attack by sending in the single-quote (') character. The results
from an SQL injection attack on a vulnerable site may range from a detailed error message,
which discloses the back-end technology being used, or allowing the attacker to access restricted
areas of the site because he manipulated the query to an always-true Boolean value, or it may
even allow the execution of operating system commands.

SQL injection techniques differ depending on the type of database being used. For instance, SQL
injection on an Oracle database is done primarily using the UNION keyword and is much more
difficult than on the MS SQL Server, where multiple queries can be executed by separating them
with the semi-colon. In its default configuration, MS SQL server runs with Local System
privileges and has the 'xp_cmdshell' extended procedure, which allows execution of operating
system commands.

The most publicized occurrences of this vulnerability were on the e-commerce sites of
Guess.com and PetCo.com. A 20-year old programmer in Orange County, California, Jeremiah
Jacks discovered that it was possible to ferret out highly sensitive data such as credit card
numbers, transaction details, etc. from these and a number of other sites using specially crafted
URLs containing SQL meta-characters.

SQL injection vulnerabilities have also been discovered in shopping cart software such as the
VP-ASP Shopping Cart, I Generic Free Shopping Cart, Web Merchant Services Storefront
Shopping Cart, etc. Of these, the vulnerability in the Storefront Shopping Cart occurred in its
login.asp page, and could potentially allow the attacker to execute malicious database queries,
without needing to authenticate to the web site.

2.3 Price Manipulation

This is a vulnerability that is almost completely unique to online shopping carts and payment
gateways. In the most common occurrence of this vulnerability, the total payable price of the
purchased goods is stored in a hidden HTML field of a dynamically generated web page. An
attacker can use a web application proxy such as Achilles to simply modify the amount that is
payable, when this information flows from the user's browser to the web server. Shown below is
a snapshot of just such a vulnerability that was discovered in one of the author's penetration
testing assignments.

Figure 1: Achilles web proxy

The final payable price (currency=Seamount=879.00) can be manipulated by the attacker to a

value of his choice. This information is eventually sent to the payment gateway with whom the
online merchant has partnered. If the volume of transactions is very high, the price manipulation
may go completely unnoticed, or may be discovered too late. Repeated attacks of this nature
could potentially cripple the viability of the online merchant.

Similar vulnerabilities have also been found in third-party software such as in the 3D3
ShopFactory Shopping Cart, where price and item-related information was stored in client-side
cookies, which could easily be manipulated by an attacker. Similarly, Smart win Technology's
CyberOffice Shopping Cart 2.0 could be attacked by downloading the order form locally, and
resubmitting it to the target server with the hidden form fields modified to arbitrary values.

2.4 Buffer overflows

Buffer overflow vulnerabilities are not very common in shopping cart or other web applications
using Perl, PHP, ASP, etc. However, sending in a large number of bytes to web applications that
are not geared to deal with them can have unexpected consequences. In one of the author's
penetration testing assignments, it was possible to disclose the path of the PHP functions being
used by sending in a very large value in the input fields. As the sanitized snapshot below shows,
when 6000 or more bytes were fed into a particular field, the back-end PHP script was unable to
process them and the error that was displayed revealed the location of these PHP functions.

Figure 2: PHP timeout error

Using this error information it was possible to access the restricted 'admin' folder. From the
structure of the web site and the visible hyperlinks there would have been no way to determine
that there existed the 'admin' directory within the 'func' sub-directory below the main $Document
Root.

Multiple buffer overflows were also discovered in the PDGSoft Shopping Cart, which potentially
allowed the attacker to execute code of his choice by over-writing the saved return address.

Error pages can serve as a valuable source for critical information. These errors can be induced
in web applications that do not follow strict input validation principles. For instance, the
application may expect numeric values and would fail when alphabets or punctuation characters
are supplied to it. This is exactly what has happened in the case below. Here, the e-commerce
website used numbers for its various pages. Users would navigate using a link such as
http://www.vulnerablesite.com/jsp/Navigate.jsp?pageid=123. By manipulating the URL and
supplying the value 'AA' for the paged, the following error was induced:

Figure 3: Discovering information through navigation errors

If you observe carefully, the highlighted information reveals the Oracle Application Server
version as Oracle 9iAS 9.0.3.0.0 as well as certain third-party components being used by the web
application, such as Orion Application Server. It also reveals the path where other (possibly
vulnerable) .jsp scripts exist - /scripts/menu.jsp.

2.5 Cross-site scripting

The Cross-site Scripting (XSS) attack is primarily targeted against the end user and leverages
two factors:

1. The lack of input and output validation being done by the web application
2. The trust placed by the end-user in a URL that carries the vulnerable web site's name.

The XSS attack requires a web form that takes in user input, processes it, and prints out the
results on a web page, which also contains the user's original input. It is most commonly found in
'search' features, where the search logic will print out the results along with a line such as
'Results for <user_supplied_input>'. In this case, if the user input is printed out without being
parsed, then an attacker can embed JavaScript by supplying it as part of the input. By crafting a
URL, which contains this JavaScript, a victim can be social engineered into clicking on it, and
the script executes on the victim's system. A typical XSS attack URL would look like this:
http://www.vulnerablesite.com/cgi-bin/search.php?keywords=&lt;script>alert("OK")&lt;script>.
In this case, when the victim clicks on this link, a message box with the text "OK" will open up
on his system.

In most cases, the attacker would craft the URL in order to try and steal the user's cookie, which
would probably contain the session ID and other sensitive information. The JavaScript could also
be coded to redirect the user to the attacker's website where malicious code could be launched
using ActiveX controls or by utilizing browser vulnerabilities such as those in Internet Explorer
or Netscape Navigator.

However, the JavaScript can also be used to redirect the user to a site that looks similar to the
original web site and requests the user to enter sensitive information such as his authentication
details for that web site, or his credit card number or social security number. A related attack is
shown below:

Figure 4: Phishing scam (Source: Article on Security Focus

http://www.securityfocus.com/infocus/1745)

In this case, the attacker has opened up two windows on the victim's system. The one in the
background is the original Citibank web site, whereas the pop up window in front of it requests
for the user's debit card number, PIN, and card expiration date. On hitting the submit button, this
information is sent to the attacker's server. Called a 'phishing' attack , it was done by sending a
spoofed email that claimed to originate from Citibank and asked users to verify their details. The
link in the spoofed email looked something like this
http://www.citibank.com:ac=piUq3027qcHw003nfuJ2@sd96V.pIsEm.NeT/3/?3X6CMW2I2uP
OVQW Most users would not be aware that as per HTTP rules, this link would actually go to
sd96v.pisem.net (highlighted above), and not www.citibank.com

Similar attacks can be carried out if the web application has scripts that redirect users to other
parts of the site, or to other related sites. For instance, in one of our assignments, the web
application had a script that was used to send the user to dynamically created parts of the web
site: http://www.vulnerablesite.com/cgi-bin/redirect.php?url=some_dynamic_value Due to the
lack of security awareness of the web developers, they did not realize that an attacker could craft
a URL such as http://www.vulnerablesite.com/cgi-bin/redirect.php?url=www.attackersite.com
and send it to a victim. This URL can be trivially obfuscated by hex-encoding the part that
follows 'url=' or by converting the attacker's IP address into hexadecimal, octal or double-word
values. For instance if the attacker's IP address is 192.168.0.1, the URL could be crafted as
follows: http://www.vulnerablesite.com/cgi-bin/redirect.php?url=http://7934518627/.

2.6 Remote command execution

The most devastating web application vulnerabilities occur when the CGI script allows an
attacker to execute operating system commands due to inadequate input validation. This is most
common with the use of the 'system' call in Perl and PHP scripts. Using a command separator
and other shell metacharacters, it is possible for the attacker to execute commands with the
privileges of the web server. For instance, Hassan Consulting's Shopping Cart allowed remote
command execution, because shell metacharacters such as |; & were not rejected by the software.
However, directory traversal was not possible in this software.

In another case, Pacific Software's Carello Shopping Cart had a vulnerable DLL that allowed the
execution of remote commands due to directory traversal attacks that could be carried out using a
specially crafted URL.

2.7 Weak Authentication and Authorization

Authentication mechanisms that do not prohibit multiple failed logins can be attacked using tools
such as Brutus . Similarly, if the web site uses HTTP Basic Authentication or does not pass
session IDs over SSL (Secure Sockets Layer), an attacker can sniff the traffic to discover user's
authentication and/or authorization credentials.

Since HTTP is a stateless protocol, web applications commonly maintain state using session IDs
or transaction IDs stored in a cookie on the user's system. Thus this session ID becomes the only
way that the web application can determine the online identity of the user. If the session ID is
stolen (say through XSS), or it can be predicted, then an attacker can take over a genuine user's
online identity vis-à-vis the vulnerable web site. Where the algorithm used to generate the
session ID is weak, it is trivial to write a Perl script to enumerate through the possible session ID
space and break the application's authentication and authorization schemes.

This was illustrated in a paper by David Endler, "Brute-Force Exploitation of Web Application
Session IDs", where he explains how session IDs of sites like www.123greetings.com,
www.register.com, and others could be trivially brute-forced. Similarly, in one such instance, we
discovered that the order ID for the user's transactions was not generated randomly, and it was
possible to access the orders placed by other users simply by writing a Perl script that
enumerated all possible order IDs within a given range. The most pertinent point here is that
although web application may have mechanisms to prevent a user from multiple password
guessing attempts during authentication, they do not usually prevent a user from trying to brute-
force sessions IDs by resubmitting the URLs as described in Endler's paper.

3. Countermeasures
The most important point is to build security into the web application at the design stage itself. In
fact, one of the key activities during the design phase should be a detailed risk assessment
exercise. Here, the team must identify the key information assets that the web application will be
dealing with. These could include configuration information, user transaction details, session
IDs, credit card numbers, etc. Each of these information assets needs to be classified in terms of
sensitivity. Depending upon the tentative architecture chosen, the developers along with security
experts must analyze the threats, impact, vulnerabilities and threat probabilities for the system.
Once these risks are listed out, system countermeasures must be designed and if necessary the
architecture itself may be modified. Countermeasures should also include strict input validation
routines, a 3-tier modular architecture, use of open-source cryptographic standards, and other
secure coding practices.

Some excellent resources on secure coding are David Wheeler's book "Security Linux
Programming HOWTO", Michael Howard's "Writing Secure Code", and John Viega's "Secure
Programming Cookbook for C and C++". The Open Web Application Security Project's Guide is
also a highly useful document on web application security issues.

4. Conclusion
The vulnerabilities discussed in this article are not necessarily exclusive to shopping carts or
online payment systems. They could easily be present in other types of web applications as well.
However, in the case of e-commerce systems, the vulnerabilities acquire a graver dimension due
to the financial nature of transactions. What is at stake is not only a direct loss of revenues, but
companies may face a serious loss to their reputations as well. In some cases, they may be faced
with legal penalties for violating customer privacy or trust, as in the case of Guess.com and
PetCo.com. It is of paramount importance for designers and developers of web applications to
consider security as a primary design goal and to follow secure coding guidelines in order to
provide the highest possible degree of assurance to their customers.
 Ecommerce Security Issues
1-Customer Security: Basic Principles

2-Protecting Yourself

Customer Security: Basic Principles

Most ecommerce merchants leave the mechanics to their hosting company or IT staff, but it
helps to understand the basic principles. Any system has to meet four requirements:

 Privacy: information must be kept from unauthorized parties.

 Integrity: message must not be altered or tampered with.
 Authentication: sender and recipient must prove their identities to each other.
 Non-repudiation: proof is needed that the message was indeed received.

Privacy is handled by encryption. In PKI (public key infrastructure) a message is encrypted by a

public key, and decrypted by a private key. The public key is widely distributed, but only the
recipient has the private key. For authentication (proving the identity of the sender, since only
the sender has the particular key) the encrypted message is encrypted again, but this time with a
private key. Such procedures form the basis of RSA (used by banks and governments) and PGP
(Pretty Good Privacy, used to encrypt emails).

Unfortunately, PKI is not an efficient way of sending large amounts of information, and is often
used only as a first step — to allow two parties to agree upon a key for symmetric secret key
encryption. Here sender and recipient use keys that are generated for the particular message by a
third body: a key distribution center. The keys are not identical, but each is shared with the key
distribution center, which allows the message to be read. Then the symmetric keys are encrypted
in the RSA manner, and rules set under various protocols. Naturally, the private keys have to be
kept secret, and most security lapses indeed arise here.

: Digital Signatures and Certificates

Digital signatures meet the need for authentication and integrity. To vastly simplify matters (as
throughout this page), a plain text message is run through a hash function and so given a value:
the message digest. This digest, the hash function and the plain text encrypted with the recipient's
public key is sent to the recipient. The recipient decodes the message with their private key, and
runs the message through the supplied hash function to that the message digest value remains
unchanged (message has not been tampered with). Very often, the message is also timestamped
by a third party agency, which provides non-repudiation.

What about authentication? How does a customer know that the website receiving sensitive
information is not set up by some other party posing as the e-merchant? They check the digital
certificate. This is a digital document issued by the CA (certification authority: VeriSign,
Thawte, etc.) that uniquely identifies the merchant. Digital certificates are sold for emails, e-
merchants and web-servers.

: Secure Socket Layers

Information sent over the Internet commonly uses the set of rules called TCP/IP (Transmission
Control Protocol / Internet Protocol). The information is broken into packets, numbered
sequentially, and an error control attached. Individual packets are sent by different routes.
TCP/IP reassembles them in order and resubmits any packet showing errors. SSL uses PKI and
digital certificates to ensure privacy and authentication. The procedure is something like this: the
client sends a message to the server, which replies with a digital certificate. Using PKI, server
and client negotiate to create session keys, which are symmetrical secret keys specially created
for that particular transmission. Once the session keys are agreed, communication continues with
these session keys and the digital certificates.

: PCI, SET, Firewalls and Kerberos

Credit card details can be safely sent with SSL, but once stored on the server they are vulnerable
to outsiders hacking into the server and accompanying network. A PCI (peripheral component
interconnect: hardware) card is often added for protection, therefore, or another approach
altogether is adopted: SET (Secure Electronic Transaction). Developed by Visa and Mastercard,
SET uses PKI for privacy, and digital certificates to authenticate the three parties: merchant,
customer and bank. More importantly, sensitive information is not seen by the merchant, and is
not kept on the merchant's server.

Firewalls (software or hardware) protect a server, a network and an individual PC from attack by
viruses and hackers. Equally important is protection from malice or carelessness within the
system, and many companies use the Kerberos protocol, which uses symmetric secret key
cryptography to restrict access to authorized employees.

Transactions
Sensitive information has to be protected through at least three transactions:

 credit card details supplied by the customer, either to the merchant or payment gateway.
Handled by the server's SSL and the merchant/server's digital certificates.
 credit card details passed to the bank for processing. Handled by the complex security
measures of the payment gateway.
 order and customer details supplied to the merchant, either directly or from the payment
gateway/credit card processing company. Handled by SSL, server security, digital
certificates (and payment gateway sometimes).

Practical Consequences
1. The merchant is always responsible for security of the Internet-connected PC where customer
details are handled. Virus protection and a firewall are the minimum requirement. To be
absolutely safe, store sensitive information and customer details on zip-disks, a physically
separate PC or with a commercial file storage service. Always keep multiple back-ups of
essential information, and ensure they are stored safely off-site.

2. Where customers order by email, information should be encrypted with PGP or similar
software. Or payment should be made by specially encrypted checks and ordering software.

3. Where credit cards are taken online and processed later, it's the merchant's responsibility to
check the security of the hosting company's webserver. Use a reputable company and demand
detailed replies to your queries.

4. Where credit cards are taken online and processed in real time, four situations arise:

1. You use a service bureau. Sensitive information is handled entirely by the service bureau,
which is responsible for its security. Other customer and order details are your
responsibility as in 3. above.
2. You possess an ecommerce merchant account but use the digital certificate supplied by
the hosting company. A cheap option acceptable for smallish transactions with SMEs.
Check out the hosting company, and the terms and conditions applying to the digital
certificate.
3. You possess an ecommerce merchant account and obtain your own digital certificate
(costing some hundreds of dollars). Check out the hosting company, and enter into a
dialogue with the certification authority: they will certainly probe your credentials.
4. You possess a merchant account, and run the business from your own server. You need
trained IT staff to maintain all aspects of security — firewalls, Kerberos, SSL, and a
digital certificate for the server (costing thousands or tens of thousands of dollars).
Security is a vexing, costly and complicated business, but a single lapse can be expensive in lost
funds, records and reputation. Don't wait for disaster to strike, but stay proactive, employing a
security expert where necessary.

Protecting Yourself
Here we provide some practical suggestions for keeping data safe, and not infringing the rules or
law relating to tax, search engines and other traders.

Office Security
The following are obvious but can be overlooked:

 use hard-to-guess passwords, restrict access to them, and don't leave them in desk
drawers or on PCs.
 ensure backups are made regularly, in sequence, and are intelligently labeled.
 check backups regularly, i.e. ensure that restores from backups are sound.*
 keep paper copies, and in a safe place.
 store copies of all essential information, preferable encrypted and off-site in:
o zips disks, CDs, removable hard-disks, etc.
o online storage facilities.*

Protection from Viruses

Do the following:

 consider using alternative browser(s).

 get the appropriate virus protection software, and keep it up to date.*
 install a decent firewall.*
 set passwords properly on networks ( IT manager's job).

Protection from Spyware

Many computers are infected by spyware of some sort. Most are 'harmless', but an increasing
number pass into viruses that will steal and transmit confidential information, even memorizing
the keystrokes of passwords. You need to:

 avoid keeping confidential information on any machine connected to the Internet.*

 run spyware removal software.*
 encrypt confidential information.*
 consider purchasing a special guide to spyware.
 visit security sites for information on the latest threats

Protection from Hackers
Hackers break into computer systems, sometimes to prove themselves, sometimes with malicious
intent. You need to:

 install a firewall.*
 ensure sensitive information is encrypted.*
 maintain proper security (restrict access with passwords) in the office.

Protection from Fraud

You don't have to accept every order, or not immediately. Escrow services are widely available.
Trade associations and other institutions provide useful information and support. Payment
service providers have levels of security. Your own order page can ask for further details, and its
country drop-down list be amended to exclude the worst offenders.*

Affiliate businesses need to be especially careful, and in these ways:

 prevent competitors stealing their affiliate links by using inexpensive software for the
purpose.*
 prevent bogus clicks-throughs by competitors who do not purchase: aim to bankrupt you
with the pay-per-click search engines.
 impression fraud by competitors aiming to lower your click-through rates and so
disqualify your ads with Google.

The last two scams are often outsourced to low-wage outlets and/or employ special software.
You'll need to track your clicks with special click auditing software (sometimes included in bid
management software), or ensure that the company that runs your pay-per-click campaigns does
so.

Web servers
Webserver security is highly technical, as you'll appreciate by reading the articles listed on the
resources page. Obvious things to check or ask about:

 the financial standing of the hosting company, and how long they have been in business.*
 guaranteed uptime*
 security protocols to cope with denial-of-service and hacker attacks.*
 regularity of backups: does it include user logs, product databases, order tracking logs,
server-side scripts, etc.?*
 whois database (www.whois.net) to ensure that you and not the hosting company remain
the administrative and technical contact for your domain and — most critically — the
registrant of the domain.*
 backup: ring them at 3 a.m. Sunday morning if they claim 24/7 telephone support.*
  complaints procedure: you don't want your site dumped because of an unwarranted
complaint from a competitor.*
 other sites being hosted with them (ask for webmasters to contact). Also check:
association with spam or porn sites won't help your business.*
 the business address of the server (whois). Find the path to the server with a tracing
program: with a reseller you'll find some other ISP's server.*
 visit forums to see what webmasters really think about hosting companies.*
 scrutinize the contract (and employ a business lawyer to check copyright, complaints,
fees and service renewal / discontinuation matters).*

And:

 host alternative company domains with another company: you can then switch painlessly
if the first goes out of business or suffers a prolonged denial of service.*
 check your webmaster is implementing proper routines, including the updating of
passwords regularly.*

Webpage Content
You are responsible for the content of your webpages, which means ensuring:

 nothing is libelous or could be construed so.*

 material does not infringe copyright.*
 links don't damage the interests of sites linked to (deep-linking may).*
 pages don't fall foul of search engine and directory requirements.*

America is a litigious society. Play safe, and even consider cloaking techniques to prevent
information being extracted from pages and made the basis of frivolous lawsuits. (But only use
cloaking if you know what you're doing: search engines will drop a site if they suspect the device
is being used improperly.)

Customer Data
You are always responsible for customer information: an onerous task if it includes credit card
and/or bank details. Use secure web forms that automatically transfer and store customer
information safely on a third-party secure site.* Encrypt it.* Keep it off Internet-connected
machines.* Make several copies and store safely off-site.* Seventy percent of companies that
lose their customer data go out of business within the year.

Legal Matters
Your company is bound by the laws and regulations of the state or country in which you are
incorporated. Check that you understand the basics, and have experts to consult if and when
needed. Be especially careful of material that could offend the authorities or religious groups
abroad, be considered inflammatory, or supportive of outlawed or terrorist groups — i.e. keep
your social and political aspirations for another site and another name.

References:
1. SQL injection and Oracle, Pete Finnigan http://www.securityfocus.com/infocus/1644
2. Advanced SQL injection, Chris Anley
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
3. News article on SQL Injection vulnerability at Guess.com
http://www.securityfocus.com/news/346
4. Jeremiah Jacks at work again, this time at PetCo.com
http://www.securityfocus.com/news/7581
5. Achilles can be downloaded from http://achilles.mavensecurity.com/
6. CERT Advisory Malicious HTML HTML Tags Embedded in Client Web Requests
http://www.cert.org/advisories/CA-2000-02.html
7. Definition of 'phishing' http://www.webopedia.com/TERM/p/phishing.html
8. Brutus can be downloaded from http://www.hoobie.net/brutus/
9. Brute-Force Exploitation of Web Application Session IDs, David Endler
http://www.idefense.com/application/poi/researchreports/display
10. Secure Programming for Linux and Unix HOWTO, David Wheeler,
http://www.dwheeler.com/secure-programs/
11. OWASP Guide http://www.owasp.org/