Microsoft ASP.NET Coding Strategies with the Microsoft ASP.NET Team (Pro-Developer)

We’ve all seen the aftermath of various worms and viruses. Given the huge number of systems affected and their global reach, you’ve probably already dealt with this sort of disruption firsthand. Fortunately, keeping a server updated with the latest fix might be all that’s necessary to prevent a problem, and recovering from an infected system has been relatively straightforward so far. But these high-profile episodes are just part of the overall security story. The more insidious attacks are less publicized: the system compromises that result in corrupted or stolen data. In these cases, keeping a server updated with the latest security fix won’t help. You have to be prepared before the damage is done. You must design, write, and deploy the applications with security always in mind.

In this chapter, we’ll cover the features of version 1.1 of the .NET Framework that make writing secure applications easier. We will look at the mechanisms available for limiting access to parts of a Web application and consider what you can and should do to limit the risk when dealing with sensitive data. We will also cover the basic steps to hardening a Web server.

Introducing ASP.NET Application Security

First, let’s establish what we mean by authentication, authorization, and impersonation. (We’ll introduce them here but talk about each in more detail later in this chapter.) These terms can be confusing, so let’s define them in a more concrete way by using the metaphor of securing an office building.

Authentication is simply establishing the identity of the user. In the secure office building, every person must have an ID badge. Each person who works in the building might be issued a cardkey or badge to display, and a visitor might be asked to wear a temporary ID.

Authorization is a set of rights granted to particular users. Once the ID is established through authentication, security isn’t improved beyond the ability to log an individual’s actions unless we enforce that only certain users can access certain resources. In the secure office building, we might limit specified groups to accessing only certain parts of the building. For example, only those individuals working on a top-secret project would be authorized to enter the project lab.

Impersonation is assuming the identity of someone else. In our example, impersonation would be using the cardkey issued for someone else’s authentication. When impersonating, all actions appear to be carried out by the assumed identity.

Figure 8-1 shows how Microsoft Internet Information Services (IIS) acts as the front line in establishing user permissions, and how ASP.NET builds on top of it later in the request.

Figure 8-1: IIS and ASP.NET authentication and authorization

These key security concepts are the basis for creating a secure Web site. IIS and Microsoft ASP.NET work together closely to authenticate and impersonate users, authorize requests, and delegate credentials to gain access to the required resources. ASP.NET goes beyond these security primitives to validate input and perform dynamic role checking.

The security role IIS performs is driven primarily by configuration data, using Microsoft Windows accounts and certificates for authentication, and NTFS (file permissions) for authorization.