Security in e-commerce
While many security issues in e-commerce are the same as general security
issues, some of them are specific for the kind of software used by e-commerce
businesses: databases, in particular databases which are accessed remotely,
online forms, and shopping carts. Below we consider these specific
vulnerabilities as well as more general ones.
SSL allows to transfer data in an encrypted form. All information that a
customer might want to keep private should be transmitted via SSL. Such
information should definitely include credit card number and related
information, and may, depending on the type of business, include
customer's name, address, and the list of products that the customer
is buying. It should also include the customer's password and order
SSL connection (i.e. connection via https, instead of http) should be the
default for transmitting customer's information. However, it is often
not the default protocol on many commercial web sites. The reason why many
businesses don't use SSL as default is because SSL connection is slower than
a regular http connection (due to encryption and decryption). eBay has been
criticized recently for transmitting passwords in the clear rather than
encrypted (click here
How reliable is SSL itself? In 1998 a Bell Labs researcher Daniel
Bleichenbacher has discovered a problem with a version of SSL used at that
time: it turned out that a long sequence of specifically designed messages
allows to figure out the key used by a server in a session by studying error
messages returned by the server. Since then SSL has been patched so that no
information about the key can be gathered from error messages. The problem,
however, was more theoretical than practical, because figuring out the key
required around a million messages sent over a designated connection. SSL is
considered a secure way of transmitting private information.
More common vulnerabilities in e-commerce are caused remotely accessed
databases. Below are some examples:
- Running SQL queries based on data entered by the user may allow a
malicious user to append their own query to the one that is supposed to be
executed. For instance, suppose a user enters the size of the product which
she/he is interested in into an online form. The size is a number which gets
appended to the following string:
SELECT ProductName FROM Products WHERE Size =
If the user enters 6, then the string becomes:
SELECT ProductName FROM Products WHERE Size = 6
This string is sent to the database as a query and returns the list of products
of size 6. However, a malicious user can enter the following into the form:
6; DELETE FROM Products
When the string is appended to the initial string, it becomes:
SELECT ProductName FROM Products WHERE Size = 6; DELETE FROM Products
When this string is passed to the database, in many systems it will cause both
queries to be executed, and in addition to selecting the list of products, the
query will delete all information from the table Products. The query "TRUNCATE
Products" will cause even more damage, because it empties the table without
entering the changes into the log, so the changes are not easily
Similar things can be done, in addition to online forms, with URL rewriting
and cookies. Note that the user can easily type in any URL into the browser
window, including a URL which contains an extra query. The user can also
easily alter a cookie which resides on the user's computer.
To avoid these vulnerabilities, one has to check the data entered by the user,
as well as URLs and cookies, to make sure that they are of the correct format.
One can also restrict privileges of the process running search queries so
that it is not allowed to remove data from the database. One also has to be
careful not to expose table names in the text of online forms, since
this attack requires the hacker to know the table name in order to
delete the information from it.
- Another group of database security issues comes from exposing
database servers to hackers. To prevent unauthorized access, database servers
should be inside a firewall. It is also important that database passwords
and user names are not exposed in web pages that a user can see (not only in
plain text, but also in hidden fields, and in Java script code). Such passwords
and user names should be transmitted encrypted. Recent break-ins into
databases include not only e-commerce sites, but even the government.
- Since many employees of an online business have access to the database,
their account names and passwords should be kept secure. Also, all code that
contains passwords for database access (such as Java code of applets and
servlets) should be stored securely.
Shopping cart vulnerabilities
Numerous vulnerabilities have been discovered in shopping carts, both
commercially produced and "home made" ones:
- Price manipulation. If a price of the product is passed as a
hidden parameter in an online form and the value of the parameter is used to
determine the charge on the credit card, then a customer can easily replace
the HTML page with the form by their own page, where all the information is
the same, but the price is changed to a lower one.
To avoid the problem, the price should be looked up in the database, rather
than taken from the form. Servlets also prevent the problem, because the
product information is passed in the Session object on the server. The client's
machine sends the cookie to the server to identify the session, but the cookie
itself does not contain any information about products or prices.
Transaction modification uses a similar idea: if the merchant's
site redirects the user to another web site for credit card verification or
sends a request for the charge to the credit card company,
this is often done via a POST request. The request may contain
the amount of the credit card charge or the kind of
a transaction (some transactions may be specified as "test", in which case no
actual charge takes place). The user may modify the amount of charge or
mark their transaction as "test".
Exposing merchant's ID. When the merchant sends a credit card charge
request, the request may contain the merchant's ID. If the ID is exposed in
the web site forms, a hacker may use this ID to send their own requests to
the credit card company. The request may include canceling a transaction, thus
crediting money to the credit card. Hackers also may use merchant's ID to check
if a credit card number is valid. This vulnerability has been recently used
by hackers to check thousands of credit card numbers at the expense of several
online merchants. Click
here for details.
- Other things that may be exposed by poorly written shopping cart code
are: IP addresses of database servers, user name and password for database
access, names of database tables and columns. All this may cause theft,
damage, or modification of the data stored in the database.
- Another group of break-ins is related to so-called back door access to
a shopping cart: shopping carts come with passwords that allow the owner to
change settings or access information in the shopping cart or the database.
Initially these passwords are set to default. Once the default becomes known
to hackers, the software can be easily accessed and changed to serve the
purposes of the hacker.
Many online businesses use customer's passwords to authorize access to
sensitive data (such as the order information). However, one has to be
extremely careful with how the password system works. Here are potential
In general, a business web site may be better off without customer's
passwords, and should not rely on them for protection of sensitive
- People tend to forget their passwords. A forgotten password needs to
be reset. However, resetting a password should be done securely. The
confirmation should be sent by e-mail, and the new password should not be
used until the customer replies to the e-mail. One of the recent cases
of security breaches involving changing passwords was discovered at
- Another possibility for stealing passwords is to "impersonate"
a merchant and to request the user's password. AOL has been a victim
of a recent scam, click here for details.
Installing recent patches
Software bugs and vulnerabilities are discovered every day. Even though
many of them are discovered by security experts, rather than hackers,
they may still be exploited by hackers once they became a public knowledge.
That's why it is important to install all software patches as soon as they
become available. This link describes one of the recent vulnerabilities.
This page has been created and is maintained by Elena Machkasova
Comments and suggestions are welcome at firstname.lastname@example.org
Spring Semester 2002