Chapter 20 - Security Fundamentals PDF

Preview

Summary

CHAPTER 20 Security Fundamentals O rdinarily, your ASP website is available to anyone who connects to your web server, whether over a local network or the Internet. Although this is ideal for many web applications (and it suits the original spirit of the Internet), it isn’t always an appropriate des...

Description

CHAPT ER

20

Security Fundamentals O

rdinarily, your ASP.NET website is available to anyone who connects to your web server, whether over a local network or the Internet. Although this is ideal for many web applications (and it suits the original spirit of the Internet), it isn’t always an appropriate design choice. For example, an e-commerce site needs to provide a secure shopping experience to attract customers. A subscription-based site needs to limit content to extract a fee. And even a wideopen public site may provide some resources or features that shouldn’t be available to all users. ASP.NET provides an extensive security model that makes it easy to protect your web applications. Although this security model is powerful and profoundly flexible, it can appear confusing because of the many different layers that it includes. Much of the work in securing your application isn’t writing code, but determining the appropriate places to implement your security strategy. In this chapter, you’ll sort out the tangled ASP.NET security model. You’ll learn two ways to authenticate users—first, using forms authentication (which is ideal for a public website that uses a custom database) and then using Windows authentication (which is ideal for an intranet application on a company network). You’ll also take a brief look at SSL (Secure Sockets Layer), the standard for secure web communication.

Determining Security Requirements The first step in securing your applications is deciding where you need security and what it needs to protect. For example, you may need to block access in order to protect private information. Or, maybe you just need to enforce a pay-for-content system. Perhaps you don’t need any sort of security at all, but you want an optional login feature to provide personalization for frequent visitors. These requirements will determine the approach you use. Security doesn’t need to be complex, but it does need to be wide-ranging and multilayered. For example, consider an e-commerce website that allows users to view reports of their recently placed orders. You probably already know the first line of defense that this website should use—a login page that forces users to identify themselves before they can see any personal information. In this chapter, you’ll learn how to use this sort of authentication system. However, it’s important to realize that, on its own, this layer of protection is not enough to truly secure your system. You also need to protect the back-end database with a strong password, and you might even choose to encrypt sensitive information before you store it (scrambling so that it’s unreadable without the right key to decrypt it). Steps like these protect your website from other attacks that get beyond your authentication system. For example, 691

692

C HA PT ER 20  SEC URIT Y FUNDA MENTA L S

they can deter a disgruntled employee with an account on the local network, a hacker who has gained access to your network through the company firewall, or a careless technician who discards a hard drive used for data storage without erasing it first. Furthermore, you’ll need to hunt carefully for weaknesses in the code you’ve written. A surprising number of websites fall prey to relatively simple attacks in which a malicious user simply tampers with a query string argument or a bit of HTML in the rendered page. For example, in the e-commerce example you need to make sure that a user who successfully logs in can’t view another user’s recent orders. Imagine you’ve created a ViewOrders.aspx page that takes a query string argument named userID, like this: http://localhost/InsecureStore/ViewOrders.aspx?userID=4191 This example is a security nightmare, because any user can easily modify the userID parameter by editing the URL to see another user’s information. A better solution would be to design the ViewOrders.aspx page so that it gets the user ID from the currently logged-on user identity (a trick you’ll learn in this chapter), and then uses that to construct the right database command.

Note Another example of a security vulnerability introduced by poor coding is the ever-common SQL injection attack. You learned to prevent this attack by using parameterized database commands in Chapter 15.

When designing with security in mind, it’s important to consider the different avenues for attack. However, you can’t always anticipate potential problems. For that reason, it makes great sense to layer your security. The mantra of security architects can be summed up like this: “Don’t force an attacker to do one impossible thing to break into your system—force them to do several.”

The ASP.NET Security Model As you’ve seen in previous chapters, web requests are fielded first by the IIS web server, which examines the file type. If the file type is registered to ASP.NET, the web server passes the request to ASP.NET. Figure 20-1 shows how these levels interact.

C HA PT ER 20  SEC URIT Y FUNDA MENTA L S

Figure 20-1. IIS and ASP.NET interaction You can apply security at several places in this chain. First, consider the process for an ordinary (non-ASP.NET) web page request: 1. IIS attempts to authenticate the user. Generally, IIS allows requests from all anonymous users and automatically logs them in under the IUSR_[ComputerName] account. IIS security settings are configured on a per-directory basis. (On Windows Vista, this account is simply named IUSR.) 2. If IIS authenticates the user successfully, it attempts to send the user the appropriate HTML file. The operating system performs its own security checks to verify that the authenticated user (typically IUSR) is allowed access to the specified file and directory. An ASP.NET request requires several additional steps (as shown in Figure 20-2). The first and last steps are similar, but the process has intermediary layers:

693

694

C HA PT ER 20  SEC URIT Y FUNDA MENTA L S

Figure 20-2. Authenticating a request

C HA PT ER 20  SEC URIT Y FUNDA MENTA L S

