Chapter 20 – Hosting Multiple Web Applications

 

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Improving Web Application Security: Threats and Countermeasures

J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan
Microsoft Corporation

Published: June 2003

Last Revised: January 2006

Applies to:

• ASP.NET version 1.1
• ASP.NET version 2.0
• Microsoft Windows® 2000 operating system
• Microsoft® Windows Server™ 2003 operating system

See the "patterns & practices Security Guidance for Applications Index" for links to additional security resources.

See the Landing Page for the starting point and a complete overview of Improving Web Application Security: Threats and Countermeasures.

Summary: This chapter shows you how to secure ASP.NET applications in hosting scenarios, where multiple applications are hosted by the same Web server. Hosting scenarios for Windows 2000 and Windows Server 2003 are covered. The chapter explains a number of techniques to provide application isolation. This includes the use of multiple identities, IIS6 application pools on Windows Server 2003 and using .NET code access security to constrain applications and enforce isolation.

Contents

In This Chapter
Overview
ASP.NET Architecture on Windows 2000
ASP.NET Architecture on Windows Server 2003
Isolating Applications by Identity
Isolating Applications with Application Pools
Isolating Applications with Code Access Security
Forms Authentication Issues
UNC Share Hosting
Summary

In This Chapter

• Using multiple identities for application isolation
• Using Microsoft Windows Server 2003 application pools for application isolation
• Using code access security for application Isolation

Overview

If you host multiple ASP.NET Web applications on a shared Web server, you need to consider application isolation. For example, how can you ensure that individual applications will not affect one another at runtime? How can you prevent a single rogue or badly written application from consuming critical system level resources on the server that keeps other applications from running properly?

The issue is particularly significant for Internet Service Providers (ISPs) who host large numbers of applications from different companies. In a hosting scenario, it is essential to ensure that the installation of a new application cannot adversely impact the operation of existing applications.

There are a number of ways in which application isolation can be achieved. The available options vary depending on the version of the .NET Framework and the version of the operating system that you run on the Web server. If you are running .NET Framework version 1.1 or 2.0, you can use the resource constraint model provided by code access security to provide one level of application isolation. This application isolation is achieved by restricting an application from to access different types of resources such as the file system, registry, event log, Active Directory, databases, network resources, and so on.

In addition, Windows Server 2003 provides process isolation through Internet Information Services 6.0 (IIS 6) application pools that enable multiple applications to run in separate IIS worker process instances. Process isolation is not possible on Windows 2000 because all Web applications run in a single instance of the ASP.NET worker process, with application domains providing isolation.

The Table 20.1 summarizes the various options for application isolation that are available on Windows 2000 and Windows Server 2003.

Table 20.1   Application Isolation Features for Windows 2000 and Windows Server 2003

Isolation Feature	Windows 2000	Windows Server 2003
Process isolation	No	Yes (IIS 6 App Pools)
Application domain isolation	Yes	Yes
Multiple thread identities	Yes	Yes
Code access security resource constraint	Yes (.NET Framework versions 1.1 and 2.0 (on Windows 2000 SP3))	Yes (.NET Framework version 1.1 and 2.0)

Windows Server 2003 running .NET Framework 1.1 or 2.0 is the recommended platform for hosting multiple ASP.NET applications because it supports process isolation and provides the richest range of options for application isolation.

ASP.NET Architecture on Windows 2000

On Windows 2000, multiple Web applications run in a single instance of the ASP.NET worker process (Aspnet_wp.exe). Each application resides in its own application domain that provides a degree of isolation for managed code. The Windows 2000/IIS 5 architecture is shown in Figure 20.1.

Figure 20.1

ASP.NET architecture on Windows 2000 with IIS 5

The components of the architecture depicted by Figure 20.1 are summarized in Table 20.2.

Table 20.2   Components of the Windows 2000 ASP.NET Architecture

