What You Must Know

Before you begin securing your Web applications and Web services, there are overarching considerations and details of which you should be aware.

ASP.NET Process Model

In Microsoft Windows 2000, Internet Information Services (IIS) 5.0 runs all Web applications and Web services in the ASP.NET worker process (Aspnet_wp.exe). The unit of isolation is the application domain and each virtual directory has its own application domain. Process-level configuration settings are maintained by the <processModel> element in Machine.config.

In Microsoft Windows Server 2003, IIS 6.0 application pools allow you to isolate applications using separate processes. For more information, see Chapter 20, "Hosting Multiple ASP.NET Applications."

ASP.NET Account

The ASPNET account is a least privileged, local account created when you install the .NET Framework. By default, it runs the ASP.NET worker process and the ASP.NET state service.

If you decide to run Web applications using a custom account, make sure you configure the account with minimum privileges. This reduces the risks associated with an attacker who manages to execute code using the application's security context. You must also specify the account's credentials on the <processModel> element. Make sure you do not store credentials in plaintext. Instead, use the Aspnet_setreg.exe tool to store encrypted credentials in the registry. The custom account must also be granted the appropriate NTFS permissions.

Aspnet_setreg.exe and Process, Session, and Identity

Aspnet_setreg.exe allows you to store credentials and connection strings in encrypted format in the registry. This tool allows you to encrypt the following attributes:

• <processModel userName = password= />

• <identity username = password= />

• <sessionState sqlConnectionString = stateConnectionString= />

The following example shows the <processModel> element with a custom account both before and after running Aspnet_setreg.exe to secure the credentials:

 <!--Before--> <processModel userName="CustomAccount" password="Str0ngPassword" /> <!--After--> <processModel  userName="registry:HKLM\SOFTWARE\YourApp\process\ASPNET_SETREG,userName"  password="registry:HKLM\SOFTWARE\YourApp\process\ASPNET_SETREG,password"/> 

You can choose the registry location that stores the encrypted data, although it must be beneath HKEY_LOCAL_MACHINE. In addition to encrypting the data using the Data Protection API (DPAPI) and storing it in the registry, the tool applies a secure ACL to restrict access to the registry key. The ACL on the registry key grants Full Control to System, Administrators, and Creator Owner. If you use the tool to encrypt the credentials for the <identity> element or the connection string for the <sessionState> element, you must also grant read access to the ASP.NET process account.

To obtain the Aspnet_setreg.exe tool and for more information, see Microsoft Knowledge Base article 329290, "How To: Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings."

Impersonation is Not the Default

By default, ASP.NET applications do not impersonate. As a result, resource access is performed using the ASP.NET worker process identity. You must grant the process identity read access (at minimum) to the Windows resources that your application requires access to by creating an appropriately configured ACL.

If you do enable impersonation, you can either impersonate the original caller that is, the IIS authenticated identity or a fixed identity specified on the <identity> element. For more information, see "Impersonation" later in this chapter.

Generally, ASP.NET applications do not use impersonation because it can negatively affect design, implementation, and scalability. For example, using impersonation prevents effective middle- tier connection pooling, which limits application scalability. Impersonation might make sense in specific scenarios, for example, when the application uses the anonymous user account's security context for resource access. This is a common technique often used when multiple applications are hosted on the same server. For more information, see Chapter 20, "Hosting Multiple Web Applications."

HttpForbiddenHandler, Urlscan, and the 404.dll

There are a number of techniques you can use to prevent access to restricted resources. ASP.NET provides the HttpForbiddenHandler to which you can map ASP.NET file types that should not be downloadable over HTTP. Mappings are applied using the <httpHandlers> element.

IISLockdown.exe provides the 404.dll. Using this, you can configure IIS to map unwanted file extensions to the 404.dll, which results in the "HTTP 404 - File not found" message when the file type is requested .

Finally, the URLScan ISAPI filter can be used to block requests for restricted file types and program executables. URLScan ships with the IISLockdown tool, although it can be obtained separately. For more information, see Microsoft Knowledge Base article 307608, " INFO : Availability of URLScan Version 2.5 Security Tool," and "How To: Use URLScan" in the "How To" section of this guide.

For more information about IISLockdown and URLScan, see Chapter 16, "Securing Your Web Server."

AppSettings

The <appSettings> element in Web.config allows applications to store configuration data, such as database connection strings or service account credentials. The advantage of this element is that it allows developers to centralize and standardize the storage and retrieval of configuration data. A single location in Web.config also eases administration and deployment.

Sensitive data, such as connection strings and credentials, should not be stored in plaintext format in configuration files. Instead, the developer should use DPAPI to encrypt secrets prior to storage.

For more information about AppSettings, see the "AppSettings in ASP.NET" show on MSDN TV at http://msdn.microsoft.com/msdntv .