1. IIS attempts to authenticate the user. Generally, IIS allows requests from all anonymous users and automatically logs them in under the IUSR account. 2. If IIS authenticates the user successfully, it passes the request to ASP.NET with additional information about the authenticated user. ASP.NET can then use its own security services, depending on the settings in the web.config file and the page that was requested. 3. If ASP.NET authenticates the user, it allows requests to the .aspx page or .asmx web service. Your code can perform additional custom security checks (for example, manually asking for another password before allowing a specific operation). 4. When the ASP.NET code requests resources (for example, tries to open a file or connect to a database), the operating system performs its own security checks. In a live website, ASP.NET code runs under a fixed account. This account is defined in the machine.config file (if you’re running IIS 5) or in IIS Manager (if you’re running IIS 6 or IIS 7). As your code performs various actions, Windows checks to make sure the account has the required permissions. One important and easily missed concept is that the ASP.NET code doesn’t run under the IUSR account, even if you’re using anonymous user access. The reason is the IUSR account doesn’t have sufficient privileges for ASP.NET code, which needs to be able to create and delete temporary files in order to manage the compilation process. Instead, the ASP.NET account is set through the machine.config file (if you’re using IIS 5) or the application pool identity (under IIS 6 and IIS 7), as described in Chapter 9. When designing ASP.NET pages, you must keep this in mind and ensure your program can’t be used to make dangerous modifications or delete important files.

Note There is one exception to the rules set out in this section. If you enable impersonation (which is described at the end of this chapter), ASP.NET runs all code under the account of an authenticated user. Impersonation is rarely used, because it forces you to grant additional permissions to all users so that ASP.NET can run properly and compile code.

RESTRICTED FILE TYPES ASP.NET automatically provides a basic level of security by blocking requests for certain file types (such as configuration and source code files). To accomplish this, ASP.NET registers the file types with IIS but specifically assigns them to the HttpForbiddenHandler class. This class has a single role in life—it denies every request it receives. ASP.NET uses this technique to block access to source code files, Visual Studio project files, and other resources. Some of the restricted file types include the following:

695

696

C HA PT ER 20  SEC URIT Y FUNDA MENTA L S

.asax .ascx .config .vb .vbproj .cs .csproj .resx .resources To see the full list, refer to the web.config.default file in the c:\Windows\Microsoft.NET\Framework\ v2.0.50727\Config folder, and search for the text System.Web.HttpForbiddenHandler.

The Visual Studio Web Server So far, this discussion assumes you’re using IIS, which is what all live ASP.NET websites use. However, IIS isn’t involved when you test a web application using the integrated web server in Visual Studio. Instead, the Visual Studio web server plays the same role. Conceptually, the Visual Studio web server works in the same way as the IIS web server. For example, it handles requests for different types of files (such as HTML pages and ASP.NET web forms) and passes requests on to ASP.NET when required. However, the security model is simplified. Because the Visual Studio web server is designed to be used by one person at a time—the current user of the local computer—it doesn’t support anonymous access. Instead, every time you run the Visual Studio web server it logs you on automatically, using your current Windows identity. As a result, your web page code runs with the permissions of your Windows user account. Typically, this gives your web application code more privileges than it would have in a deployed website, where it’s forced to run under a more limited account.

Authentication and Authorization Two concepts form the basis of any discussion about security: Authentication: This is the process of determining a user’s identity and forcing users to prove they are who they claim to be. Usually, this involves entering credentials (typically a user name and password) into some sort of login page or window. These credentials are then authenticated against the Windows user accounts on a computer, a list of users in a file, or a back-end database. Authorization: Once a user is authenticated, authorization is the process of determining whether that user has sufficient permissions to perform a given action (such as viewing a page or retrieving information from a database). Windows imposes some authorization checks (for example, when you open a file), but your code will probably want to impose its own checks (for example, when a user performs a task in your web application such as submitting an order, assigning a project, or giving a promotion).

C HA PT ER 20  SEC URIT Y FUNDA MENTA L S

Authentication and authorization are the two cornerstones of creating a secure userbased site. The Windows operating system provides a good analogy. When you first boot up your computer, you supply a user ID and password, thereby authenticating yourself to the system. After that point, every time you interact with a restricted resource (such as a file, database, registry key, and so on), Windows quietly performs authorization checks to ensure your user account has the necessary rights. You can use two types of authentication to secure an ASP.NET website: Forms authentication: With forms authentication, IIS is configured to allow anonymous users (which is its default setting). However, you use ASP.NET’s forms authentication model to secure parts of your site. This allows you to create a subscription site or e-commerce store. You can manage the login process easily, and write your own login code for authenticating users against a database or simple user account list. Windows authentication: With Windows authentication, IIS forces every user to log in as a Windows user. (Depending on the specific configuration you use, this login process may take place automatically, as it does in the Visual Studio test web server, or it may require that the user type a name and password into a Login dialog box.) This system requires that all users have Windows user accounts on the server (although users could share accounts). This scenario is poorly suited for a public web application but is often ideal with an intranet or company-specific site designed to provide resources for a limited set of users. You’ll concentrate on these two approaches in this chapter. First, you’ll explore the forms authentication model, which is perfect for publicly accessible websites. Then, you’ll consider Windows authentication, which makes sense in smaller network environments where you have a group of known users.

