EXPERT RESPONSE
Firstly, you should check the security of the servers hosting the e-commerce site. A Web server needs to be hardened and securely maintained. For guidance, I recommend that you download the appropriate Security Configuration Guide from the U.S. National Security Agency Web site. The guides are free and cover most Web servers. You can also use the NIST (National Institute of Standards and Technology) Security Configuration Checklists Repository to find instructions and procedures on how to complete a secure configuration. The free Benchmark and Scoring Tools from the Center for Internet Security (CIS) also provides a quick and easy way to evaluate an e-commerce Web infrastructure and compare its level of security against minimum due-care security benchmarks.
Generally speaking, an e-commerce database needs to reside on a separate server, which also should be hardened and protected. Ensure that all database connections are secured and that the database table access control list is suitably configured for a publicly accessible database. Again, the CIS provides benchmarks and scoring tools for Oracle and SQL Server databases.
Once the servers are secure, check and review the security of the actual e-commerce application. The most common mistakes that make Web applications susceptible to attack are:
Failing to constrain and validate input;
Failing to encode output; and
Trusting data retrieved from a database or cookie.
An application should be designed so that all data is assumed to be from an untrusted source. All data, whether it is supplied by customers or read from a cookie or database, needs to be validated for type, length, format and range. Any data that isn't well-formed and correct should be rejected. Many applications sanitize input by filtering out known unsafe characters. This filtering, however, is not a best practice since malicious users can usually find an alternative means of bypassing the validation process. Instead, write applications to check for known secure, safe input. The validation needs to take place on a trusted server, not on the client. Only once this verification has taken place should data be passed on to your scripts and database.
When data is requested from a database, use parameterized queries and stored procedures to help prevent SQL injection attacks. To ensure that special HTML characters are displayed correctly, the data that is sent back to the client needs to be encoded. Web pages should set the correct character encoding. Finally, if an application does run into a problem, it should handle any errors without divulging system information to the user. Attackers can use overly verbose error messages to learn about the inner workings of an application.
Once you have ensured that your application correctly handles incoming and outgoing data, you should run a penetration test. By simulating an attack, you can evaluate whether the site has any potential vulnerabilities resulting from poor or improper system configuration, hardware or software flaws or weaknesses in the perimeter defenses protecting the site. There are several tools that can automate this task. I would also recommend that you read the Open Source Security Testing Methodology Manual. The guide provides a recognized methodology for performing security tests and measuring the results.
More information:
Joel Dubin explains the best authentication method for protecting an online banking site.
Learn how to be ready for Web site attacks.
|