Component	Description
Inetinfo.exe	The main IIS process. A Windows service that runs under the local SYSTEM account.
Aspnet_isapi.dll	IIS script mappings associate ASP.NET file types with this ASP.NET ISAPI extension that runs inside Inetinfo.exe. It is responsible for forwarding requests to the ASP.NET worker process through an asynchronous named pipe. It also starts the worker process and performs health monitoring. The ISAPI extension contains no managed code and performs no request processing itself.
Aspnet_filter.dll	A lightweight ISAPI filter used only to support cookie-less session state for ASP.NET applications. Runs inside Inetinfo.exe.
Aspnet_wp.exe	The ASP.NET worker process. Hosts multiple Web applications in separate application domains that are used to provide isolation. Generally one instance per server, although on multi-processor servers, a Web garden mode supports multiple identical processes with an affinity for a given processor. It is not possible to separate specific Web applications into different processes. This requires IIS 6 and Windows Server 2003. Aspnet_wp.exe runs under the local ASPNET account, although a custom account can be used.
Aspnet_state.exe	An optional Windows service used to store session state for ASP.NET applications. It can run on the Web server or on a remote machine (required for Web farm scenarios). It runs under the local ASPNET account, although a custom account can be used, configured via the Services snap-in.

ASP.NET Architecture on Windows Server 2003

On Windows Server 2003, the architecture changes because IIS 6 allows multiple processes to be used to host separate Web applications. This is shown in Figure 20.2.

Note   IIS 6 supports a backwards compatibility mode that, in turn, supports the IIS 5 ASP.NET worker process model.

Figure 20.2

ASP.NET architecture on Windows Server 2003 with IIS 6

Compared to the ASP.NET architecture under Windows 2000, the primary difference in Windows Server 2003 is that separate IIS worker process instances (W3wp.exe) can be used to host Web applications. By default, these run using the NT Authority\NetworkService account, which is a least privileged local account that acts as the computer account over the network. A Web application that runs in the context of the Network Service account presents the computer's credentials to remote servers for authentication.

Configuring ACLs for Network Service

Configuring an access control list (ACL) for the Network Service account varies for local and remote machines. If you want to grant access to the Network Service account on the local machine, add the Network Service account to an ACL. If you want to grant access to the Network Service account on a remote machine, add the DomainName\MachineName$ account to an ACL.

Note   Do not confuse the Network Service account with the Network built-in group, which includes users who were authenticated across the network.

The main components of the architecture depicted by Figure 20.2 are summarized in Table 20.3.

Table 20.3   Components of the Windows Server 2003 ASP.NET Architecture

Component	Description
Aspnet_isapi.dll	Queues requests for processing by the managed code ASP.NET engine and performs health monitoring.
Aspnet_filter.dll	A lightweight ISAPI filter used only to support cookie-less session state for ASP.NET applications. Runs inside W3wp.exe.
W3wp.exe	The IIS worker process that contains the managed code ASP.NET processing engine. The URL space can be arbitrarily divided among different W3wp.exe instances using IIS 6 application pools. A Web garden mode is also supported. Requests are routed to the W3wp.exe process instance directly from Http.sys which runs in kernel mode. By default, the process runs under the Network Service account but can be configured.
Aspnet_state.exe	An optional Windows service used to store session state for ASP.NET applications. It can run on the Web server or on a remote machine (required for Web farm scenarios). Runs under the Network Service account but can be configured using the Services snap-in.

Isolating Applications by Identity

You can isolate ASP.NET Web applications from an operating system identity standpoint by controlling the account identity used to run each application. If each application uses a separate fixed account identity, you can authorize and audit each application separately.

**Note **  If you host an ASP.NET Web application built using the .NET Framework version 1.0, the process account needs appropriate permissions to the root of the current file system drive. For more information, see Microsoft Knowledge Base article 317955, "FIX: 'Failed to Start Monitoring Directory Changes' Error Message When You Browse to an ASP.NET Page."

There are two ways to use separate fixed identities for each application on a shared Web server:

• Anonymous account impersonation
• Fixed identity impersonation

