In this chapter, you modified the EmployeeManagementWeb application to use forms-based authentication and you created two sample applications—one that uses Windows authentication and another that uses Passport authentication. The next chapter builds on these techniques by adding to Forms-based authentication SSL encryption that protects the credentials the
chapter also discusses how to use the ASP.NET authorization settings to personalize the application for each user.
Securing Web Applications
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
world, where you can find out the weather in New Zealand, read about
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
provide. Potentially, your
might be made on a catchy URL, a
Web site, and a truckload of
Many first-time customers will be initially wary of your fledgling plastic dinosaur empire. Newspapers have regular
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
rex, Web users are alert for the smallest signal that something is wrong. To make these first-time users comfortable and
them into return customers, you must provide a great
experience. An essential part of achieving this goal is to provide a secure experience. The challenge
you is that the Internet is
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
its destination. The process of a packet being passed from one router to another is called a
. The Microsoft Windows command-line program TraceRt.exe (short for
) 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.
13 hops to Yahoo
While your TCP/IP packet is
its way to Yahoo,
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
tool such as Ethereal (a free download, available from
). 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.
Intercepting TCP/IP packets
How likely is it that someone will intercept your TCP/IP packet? The
is small if a hacker is simply
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
employee or evil competitor jealous of your success
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.
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
seaboard of the United States—the flaw is called a
. 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
. 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
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
, 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.