Forms Authentication In traditional ASP programming developers often had to create their own security systems. A common approach was to insert a little snippet of code at the beginning of every secure page. This code would check for the existence of a custom cookie. If the cookie didn’t exist, the user would be redirected to a login page, where the cookie would be created after a successful login. ASP.NET uses the same approach in its forms authentication model. You are still responsible for creating the login page (although you can use a set of specially designed controls to help you, as described in Chapter 21). However, you don’t need to create the security cookie manually, or check for it in secure pages, because ASP.NET handles these tasks automatically. You also benefit from ASP.NET’s support for sophisticated validation algorithms, which make it all but impossible for users to spoof their own cookies or try other hacking tricks to fool your application into giving them access. Figure 20-3 shows a simplified security diagram of the forms authentication model in ASP.NET.

697

698

C HA PT ER 20  SEC URIT Y FUNDA MENTA L S

Figure 20-3. ASP.NET forms authentication To implement forms-based security, you need to follow three steps: 1. Set the authentication mode to forms authentication in the web.config file (or use the WAT). 2. Restrict anonymous users from a specific page or directory in your application. 3. Create the login page. You’ll walk through these steps in the following sections.

C HA PT ER 20  SEC URIT Y FUNDA MENTA L S

Web.config Settings You define the type of security in the web.config file by using the tag. The following example configures the application to use forms authentication by using the tag. It also sets several of the most important settings using a nested tag. Namely, it sets the name of the security cookie, the length of time it will be considered valid (in minutes), and the page that allows the user to log in.

...



...

Table 20-1 describes these settings. They all supply default values, so you don’t need to set them explicitly. For a complete list of supported attributes, consult the Visual Studio Help. Table 20-1. Forms Authentication Settings

Attribute

Description

name

The name of the HTTP cookie to use for authentication (defaults to .ASPXAUTH). If multiple applications are running on the same web server, you should give each application’s security cookie a unique name.

loginUrl

Your custom login page, where the user is redirected if no valid authentication cookie is found. The default value is Login.aspx.

protection

The type of encryption and validation used for the security cookie (can be All, None, Encryption, or Validation). Validation ensures the cookie isn’t changed during transit, and encryption (typically Triple-DES) is used to encode its contents. The default value is All.

timeout

The number of minutes before the cookie expires. ASP.NET will refresh the cookie when it receives a request, as long as half of the cookie’s lifetime has expired. The default value is 30.

path

The path for cookies issued by the application. The default value (/) is recommended, because case mismatches can prevent the cookie from being sent with a request.

Authorization Rules If you make these changes to an application’s web.config file and request a page, you’ll notice that nothing unusual happens, and the web page is served in the normal way. This is because even though you have enabled forms authentication for your application, you have not

699

700

C HA PT ER 20  SEC URIT Y FUNDA MENTA L S

restricted anonymous users. In other words, you’ve chosen the system you want to use for authentication, but at the moment none of your pages needs authentication. To control who can and can’t access your website, you need to add access control rules to the section of your web.config file. Here’s an example that duplicates the default behavior:

...





...

The asterisk (*) is a wildcard character that explicitly permits all users to use the application, even those who haven’t been authenticated. Even if you don’t include this line in your application’s web.config file, this is still the behavior you’ll see, because the default settings inherited from the machine.config file allow all users. To change this behavior, you need to explicitly add a more restrictive rule, as shown here:

The question mark (?) is a wildcard character that matches all anonymous users. By including this rule in your web.config file, you specify that anonymous users are not allowed. Every user must be authenticated, and every user request will require the security cookie. If you request a page in the application directory now, ASP.NET will detect that the request isn’t authenticated and attempt to redirect the request to the login page (which will probably cause an error, unless you’ve already created this file). Now consider what happens if you add more than one rule to the authorization section:



When evaluating rules, ASP.NET scans through the list from top to bottom and then continues with the settings in any .config file inherited from a parent directory, ending with the settings in the base machine.config file. As soon as it finds an applicable rule, it stops its search. Thus, in the previous case, it will determine that the rule applies to the current request and will not evaluate the second line. This means these rules will allow all users, including anonymous users.

C HA PT ER 20  SEC URIT Y FUNDA MENTA L S

But consider what happens if these two lines are reversed:



Now these rules will deny anonymous users (by matching the first rule) and allow all other users (by matching the second rule).

Controlling Access to Specific Directories A common application design is to place files that require authentication in a separate directory. With ASP.NET configuration files, this approach is easy. Just leave the default settings in the normal parent directory, and add a web.config file that specifies stricter settings in the secured directory. This web.config simply needs to deny anonymous users (all other settings and configuration sections can be omitted).





Note You cannot change the tag settings in the web.config file of a subdirectory in your application. Instead, all the directories in the application must use the same authentication system. However, each directory can have its own authorization rules.

Controlling Access to Specific Files Generally, setting file a...