Isolating Applications by Identity | Improving Web Application Security: Threats and Countermeasures

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

Task 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.

Create new anonymous user accounts, one per application.

For more information about creating an anonymous user account, see the "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.
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."

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

Start Internet Services Manager from the Administrative Tools program group .
Select the application's application directory, right-click and then click Properties .
Click the Security tab and then click the Edit button.
Ensure Anonymous access is selected and click Edit .
Enter the user name for the anonymous account that you have created, or click Browse to select the user name from a list.
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.

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.

Task 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.

Create new anonymous user accounts, one per application.

For more information about creating an anonymous user account, see the "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.
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."

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. 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"/>

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.