Design Considerations

Before you develop Web pages and controls, there are a number of important issues that you should consider at design time. The following are the key considerations:

• Use server-side input validation .

• Partition your Web site .

• Consider the identity that is used for resource access .

• Protect credentials and authentication tickets .

• Fail securely .

• Consider authorization granularity .

• Place Web controls and user controls in separate assemblies .

• Place resource access code in a separate assembly .

Use Server-Side Input Validation

At design time, identify all the various sources of user input that your Web pages and controls process. This includes form fields, query strings, and cookies received from the Web user, as well as data from back-end data sources. The Web user clearly lives outside your application's trust boundary, so all of the input from that source must be validated at the server. Unless you can absolutely trust the data retrieved from back-end data sources, that data should also be validated and sanitized before it is sent to the client. Make sure your solution does not rely on client-side validation because this is easily bypassed.

Partition Your Web Site

Your Web site design should clearly differentiate between publicly accessible areas and restricted areas that require authenticated access. Use separate subdirectories beneath your application's virtual root directory to maintain restricted pages, such as checkout functionality in a classic e-commerce Web site that requires authenticated access and transmits sensitive data such as credit card numbers . Separate subdirectories allow you to apply additional security (for example, by requiring SSL) without incurring SSL performance overhead across the entire site. It also allows you to mitigate the risk of session hijacking by restricting the transmission of authentication cookies to HTTPS connections. Figure 10.2 shows a typical partitioning.

Figure 10.2: A Web site partitioned into public and secure areas

Note that in Figure 10.2, the restricted subfolder is configured in Internet Information Services (IIS) to require SSL access. The first <authorization> element in Web.config allows all users to access the public area, while the second element prevents unauthenticated users from accessing the contents of the secured subfolder and forces a login.

For more information about restricting authentication cookies so that they are passed only over HTTPS connections and about how to navigate between restricted and nonrestricted pages, see "Use Absolute URLs for Navigation" in the "Authentication" section of this chapter.

Consider the Identity That Is Used for Resource Access

By default, ASP.NET applications do not impersonate, and the least privileged ASPNET process account is used to run ASP.NET Web applications and for resource access. The default is the recommended configuration. There are several situations in which you may want to use a different Windows security context for resource access. These include:

• Hosting multiple applications on the same server

  You can use IIS to configure each application to use a separate anonymous Internet user account and then enable impersonation. Each application then has a distinct identity for resource access. For more information about this approach, see Chapter 20, "Hosting Multiple Web Applications."

• Accessing a remote resource with specific authentication requirements

  If you need to access a specific remote resource (for example, a file share) and have been given a particular Windows account to use, you can use configure this account as the anonymous Web user account for your application. Then you can use programmatic impersonation prior to accessing the specific remote resource. For more information, see "Impersonation" later in this chapter.

Protect Credentials and Authentication Tickets

Your design should factor in how to protect credentials and authentication tickets. Credentials need to be secured if they are passed across the network and while they are in persistent stores such as configuration files. Authentication tickets must be secured over the network because they are vulnerable to hijacking. Encryption provides a solution. SSL or IPSec can be used to protect credentials and tickets over the network and DPAPI provides a good solution for encrypting credentials in configuration files.

Fail Securely

If your application fails with an unrecoverable exception condition, make sure that it fails securely and does not leave the system wide open . Make sure the exception details that are valuable to a malicious user are not allowed to propagate to the client and that generic error pages are returned instead. Plan to handle errors using structured exception handling, rather than relying on method error codes.

Consider Authorization Granularity

Consider the authorization granularity that you use in the authenticated parts of your site. If you have configured a directory to require authentication, should all users have equal access to the pages in that directory? If necessary, you can apply different authorization rules for separate pages based on the identity, or more commonly, the role membership of the caller, by using multiple <authorization> elements within separate <location> elements.

For example, two pages in the same directory can have different <allow> and <deny> elements in Web.config.

Place Web Controls and User Controls in Separate Assemblies

When Web controls and user controls are put in their own assemblies, you can configure security for each assembly independently by using code access security policy. This provides additional flexibility for the administrator and it means that you are not forced to grant extended permissions to all controls just to satisfy the requirements of a single control.

Place Resource Access Code in a Separate Assembly

Use separate assemblies and call them from your page classes rather than embedding resource access code in your page class event handlers. This provides greater flexibility for code access security policy and is particularly important for building partial-trust Web applications. For more information, see Chapter 9, "Using Code Access Security with ASP.NET."