eWeek labs this past year had up-close-and-personal experience with the data security, privacy and integrity issues that keep e-business managers up at night: the eWeek eXcellence Awards Web site (www.excellenceawardsonline.com).
Significantly increasing the complexity of the Web project was our requirement that companies nominating products make a donation of $100 to the Starlight Childrens Foundation (www.starlight.org), which provides computers and Internet access to hospitalized children.
As the broker of the donations, we had to support secure communication links and securely store and process credit card data. We also provided payment confirmation by e-mail and payment status information online.
Our site mirrored the challenges of a marketplace or business exchange site, where competitors interact with shared services in carefully controlled ways. The eXcellence Awards program was a highly competitive process, and many companies provided sensitive information on release dates and feature sets. It was critical for us to be able to assure site users that none of their competitors would be able to sniff out entry information by accident or deliberate malicious effort.
We went to working making sure the eXcellence Awards Web application met privacy and security requirements.
Application errors are a frighteningly common source of security and privacy vulnerabilities on Web sites, particularly because the application server must have trusted access to the database. (We used Apache Groups TomCat Java Server Pages application server.)
In designing the overall infrastructure of the site, we tried to modulate tasks as much as possible to identify where security-sensitive transactions, such as logging in to the site or the database, occurred. We extracted this code and placed it into a set of included files so that we could guarantee that we used and maintained a single code library for these tasks.
Handling the database password was a particularly sensitive issue. We decided not to specify the password anywhere in JSP code, since there have been bugs in the past that have allowed users to see scripting code embedded in HTML pages. Instead, our code dynamically loaded the database password from a disk file, letting us rely on the Unix file system permission system as an additional layer of protection.
We also configured MySQL ABs MySQL security settings to only allow database connections from the local machine, so any unauthorized database activity would require a cracker to create and upload a modified JSP page or get shell access to the server.
Tracking user identifications and making sure users were never able to access pages or information not associated with their user ID was another important task. We again used a set of shared include files to ensure users had logged in before seeing certain pages. We tracked user ID information in a server-side session object, not a client-side cookie. We did use temporary cookies to store a users session ID but not to store a users name or password information. Relying on an anonymous source (such as a client browser) to provide trusted information is a mistake.
We then added security checks to the top of every page that included sensitive information. We ensured that users were correctly logged in and did real-time database lookups.
For example, we used an entry ID as a parameter for one page but did a lookup on the company ID of that entry ID. We then matched this information against the company ID of the logged-in user before displaying any entry information.
We also developed a set of wrapper classes that were called on every variable that was sent to the database as part of a SQL statement. This code checked variable contents for database control characters, such as semicolons, quote characters and backslashes, and either removed them or marked them using escape characters so the database would treat them as ordinary text, not as commands.
Dont forget to secure less-visible places where sensitive data can be stored, such as database activity log files and backup files. We stored log and backup data securely offsite, deleting the old data from the server each time.
The problems we did have cropped up in unexpected places. For example, during the course of the awards program, we sent out several mass e-mailings to people who nominated products. In one mailing, a large number of e-mail addresses were cut from another document and pasted into the “To:” field of the e-mail message. None of the names, companies and addresses were hidden. This security (and cultural) breach is further evidence that security is indeed about process and not just products.
One error we made resulted in someone being able to get around our deadline for nominations (although only by a couple of hours). At one point we had renamed a set of server files but left the old files in place to allow users to finish their sessions. We forgot to remove the old files, which did not include the deadline code, so a user was able to use the old file names to submit a new entry. Because current browsers auto-complete URL references from their caches, information on old file names is easily accessible to users.