Anonymous Account Impersonation

With anonymous account impersonation, your application impersonates the anonymous account specified by IIS and configured for your application's virtual directory. You can use this approach if your application authenticates users independently of IIS, for example, by using Forms or Microsoft Passport authentication. In these scenarios, you can isolate the application by using a fixed anonymous account. Once the caller is authenticated and roles are checked, the trusted server model can be used for downstream resource access, where the configured anonymous account provides the trusted identity.

To support this approach, the application's virtual directories in IIS must support anonymous access and a separate anonymous account must be configured for each application. The application must then be configured for impersonation. This approach is shown in Figure 20.3. Local and remote resource access assumes the security context of the impersonated anonymous account.

Figure 20.3

Multiple anonymous accounts used for each application

To use multiple anonymous accounts for resource access

This procedure describes how to use multiple anonymous accounts, one per Web application, for resource access to support individual application authorization and auditing.

1. Create new anonymous user accounts, one per application.

   For more information about creating an anonymous user account, see the "Step 5. Accounts" section in Chapter 16, "Securing Your Web Server."

   If you need to access remote resources using the anonymous account, either use a least privileged domain account, or use a local account and create a duplicated local account on the remote server with a matching user name and password.

2. Use <location> tags in Machine.config to configure each Web application for impersonation.

   <location path="Web Site Name/VDirName" allowOverride="false" >
     <system.web>
       <identity impersonate="true" />
     <system.web>
   <location>
   

   The allowOverride="false" setting prevents an individual application from overriding this setting in a Web.config file. For more information about the <location> element, see "Machine.Config and Web.Config Explained" in Chapter 19, "Securing Your ASP.NET Application and Web Services."

3. Use Internet Services Manager to configure each application's virtual directory to use a separate anonymous user account.

   1. Start Internet Services Manager from the Administrative Tools program group.

   2. Select the application's application directory, right-click and then click Properties.

   3. Click the Security tab and then click the Edit button.

   4. Ensure Anonymous access is selected and click Edit.

   5. Enter the user name for the anonymous account that you have created, or click Browse to select the user name from a list.

   6. If you want to use the account to access a remote resource, clear the Allow IIS to Control Password checkbox for the anonymous account.

      If you select Allow IIS to Control Password, the logon session created using the specified anonymous account has NULL network credentials and cannot be used to access network resources where authentication is required. If you clear this checkbox, the logon session is an interactive logon session with network credentials. However, if the account is local to the machine, no other machine on the network can authenticate the account. In this scenario, create a duplicate account on the target remote server.

      Note   The type of logon session created is controlled by the LogonMethod IIS Metabase setting. The default is an interactive logon session, which requires the account to have the "Allow Log on Locally" user privilege.

      The Allow IIS to Control Password option is not available on IIS 6. IIS 6 sets the default LogonMethod to Network Cleartext, which requires the account to have the "Access this computer from the network" user privilege. This allows the account to be authenticated by a network server.

4. Configure NTFS permissions for each account to ensure that each account has access only to the appropriate file system files and folders, and cannot access critical resources such as operating system tools.

   For more information about configuring NTFS permissions for the anonymous account, see Chapter 16, "Securing Your Web Server."

   Note   If you run the IISLockdown wizard, it creates a Web Anonymous Users group. Members of this group are denied access to system directories and tools.

Fixed Identity Impersonation

When you need IIS to authenticate users for your application, for example by using Integrated Windows authentication or certificate authentication, you can use a fixed impersonation identity to execute your ASP.NET application. This scenario is shown in Figure 20.4.

Figure 20.4

Applications impersonate a fixed account and use that to access resources

You can configure individual ASP.NET applications to impersonate a fixed account. The advantage of this configuration is that it can be used with any IIS authentication method, and does not require IIS anonymous authentication.

To use multiple fixed impersonation accounts for resource access

This procedure describes how to use multiple fixed impersonation accounts, one per Web application, for resource access to support individual application authorization and auditing.

