Strategies for Dealing with Security

One of the greatest features of the Internetthe accessibility of all machines to each otherturns out to be one of the biggest headaches that you will have to face. With so many computers out there, some users are bound to have less than noble intentions. It has been estimated that over three quarters of all PCs connected to the Internet are infected with spyware, adware, or bot software that has the machines doing things without the knowledge of their owners. In one study, by the American newspaper USA Today and Avantgarde, a San Francisco-based technology marketing firm, installed a version of a modern commercial operating system on a computer (without any of the latest patches), connected it to the Internet, and waited. Within four minutes, the machine had been compromised!

With all of this danger swirling around us, it can be intimidating to think about exposing a web application with confidential information (for instance, bank account information) to the global network. But business must go on, and we must develop an approach to planning for and dealing with security. The key is to find one with the appropriate balance between protecting ourselves, doing business, and having a working application.

The Most Important Thing

Security is not a feature. When you are deciding the list of features that you would like to include in a web application, security is not something that you casually include in the list and assign a developer to work on for a few days. It must be part of the core design of the application to which you must always devote effort, even after the application is deployed and development has slowed or ceased.

As you work through your application and design features, you must think not only of how you would like the feature to be used, but also how it could be misused. If we were to write a specification for a feature area, we could structure it as follows:

Feature: Message Entry Form.

Usage: Users will be presented with a form in which they can enter a message in their online journals. They will have the ability to enter a title, a priority level (in case they want to limit viewers), and a body for the message. In this body, they can include certain markup tags for HTML, such as , ,  , , <ul>, <li>, and . No other tags will be permitted. The "Preview" and "Submit" buttons allow the user to view the entry and commit it to the database.

Misuse: There are a number of ways in which this form can be misused:

SQL Injection Attacks We must filter out SQL in any of the input fields.
Cross Site Scripting (XSS) We must be sure that no script can get through our filters and into the results seen by users.
Denial-of-Service There are two ways that this form could translate into a denial-of-service. First, if the user enters a message that is very large, he could rapidly fill up our database. Second, if a user enters a large number of messages in a very short period of time, this could also fill our databases. To prevent this, we should place a limit on the maximum size of an entry and the maximum number of entries that a user account may submit in a 24-hour period.

By thinking of and planning for, right from the beginning, the various ways in which our system could be abused, we can design our code to reduce the likelihood of these problems occurring. This also saves us from trying to retrofit everything later when we finally turn our attention to the problem.

Balancing Security and Usability

One of the greatest concerns we have when designing a user system is the users' passwords. Users often choose passwords that are not difficult to crack with software, especially when they use words readily available in dictionaries. We would like a way to reduce the risk of a user's password being guessed and the subsequent danger to our system.

One solution would be to require users to go through four login dialog boxes with separate passwords. We could also require users to change their passwords at least once a month and never use a password they have used before. This would make our system much more secure, and crackers would have to spend more time getting through the login process to the compromised system.

Unfortunately, our system would be so secure that nobody would bother to use it. At some point, they would decide that it was simply not worth it. This illustrates how worrying about usability is just as important as worrying about security. An easy-to-use system with little security might prove attractive to users, but it will also result in a higher probability of security-related problems and business interruptions. Similarly, a system with security so robust that it is borderline unusable will attract few users and negatively affect our business.

As web application designers, we must look for ways to improve our security without disproportionately affecting the usability of the system. As with all things related to the user interface (see Chapter 14, "Implementing a User Interface"), there are no hard and fast rules to follow; instead, we must rely on personal judgment, usability testing, and user feedback to see how users react to our prototypes and designs.

After Development Finishes

Even after we finish developing our web application and deploy it to production servers for use, our job is not complete. Part of security is monitoring the system as it operates by looking at logs and other files to see how the system is performing. Only by keeping a close eye on the operation of the system (or by running tools to do portions of this for us) can we monitor ongoing security problems and identify areas where we need to spend time developing more secure solutions.

Unfortunately, security is an ongoing battlea battle that can never be won. Constant vigilance, improvements to our system, and rapid reaction to any problems are the price to be paid for a smoothly operating web application.

Our Basic Approach

To give ourselves the most complete security solution possible for a reasonable amount of effort and time, we will describe a two-fold approach to security. The first part will discuss how to secure our application and how to design features that will keep it safe. We could call this a top-down approach.

In contrast, we might call the second part of our security approach a bottom-up approach. In this phase, we will look at the individual components in our application, such as the database server, the server, and the network. We will ensure that our interactions with these components, in addition to the installation and configuration of these components, are safe. Many products install with configurations that leave us open to attack, so we should learn about these holes to plug them.

Table of Contents