Chapter 5: Securing Web Applications

Overview

Key concepts in this chapter are:

• Obtaining and installing a certificate

• Using SSL to secure a login form

• Securing Web services

• Adding audit tracking

• Designing an application for security

Think of any English word, put a .com on the end, and type it into your browser. Within seconds, you’ll be transported to someone’s magical world, where you can find out the weather in New Zealand, read about beach resorts in Costa Rica, or buy miniature plastic dinosaurs from an entrepreneurial father of three operating out of a pizza-delivery van somewhere in western Washington. We live in crazy times. The Internet is a true meritocracy—millions of customers will try, buy from, or take flight from your Web site based on the service or disservice you intentionally or accidentally provide. Potentially, your fortune might be made on a catchy URL, a stellar Web site, and a truckload of miniature plastic dinosaurs.

Many first-time customers will be initially wary of your fledgling plastic dinosaur empire. Newspapers have regular reports of Web sites that are fraudulent or unsecured, and Web users are increasingly shy of disclosing too much information. Like a young brontosaurus sniffing the wind for the scent of a tyrannosaurus rex, Web users are alert for the smallest signal that something is wrong. To make these first-time users comfortable and turn them into return customers, you must provide a great user experience. An essential part of achieving this goal is to provide a secure experience. The challenge facing you is that the Internet is inherently an insecure environment—each time you send information over the Internet, the information is formatted as a TCP/IP packet, and this TCP/IP packet might be passed through 10 or 20 routers before it reaches its destination. The process of a packet being passed from one router to another is called a hop . The Microsoft Windows command-line program TraceRt.exe (short for trace route ) is useful for showing how many hops are required to reach a destination. Figure 5-1 shows a TraceRt.exe output example for reaching the Yahoo home page. From the author’s machine, it takes 13 hops to reach www.yahoo.com.

Figure 5-1: 13 hops to Yahoo

While your TCP/IP packet is hopping its way to Yahoo, anyone who has access to your Internet gateway, the hop routers, or the Yahoo Internet gateway can intercept and read your TCP/IP packets. How easy is this to do? It’s useful to install a packet-sniffing tool such as Ethereal (a free download, available from http://ethereal.ntop.org ). Ethereal will intercept and display the contents of any packet sent over the Internet from your machine. Figure 5-2 shows the output of Ethereal while accessing www.yahoo.com. All the information returned to the Web browser is easily seen in the main window of Ethereal.

Figure 5-2: Intercepting TCP/IP packets

How likely is it that someone will intercept your TCP/IP packet? The likelihood is small if a hacker is simply randomly intercepting TCP/IP packets. Because a hacker can capture only a limited number of packets at any given time, your one packet among millions is probably safe because of the sheer volume of traffic on the Internet. However, the odds of your information being intercepted increase if someone such as a disgruntled employee or evil competitor jealous of your success specifically decides to target your Web application. The best practice is to assume that someone with malicious intent is monitoring every communication with your Web site. You should ask yourself whether or not you would be comfortable with your data being made public. In the same way that you probably lock your car if you leave it in a public parking lot overnight, you should secure any data that you want to be kept private.

Is It a Bug, or an Attack from a Criminal Mastermind?

When a Web application has a flaw—such as exposing sensitive data, crashing unexpectedly, or allowing an unauthorized user to shut off electricity to the eastern seaboard of the United States—the flaw is called a vulnerability . The vulnerability might be triggered accidentally by a valid user or maliciously by an intruder intent on disrupting the distribution of miniature plastic dinosaurs. When this happens, it is called an exploit . The practices throughout this book are designed to help you protect against exploits regardless of the person’s intentions—creating a more robust application for legitimate users and a more secure application to protect against unauthorized intruders.

Web applications are typically data-centric applications. For example, an application may collect data from a customer, create an order that includes purchase details, update the customer’s personal profile, and process credit card information. The application may then kick off the process for fulfilling and shipping the order to the customer. In this type of situation, the most important things to secure are the personal information of the customer and the validity of the order. A less common type of Web application is a control system , which affects a physical system, such as opening the floodgate of a dam. The best practice for securing control-system applications, which if left unsecured could endanger human life or critically damage your business, is simple: don’t connect them to the Internet.