1. Create new anonymous user accounts, one per application.

   For more information about creating an anonymous user account, see the "Step 5. Accounts" section in Chapter 16, "Securing Your Web Server."

   If you need access to remote resources using the anonymous account, either use a least privileged domain account, or use a local account and create a duplicated local account on the remote server with a matching user name and password.

2. Store the encrypted account credentials in the registry.

   Run Aspnet_setreg.exe to store the new account's encrypted credentials in the registry. For more information, see Microsoft Knowledge Base article 329290, "How To: Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings."

   Note   If you are running .NET 2.0, you can encrypt the <identity> configuration section by using the Protected Configuration feature. For more information, see "How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI" and "How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA."

3. Configure Web applications for impersonation.

   You can do this in Machine.config or Web.config. To configure multiple applications with different identities, use <location> tags in Machine.config.

   If you are running .NET 1.1, the output of Aspnet_setreg.exe run in the previous step shows you the required format of the userName and password attribute values for the <identity> element. Some examples are shown below.

   <location path="Web Site Name/appvDir1" allowOverride="false" >
     <system.web>
        <identity impersonate="true"
                  userName=
             "registry:HKLM\SOFTWARE\YourApp1\identity\ASPNET_SETREG,userName"
                  password=
             "registry:HKLM\SOFTWARE\YourApp1\identity\ASPNET_SETREG,password"/>
     </system.web>
   </location>
   
   <location path="Web Site Name/appvDir2" allowOverride="false" >
     <system.web>
         <identity impersonate="true"
                   userName=
           "registry:HKLM\SOFTWARE\YourApp2\identity\ASPNET_SETREG,userName"
                   password=
           "registry:HKLM\SOFTWARE\YourApp2\identity\ASPNET_SETREG,password"/>
     </system.web>
   </location>
   

   To configure impersonation at the application level, use an <identity> element in the application's Web.config file as shown below.

   <identity impersonate="true"
      userName="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,userName"
      password="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,password"/>
   

4. Configure NTFS permissions for each account to ensure that each account has access only to the appropriate file system files and folders, and no access to critical resources such as operating system tools.

   For more information about configuring NTFS permissions for the anonymous account, see Chapter 16, "Securing Your Web Server."

Note   On Windows 2000 and the .NET Framework version 1.0, if you impersonate a fixed identity by using the above configuration, you must grant the "Act as part of the operating system" privilege to the ASP.NET process account used to run your Web applications. This is contrary to the principle of least privilege. You are recommended to upgrade to the .NET Framework version 1.1 where this is no longer a requirement.

Note For more information about isolating the applications using application pools, see "How To: Improve Security When Hosting Multiple Applications in ASP.NET 2.0."

Isolating Applications with Application Pools

If your applications run on Windows Server 2003, you can use application pools and configure each application to run in its own worker process that provides process-level isolation. By default, all applications run in a default application pool. With application pools, you can configure each process to run using a separate identity and, as a result, you do not need to use impersonation.

To provide process level isolation

1. Create a set of new Windows accounts, one per application to run each worker process instance.

2. Configure NTFS permissions for each account to ensure that each account only has access to the appropriate file system files and folders, and cannot access critical resources such as operating system tools.

   For more information about configuring NTFS permissions for the anonymous account, see Chapter 16, "Securing Your Web Server."

3. Disable Web application impersonation.

   You can do this in Machine.config or Web.config. To disable impersonation for multiple applications in Machine.config, place <identity> elements inside <location> elements as shown below.

   Use the following configuration. This configuration does not impersonate.

   <location path="Web Site Name/appvDir1" allowOverride="false" >
     <system.web>
        <identity impersonate="false"
     </system.web>
   </location>
   

   Note   ASP.NET applications do not impersonate by default.

4. Create new application pools and configure them to run under the new accounts.

   Use IIS 6 to create new application pools with default settings, and use the accounts created in step 1 to configure the identity of each pool, so that each pool runs using a separate identity.

