e-Commerce security: Attacks and preventive strategies - IX

Site development best practices

This section describes best practices you can implement to help secure your site.

Security policies and standards

There are many established policies and standards for avoiding security issues. However, they are not required by law. Some basic rules include:

• Never store a user's password in plain text or encrypted text on the system. Instead, use a one-way hashing algorithm to prevent password extraction.
• Employ external security consultants (ethical hackers) to analyze your system.
• Standards, such as the Federal Information Processing Standard (FIPS), describe guidelines for implementing features. For example, FIPS makes recommendations on password policies.
• Ensure that a sufficiently robust encryption algorithm, such as triple DES or AES, is used to encrypt all confidential information stored on the system.
• When developing third-party software for e-Commerce applications, use external auditors to verify that appropriate processes and techniques are being followed.
• Recently, there has been an effort to consolidate these best practices as the Common Criteria for IT Security Evaluation (CC). CC seems to be gaining attraction. It is directly applicable to the development of specific e-Commerce sites and to the development of third party software used as an infrastructure in e-Commerce sites.

Security best practices remain largely an art rather than a science, but there are some good guidelines and standards that all developers of e-Commerce software should follow.

Using cookies

One of the issues faced by Web site designers is maintaining a secure session with a client over subsequent requests. Because HTTP is stateless, unless some kind of session token is passed back and forth on every request, the server has no way to link together requests made by the same person. Cookies are a popular mechanism for this. An identifier for the user or session is stored in a cookie and read on every request. You can use cookies to store user preference information, such as language and currency. This simplifies Web page development because you do not have to be concerned about passing this information back to the server.

The primary use of cookies is to store authentication and session information, your information, and your preferences. A secondary and controversial usage of cookies is to track the activities of users.

Different types of cookies are:

• Temporary cookies: These cookies are valid only for the lifetime of your current session, and are deleted when you close your browser. These are usually the good type. They are mostly used to keep your session information.
• Permanent cookies: These are for a time period, specified by the site, on the shopper's computer. They recall your previous session information.
• Server-only cookies: These cookies are usually harmless, and are only used by the server that issued them.
• Third-party cookies: These are usually used for tracking purposes by a site other than the one you are visiting. Your browser or a P3P policy can filter these cookies.

If you do not want to store cookies, here are other alternatives:

• Send user ID/password on every request: This was popular 5-10 years ago, but now recognized as an insecure technique. The user ID/password flowing under non-SSL is susceptible to attacks. This alternative is not practical for a high volume site. Pages that run under SSL would slow down site performance.
• SSL client side authentication: This is the most secure, but it is cumbersome for shoppers to install on their browsers. You have to pay for a company to verify who you are and to issue a certificate. The popularity of this technique for client-side authentication has decreased in recent years. It remains very popular on server sites.
• URL rewriting: This is a popular alternative to cookies. Each HTTP link on the page is specially encoded, but it is expensive for the site to implement. It interferes with the performance of the site because the pages cannot be cached and reused for different users. This alternative is susceptible to attack if it is not used under SSL.

Cookies marked as secure (storing encrypted data and passing to the user only under SSL) remain the most popular method of providing a secure online experience.

Using threat models to prevent exploits

When architecting and developing a system, it is important to use threat models to identify all possible security threats on the server. Think of the server like your house. It has doors and windows to allow for entry and exit. These are the points that a burglar will attack. A threat model seeks to identify these points in the server and to develop possible attacks.

Threat models are particularly important when relying on a third party vendor for all or part of the site's infrastructure. This ensures that the suite of threat models is complete and up-to-date.

Figure 11. Threat models
 

Responding to security issues

An effective overall security strategy is to be prepared when vulnerabilities are detected. This also means ensuring that software vendors selected for all or part of the site's infrastructure have proactive and reactive policies for handling security issues.

In the case of WebSphere Commerce, we can quickly form a SWAT team with key developers, testers, and support personnel. This becomes the highest priority for all involved parties. An assessment is made immediately, usually within the first few hours, to determine the vulnerability of the merchant's sites. A workaround or permanent solution is developed for the affected sites within a day. Then a "flash" issued to all customers to notify them of the problem, the solution, and how to check if they have been exploited. For critical issues, no one leaves until there is a solution.

Using an online security checklist

Use this security checklist to protect yourself as a shopper:

• Whenever you logon, register, or enter private information, such as credit card data, ensure your browser is communicating with the server using SSL.
• Do not shop at a site when the browser does not recognize the server's SSL certificate. This check is done by your browser the first time your URL becomes HTTPS for the site. If the certificate is not recognized, then your browser presents a pop-up message to inform you.
• Use a password of at least 6 characters, and ensure that it contains some numeric and special characters (for example, c0113g3).
• Avoid reusing the same user ID and password at multiple Web sites.
• If you are authenticated (logged on) to a site, always logoff after you finish.
• Use a credit card for online purchases. Most credit card companies will help you with non-existent or damaged products.
• A bricks and mortar store with an online brand is most likely a legitimate site. However, the site may still have vulnerabilities.