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

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 ID.

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 for details).

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.

Database vulnerabilities

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 traceable.
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.

Customer's passwords

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 problems:

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 eBay.
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.

In general, a business web site may be better off without customer's passwords, and should not rely on them for protection of sensitive information.

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 emachkas@wellesley.edu

Spring Semester 2002