5. Configure each application to run in its own application pool.

   On the Directory tab of each IIS application, choose the application pool for the application to run in.

Note For more information about isolating the applications using application pools, see "How To: Improve Security When Hosting Multiple Applications in ASP.NET 2.0."

Isolating Applications with Code Access Security

In .NET Framework 1.1 and 2.0, you can configure applications to run at partial trust levels, using the <trust> element. The following configuration shows how to configure an application's trust level from the Machine.config file. In this example, the Medium trust level is used.

<location path="Web Site Name/appvDir1" allowOverride="false">
  <system.web>
    <trust level="Medium" originUrl="" />
  </system.web>
</location>

Note   In ASP.NET, the trust-level setting is in the machine-level Web.config file.

If you configure an application to run with a trust level other than "Full," the application has restricted code access security permissions to access specific types of resources. In this way, you can constrain applications to prevent them from interacting with one another and from gaining access to system level resources such as restricted areas of the file system, the registry, the event log, and so on.

For more information about the ASP.NET trust levels and how they can be used to provide application isolation and about application specific design and development considerations, see Chapter 9, "Using Code Access Security with ASP.NET."

Note   If you use code access security to provide application isolation, you should still consider the operating system identity of the application. The recommended isolation model is to use code access security together with process level isolation on Windows Server 2003.

Forms Authentication Issues

If you use Forms authentication with version 1.0 of the .NET Framework, you should use separate cookie paths and names. If you do not do so, it is possible for a user authenticated in one application to make a request to another application without being redirected to that application's logon page. The URL authorization rules within the second application may deny access to the user, without providing the opportunity to supply logon credentials using the logon form.

To avoid this issue, use unique cookie path and name attributes on the <forms> element for each application, and also use separate machine keys for each application.

Versions 1.1 and 2.0 of the .NET Framework support the IsolateApps setting shown below.

<machineKey validationKey="AutoGenerate,IsolateApps"
            decryptionKey="AutoGenerate,IsolateApps" validation="SHA1"..../>

This ensures that each application on the machine uses a separate key for encryption and validation of Forms authentication cookies and view state.

With version 1.0 of the .NET Framework, you cannot use IsolateApps and you must manually generate <machineKey> elements. For more information about this issue, see the following articles in the Microsoft Knowledge Base.

• 313116, "PRB: Forms Authentication Requests Are Not Directed to loginUrl Page"
• 312906, "How To: Create Keys by Using Visual C# .NET for Use in Forms Authentication"

UNC Share Hosting

If you run an application with its content on a Universal Naming Convention (UNC) share, the credentials used to access the share are either the credentials of the application or of the authenticated client. This is configured in IIS by an administrator.

When an application is configured in this manner, ASP.NET impersonates the security context of the token it receives from IIS. This is not configurable with the <identity> tag unless explicit credentials are provided.

With version 1.0 of the .NET Framework, use Mscorcfg.msc to create a code group based on the URL and to grant it full trust.

When you use a virtual directory that points to a remote share to host an ASP.NET application, you may receive a security exception. For more information, see Microsoft Knowledge Base article 320268, "PRB: System.Security.SecurityException: Security error."

Summary

If you host multiple ASP.NET applications on a single Web server, you need to consider how applications are isolated from one another and from shared system resources such as the file system, registry, and event logs. Without adequate isolation, a rogue or badly developed application can adversely affect other applications on the server.

On Windows Server 2003, use the multiple worker process model supported by IIS 6 to provide operating system process isolation for applications. On Windows 2000, process isolation is not possible, although multiple applications can be configured to use separate anonymous user accounts. This provides separate application auditing and supports independent application authorization.

On both platforms you can use the resource constraint model provided by code access security as an additional control to restrict which applications have access to which resource types. The use of code access security with ASP.NET applications requires .NET Framework 1.1 or 2.0.

For more information about securing ASP.NET applications, see Chapter 19, "Securing Your ASP.NET Applications and Web Services."

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

© Microsoft Corporation. All rights reserved.