Security Changes in IIS 7.0

IIS 7.0 builds on the security focus established in its predecessor, IIS 6.0. As a result, the overwhelming majority of the core security principles and features established in IIS 6.0 are still in use today. However, IIS 7.0 does introduce improvements to help enhance the security of the Web server:

• The anonymous user configured by default for anonymous authentication is the new built-in IUSR account. This account is built in and does not require a password that needs to be renewed and synchronized between servers. Additionally, permissions set for IUSR accounts are effective when copied to another IIS 7.0 server because the IUSR account has a well-known Security Identifier (SID) that is the same on every computer. For more information, see the section titled "Anonymous Authentication" later in this chapter.
• The IIS_WPG group has been replaced with the built-in IIS_IUSRS group. This group is built in and enables permissions set for IIS_IUSRS to remain effective when copied to another IIS 7.0 server because it has a well-known Security Identifier (SID). In addition, this SID is automatically injected into the worker process token for each IIS worker process, eliminating the need for manual group membership for any custom application pool identities. For more information, see the section titled "Set NTFS Permissions to Grant Minimal Access" later in this chapter.
• Anonymous authentication can be configured to use the application pool identity. This enables the content to require permissions only for the application pool identity when using anonymous authentication, simplifying permission management. For more information, see the section titled "Set NTFS Permissions to Grant Minimal Access" later in this chapter.
• IIS worker processes automatically receive a unique application pool Security Identifier (SID) that you can use to grant access to the specific application pool to enable application isolation. For more information, see the section titled "Isolating Applications" later in this chapter.
• Configuration isolation automatically isolates server-level configuration for each application pool. The global server-level configuration contained in applicationHost.config is automatically isolated by creating filtered copies of this configuration for each application pool and preventing other applications pools from being able to read this configuration. For more information, see the section titled "Understanding Configuration Isolation" later in this chapter.
• Virtual directories can specify fixed credentials regardless of whether they point to Universal Naming Convention (UNC) shares or a local file system. Unlike IIS 6.0, which supports fixed credentials for specifying access to UNC shares only, IIS 7.0 enables fixed credentials to be used for any virtual directory.
• Windows Authentication is performed in the kernel by default. This improves the configurability of the Kerberos protocol on the server. It also improves the performance of Windows Authentication. However, it may affect some applications that have custom clients that presend authentication credentials on the first request. This behavior can be turned off in the configuration. For more information, see the section titled "Windows Authentication" later in this chapter.
• The new Request Filtering feature provides extended URL Scan functionality. You can use the new Request Filtering feature to protect your Web server against nonstandard or malicious request patterns and additionally protect specific resources and directories from being accessed. For more information, see the section titled "Request Filtering" later in this chapter.
• The new URL Authorization feature enables applications to control access to resources through configuration-based rules. The new URL Authorization feature provides flexible configuration-based rules to control access to application resources in terms of users and roles, and it supports the use of the ASP.NET Roles service. For more information, see the section titled "URL Authorization" later in this chapter.

Additionally, IIS 7.0 introduces several changes to existing security features and removes several deprecated security features that could impact your application. These changes to security-related features are listed here:

• IIS 6.0 Digest Authentication is no longer supported. It is being replaced by Advanced Digest Authentication (now simply referred to as Digest Authentication), which does not require the application pool to run with LocalSystem privileges. See the section titled "Digest Authentication" later in this chapter for more information.
• .NET Passport Authentication is no longer supported. The .NET Passport Authentication support is not included in Windows Vista and Windows Server 2008, and therefore IIS 7.0 does not support it.
• IIS 6.0 URL Authorization is no longer supported. The IIS 6.0 URL Authorization was overly complex and not often used. It has been replaced by the new configuration-based URL Authorization feature. See the section titled "URL Authorization" later in this chapter for more information.
• IIS 6.0 Sub-Authentication is no longer supported. The Sub-Authentication feature enabled IIS 6.0 Digest Authentication (which has been removed) and synchronized anonymous account passwords (the anonymous account now uses the new built-in IUSR account that does not have a password). It is no longer needed in IIS 7.0 and therefore has been retired.
• IIS Manager no longer provides support for configuring IIS Client Certificate Mapping Authentication. You can edit the configuration directly, use Appcmd from the command line, or use another configuration application programming interface (API) to configure this feature. For more information, see the section titled "IIS Client Certificate Mapping Authentication" later in this chapter.
• Several authentication and impersonation differences exist in ASP.NET applications when running in the default Integrated mode. This includes an inability to use both Forms authentication and an IIS authentication method simultaneously, and an inability to impersonate the authenticated user in certain stages of request processing. For more information on security changes impacting ASP.NET applications, see the list of breaking changes at https://mvolo.com/blogs/serverside/archive/2007/12/08/IIS-7.0-Breaking-Changes-ASP.NET-2.0-applications-Integrated-mode.aspx.
• Metabase access control lists (ACLs) are no longer supported. With the new configuration system, you cannot set permissions on individual configuration settings. IIS 7.0 provides built-in support for delegating configuration settings to Web site and application owners, replacing metabase ACLs as a mechanism for configuration delegation. For more information, see the section titled "Controlling Configuration Delegation" later in this chapter.
• Metabase auditing is no longer supported. The ability to audit changes to specific configuration settings is not supported out of the box. This is a consequence of IIS 7.0 not supporting metabase ACLs.

Reducing Attack Surface Area

Reducing the attack surface area of the Web server is a key strategy in reducing the risk of a security vulnerability being successfully exploited by an attacker. The principle of attack surface area reduction is not exclusive to Web servers—it is generally accepted as one of the most direct ways to improve the security of any software system. When applied to IIS 7.0, it provides the following benefits:

• It directly reduces the number of features and services exposed by the Web server to outside clients, minimizing the amount of code available for an attacker to exploit.
• It reduces complexity, which makes it easier to configure the Web server in a secure manner.
• If a vulnerability is exposed, the uptime of the Web server is not affected as much, because if the component affected by the vulnerability is not installed, it is not necessary to take the Web server offline or patch it immediately.

IIS 7.0 gives you an unparalleled ability to reduce the attack surface area of the Web server through its modular architecture by enabling you to remove all functionality other than what is absolutely necessary to host your application. By leveraging this ability, you can deploy low-footprint Web servers with minimal possible surface area.

After installing the minimal set of features, you can further reduce the surface area of the Web server by configuring your application to operate with the minimal functionality, for example, configuring which application resources should be served.

In the rest of this section, we will review the cumulative process for reducing the surface area of the Web server and your application. This process includes the following steps:

1. Reduce the surface area of the Web server.
   • Install the minimal required set of Web server features.
   • Enable only the required Internet Server Application Programming Interface (ISAPI) filters.
   • Enable only the required ISAPI extensions.
   • Enable only the required Common Gateway Interface (CGI) applications.
   • Enable only the required FastCGI applications.
2. Reduce the surface area of the application.
   • Enable only the required modules.
   • Configure the minimal set of application handler mappings.
   • Set Web site permissions.
   • Configure a minimal set of MIME types.

The modular architecture of IIS 7.0 gives you the ability to install only the Web server features required for the correct operation of your Web server. This forms the foundation of the surface area reduction strategy.

In addition, you can continue to control what extensions that do not use the IIS 7.0 modular extensibility model can execute on the server. This includes ISAPI extensions and filters and CGI and FastCGI programs.

Installing the Minimal Required Set of Web Server Features

The IIS 7.0 modular feature set comprises more than 40 individual Web server modules that provide various request processing and application services. The Web server core engine retains only the minimal set of functionality needed to receive the request and dispatch its processing to modules. You can leverage this architecture to deploy minimal surface area Web servers by installing only the modules that are required for the Web server's operation.

The modular feature set provided in IIS 7.0 is fully integrated with Windows Setup. This means that you can install or uninstall most of the IIS 7.0 modules by installing IIS 7.0 features directly from the Turn Windows Features On Or Off page in Windows Vista, or the Web Server (IIS) role in Server Manager on Windows Server 2008 as shown in Figure 14-1. Each feature typically corresponds to one module (or in some cases several modules) and installs any corresponding configuration information as well as feature dependencies.

The default installation of IIS 7.0 includes only the features necessary for IIS 7.0 to function as a static file Web server. In many cases, this may not be sufficient to properly host your application, so you will need to install additional features, including support for hosting dynamic application technologies. When you do this, you will be prompted to install any dependencies of the feature you are installing and configure the proper default configuration for that feature.

Figure 14-1 Installing IIS 7.0 using the Add Roles Wizard.

Caution Do not install all the IIS 7.0 features if you are unsure of what you need. Doing so can unnecessarily increase the surface area of the Web server.

By ensuring that only the required modules are installed, you can significantly reduce the surface area of the Web server. This provides the following benefits:

• Removes the potential for an attacker to exploit known or future threats in features that are not installed.
• Reduces management complexity, making it easier to configure the server in a secure manner.
• Reduces the downtime and costs associated with reacting to a vulnerability or applying patches. If the patched component is not installed, you do not need to take the server offline to perform the patch. You can also perform patching on your own schedule instead of being forced to perform it immediately if a vulnerability is found.

Note When you apply a patch to a component of a Web server feature that is not installed, it is stored in the operating system installation cache. This way, when you install the feature in the future, it will use the patched version automatically. Therefore, be sure to continue installing all operating system updates, even if the corresponding features are not currently being used on the server.

To reduce the surface area of the Web server, you should take the following steps:

1. Determine the set of features your applications need. In the majority of cases, you should be able to tell what features are required by your application by reviewing the list of setup components and comparing it with your application's requirements. As a guide, you can often use the recommended set of modules for specific application workloads. You can find more information on recommended installation workloads at https://www.iis.net/articles/view.aspx/IIS7/Deploy-an-IIS7-Server/Installing-IIS7/Install-Typical-IIS-Workloads?Page=2. You should exercise caution when removing Web server features that are security sensitive, because doing so may have a negative impact on your server's security. To review the list of modules that have a security impact, see the section titled "Taking Advantage of Componentization to Reduce the Security Surface Area of the Server" in Chapter 12, "Managing Web Server Modules."
2. Install only the required features. After you have determined the required features, you should install them using the roles or features wizards. For more information on the options for installing IIS 7.0 features, see Chapter 5, "Installing IIS 7.0." When in doubt, do not install all features, because doing so will result in an unnecessary surface area increase.
3. Install only the required third-party modules. IIS 7.0 applications may require third-party modules to be installed to add additional functionality or replace a built-in IIS 7.0 feature. You should exercise caution when installing any module on the Web server and make sure that you trust its source. Installing untrusted or buggy modules can compromise the security of the Web server or negatively affect its reliability and performance. For information about installing third-party modules, see Chapter 12.
4. Test your application. You should always test your application to ensure that it operates correctly given the installed feature set. Your application may experience errors if a required module is not installed. The symptoms of this error will depend on the service provided by the missing module. If your testing shows an error and you believe that it is due to a missing feature, make sure that the error is removed or changed by installing that specific feature. If the error remains, uninstall the feature and try again. Never blindly install multiple or all features to get the application to work.

When you run multiple applications on the same Web server, you will need to install the superset of the modules required by each application. You can then further reduce the surface area of each application by controlling which modules are enabled at the application level. We will review how to do this in the section titled "Enabling Only the Required Modules" later in this chapter.

For more information on using the roles or features wizards to install IIS 7.0 features and other available features, see Chapter 5. For more information on installing and enabling modules, including third-party modules, see Chapter 12.

Enabling Only the Required ISAPI Filters

IIS 6.0 provides support for ISAPI filters, to allow third parties to extend IIS request processing. IIS 7.0 replaces ISAPI filters with IIS 7.0 modules as the preferred mechanism for extending the Web server. However, IIS 7.0 continues to support ISAPI filters for backward compatibility reasons.

Note To enable ISAPI filters to work on IIS 7.0, the ISAPI Filters role service must be installed. This role service installs the IsapiFilterModule module, which provides support for hosting ISAPI filters. If this module is removed, ISAPI filters will not be loaded. This role service is not enabled by default; it is however enabled when the ASP.NET role service is installed.

If your Web server uses ISAPI filters, to minimize the Web server surface area you should ensure that only the required ISAPI filters are enabled.

Note You must be a server administrator to enable ISAPI filters.

To properly configure ISAPI filters, you should take the following steps:

1. If your Web server uses ISAPI filters, install the ISAPI Filters role service. Without this role service, the ISAPI filters will not be loaded and therefore may create a security risk if they are responsible for security-sensitive functionality.
2. If your Web server does not use ISAPI filters, do not install the ISAPI Filters role service. This eliminates the possibility of unwanted ISAPI filters being configured on your server.
3. Determine the ISAPI filters that your application requires. In the majority of cases, your Web server should not require any ISAPI filters (with the exception of the ASP.NET ISAPI filter; see the note later in this section). Therefore, you will typically need to configure ISAPI filters only if you are migrating an existing application from previous versions of IIS that require specific ISAPI filters, or if you are installing a new third-party ISAPI filter.
4. Enable the required ISAPI filters. You can control which ISAPI filters are enabled on your server, and for a specific Web site, by using IIS Manager.

To use IIS Manager to configure the ISAPI filters, click the Web server node or Web site node in the tree view and then double-click ISAPI Filters, as shown in Figure 14-2. Exercise extreme caution when installing third-party ISAPI filters and be sure you trust their source. Installing untrusted or buggy ISAPI filters can compromise the security of the Web server or negatively affect its reliability.

Figure 14-2 Using IIS Manager to configure ISAPI filters.

Note IIS 7.0 does not install any ISAPI filters by default. However, ASP.NET 1.1 and ASP.NET 2.0 will install an ISAPI filter named ASP.NET_2.0.50727.0. This filter is required for cookie-less ASP.NET features to work properly. You should not remove this filter.

You can also control which filters are enabled for the Web server or for a specific Web site by editing the system.webServer/isapiFilters configuration section directly, with the Appcmd command line tool, or with another configuration API.

Enabling Only the Required ISAPI Extensions

IIS 6.0 provides support for ISAPI extensions, which allows third parties to extend IIS request processing by returning responses for specific content types. IIS 7.0 replaces ISAPI extensions with IIS 7.0 modules as a preferred mechanism for extending IIS. However, IIS 7.0 continues to support ISAPI extensions for backward compatibility reasons.

Note To enable ISAPI extensions to work on IIS 7.0, the ISAPI Extensions role service must be installed. This role service installs the IsapiModule module, which provides support for hosting ISAPI extensions. If this module is removed, ISAPI extensions will not be loaded. This role service is not enabled by default, but it is enabled when ASP.NET is installed.

Today, dynamic application framework technologies frequently use ISAPI extensions to interface with IIS. Therefore, it is likely that if you are using dynamic application technologies, you will need to use ISAPI extensions. For example, both ASP.NET (for Classic mode applications) and ASP are implemented as ISAPI extensions.

If your Web server uses ISAPI extensions, to minimize the Web server surface area you should ensure that only the required ISAPI extensions are enabled.

Note You must be a server administrator to enable ISAPI extensions.

To properly configure ISAPI extensions, you should take the following steps:

1. If your Web server uses ISAPI extensions, install the ISAPI Extensions role service. Without this role service, the ISAPI extensions will not be loaded, and requests to resources mapped to ISAPI extensions will return errors.
2. If your Web server does not use ISAPI extensions, do not install the ISAPI Extensions role service. This eliminates the possibility of unwanted ISAPI extensions being configured on your server.
3. Configure the allowed ISAPI extensions. Each ISAPI extension must be allowed to execute on the server before it can be used. You can use IIS Manager to configure all ISAPI extensions that are allowed to execute on the server. Doing so is explained in more detail later in this section. Exercise extreme caution when allowing third-party ISAPI extensions and be sure you trust their source. Installing untrusted or buggy ISAPI extensions can compromise the security of the Web server or negatively affect its reliability.
4. Configure the desired handler mappings. To use ISAPI extensions, you need to create handler mappings that map allowed ISAPI extensions to specific content types in your application. For more information on creating handler mappings for ISAPI extensions, see Chapter 12. We will discuss securing handler mappings in the section titled "Configuring the Minimal Set of Handler Mappings" later in this chapter.

You must explicitly allow any ISAPI extension that has to execute on your server. When you allow a specific ISAPI extension path, any application on the server can load this extension, if the server configures a handler mapping to this extension. Table 14-1 specifies the common ISAPI extensions and when they are installed.

Table 14-1 Common ISAPI Extensions

On IIS 6.0, you have to explicitly allow the ISAPI extensions corresponding to ASP and ASP.NET 2.0. On IIS 7.0, these ISAPI extensions are automatically allowed when you install the corresponding role services. In addition, only ASP.NET applications running in Classic mode use the ASP.NET 2.0 ISAPI extension. It is a more reliable practice to use the roles or features wizards to control the availability of these features, instead of allowing or not allowing them in the ISAPI and CGI Restrictions. However, you still need to manually enable the ISAPI extension for ASP.NET v1.1.

On IIS 6.0, you can allow an ISAPI extension in the Web Service Extension Restriction List. On IIS 7.0, you can use IIS Manager to do this by clicking the Web server node in the tree view and then double-clicking ISAPI And CGI Restrictions to open the feature shown in Figure 14-3. To add a new ISAPI extension, click Add in the Actions pane and then enter the exact path of the ISAPI extension. If you would like to allow the ISAPI extension to execute, check the Allow Extension Path To Execute check box. You can also allow or deny existing extensions.

Figure 14-3 Allowing ISAPI extensions in the ISAPI and CGI Restrictions by using IIS Manager.

In addition to using IIS Manager, you can also edit the system.webServer/security/isapiCgi-Restriction configuration section directly by using the Appcmd command line tool or with another configuration API. For more information about configuring enabled ISAPI extensions, see the section titled "Adding Entries to the ISAPI CGI Restriction List (Formerly Web Service Restriction List)" in Chapter 12.

Enabling Only the Required CGI Programs

IIS 7.0 continues to support CGI programs as one of the ways to extend the functionality of the Web server.

Note To enable CGI programs to work on IIS 7.0, the CGI role service must be installed. This role service installs the CgiModule module, which provides support for launching CGI programs. If this module is removed, CGI programs will not be usable. This role service is not enabled by default.

By default, IIS 7.0 does not provide any CGI programs, so they should be used only if your application uses third-party CGI programs. If it does, you should ensure that only the required CGI programs are allowed to minimize the Web server surface area.

Note You must be a server administrator to allow CGI programs.

To properly configure CGI programs, you should take the following steps:

1. If your Web server uses CGI programs, install the CGI role service. Without this role service, the CGI programs will not be created, and requests to resources mapped to CGI programs will return errors.
2. If your Web server does not use CGI programs, do not install the CGI role service. This eliminates the possibility of unwanted CGI programs being configured on your server.
3. Configure the allowed CGI programs. Each CGI program must be allowed to execute on the server before it can be used. You can use IIS Manager to configure all CGI programs that are allowed to execute on the server. This is explained in more detail later in this section. Exercise extreme caution when allowing third-party CGI programs and be sure you trust their source. Installing untrusted or buggy CGI programs can compromise the security of the Web server or negatively affect its reliability.
4. Configure the desired handler mappings. To use CGI programs, you need to create handler mappings that map allowed CGI programs to specific content types in your application. For more information on creating handler mappings for CGI programs, see Chapter 12. We will discuss securing handler mappings in the section titled "Configuring the Minimal Set of Handler Mappings" later in this chapter.

Similar to ISAPI extensions, you must explicitly allow any CGI program that has to execute on your server. When you allow a specific CGI program path, this CGI program can now be launched by any application on the server that configures a handler mapping to this CGI program. To be allowed, each allowed CGI program entry must specify the full path and arguments exactly the same way they are specified in each handler mapping. CGI programs are allowed in the ISAPI and CGI Restrictions feature, similar to the process described in the section titled "Enabling Only the Required ISAPI Extensions" earlier in this chapter.

Enabling Only the Required FastCGI Programs

IIS 7.0 supports hosting FastCGI programs by using the FastCGI feature, which provides a more reliable way to host many application frameworks than CGI does.

Note To enable FastCGI programs to work on IIS 7.0, the CGI role service must be installed. This role service installs the FastCgiModule module, which provides support for launching FastCGI programs. If this module is removed, FastCGI programs will not be usable. This role service is not enabled by default.

By default, IIS 7.0 does not provide any FastCGI programs, so they should be used only if your application uses third-party FastCGI programs. If so, to minimize the Web server surface area, you should ensure that only the required FastCGI programs are allowed.

Note You must be a server administrator to allow FastCGI programs.

To properly configure FastCGI programs, you should take the following steps:

1. If your Web server uses FastCGI programs, install the CGI role service. Without this role service, the FastCGI programs will not be usable, and requests to resources mapped to FastCGI programs will return errors.
2. If your Web server does not use FastCGI programs, do not install the CGI role -service. This eliminates the possibility of unwanted FastCGI programs being configured on your server.
3. Configure the allowed FastCGI programs. Each FastCGI program must be allowed to execute on the server before it can be used. Though there is no IIS Manager support for configuring FastCGI programs that are allowed to execute on the server, you can do this by editing the system.webServer/fastCgi configuration section. For more information on configuring FastCGI programs, see Chapter 11, "Hosting Application Development Frameworks." Exercise extreme caution when allowing third-party FastCGI programs and be sure you trust their source. Installing untrusted or buggy FastCGI programs can compromise the security of the Web server or negatively affect its reliability.
4. Configure the desired handler mappings. To use FastCGI programs, you need to create handler mappings that map allowed FastCGI programs to specific content types in your application. For more information on creating handler mappings for FastCGI programs, see Chapter 12. We will discuss securing handler mappings in the section titled "Configuring the Minimal Set of Handler Mappings" later in this chapter.

Unlike ISAPI extensions and CGI programs, FastCGI programs are not allowed through the ISAPI and CGI Restriction feature. Instead, in the system.webServer/fastCgi configuration section, you need to create an entry for each allowed FastCGI program. For more information on configuring FastCGI programs, see Chapter 11.

Reducing the Application's Surface Area

Installing only the required Web server features and locking down the enabled ISAPI extensions, ISAPI filters, and CGI and FastCGI programs is a great way to reduce the surface area of the Web server as a whole. You can take it a step further by reducing the set of functionality available at the application level, by limiting the modules enabled in each application, and by constraining the set of resources that the application is configured to serve.

Enabling Only the Required Modules

When your Web server is configured to run a single dedicated application, you should install only the modules necessary to host this application. However, if your Web server hosts multiple applications, you may need to install a superset of all IIS features and third-party modules that each application requires. In this case, you can further reduce the surface area of each application by disabling at the application level any modules that the application does not need.

To do this, you can configure the set of enabled IIS modules (managed or native) for each application. You can do this by using IIS Manager: select your application node in the tree view, double-click Modules, and remove any modules that are not needed in the application. You can learn more about the process for removing modules in Chapter 12.

Caution Exercise caution when removing modules because removing security-sensitive modules that perform tasks—for example, those that perform authorization—can result in weakening application security. See the section titled "Securing Web Server Modules" in Chapter 12 for information about removing modules and which built-in IIS modules may be security-sensitive.

If you are operating a Web server on which third parties are able to publish application content, be aware that they can by default enable new managed modules that are included with their application to process requests to their application. Likewise, they can disable any module that is installed and enabled at the server level, as long as it is not locked by default. If this is not what you want, you should consider locking the system.webServer/modules configuration section or using fine-grain configuration locking to lock specific modules against being removed. For more information on locking down modules, see the section titled "Locking Down Extensibility" in Chapter 12.

Note It is not possible to add new native modules at the application level. Similarly, it is not possible to remove native modules associated with IIS features at the application level by default because IIS setup locks them at the server level.

Configuring the Minimal Set of Handler Mappings

Handler mappings directly determine what resource types the Web server is configured to serve. They do this by mapping extensions or URL paths to modules or ASP.NET handlers that provide processing for the corresponding resource type. Similar to modules, handler mappings are typically installed at the server level when IIS features or third-party application frameworks are installed. This is done to enable all applications on the server to serve the associated content.

If your application does not serve specific content types or does not use specific application framework technologies installed on the Web server, you should remove the associated handler mapping entries in the system.webServer/handlers configuration section at the application level to prevent the Web server from attempting to use them to satisfy requests to your application. This reduces the risk of unintended script functionality executing in your application, or an application framework specific vulnerability being exploited. Note that the latter may occur even if your application does not contain any resources or scripts for a particular application framework, if the application framework contains a vulnerability that manifests before it attempts to locate the requested script.

Use the following techniques to configure the minimal set of handler mappings for your application:

• Review the handler mappings to understand what resource types can be processed in your application. Keep in mind that the Web server will attempt to satisfy each incoming request with the first handler mapping that matches the URL path and verb of the incoming request. Typically, the StaticFileModule will process all requests that have not matched other handler mappings, thus serving the requested resource as a static file if its extension is listed in the application's MIME type configuration. For more information on how handler mappings are selected, see the section titled "Adding Handler Mappings" in Chapter 12.
• Remove any unused handler mappings in your application. You can do this by removing the specific handler mappings. If possible, remove all handler mappings by clearing the system.webServer/handlers configuration section and re-adding only the handler mappings that your application uses.
• Be aware of preconditions. Because preconditions can be set on handler mappings to disable the use of these mappings in some application pools, some handler mappings may be ignored, resulting in the request being served using another matching handler mapping. To avoid security problems, do not create multiple handler mappings that rely on order to match similar requests.
• Add applicable restrictions to handler mappings. When adding new handler mappings, make use of the resource type restrictions to restrict the handler mappings only to requests that map to existing physical files or directories in your application. This can help stop malicious requests to resources that do not exist in your application. Additionally, make use of the access restrictions as described in the section titled "Setting Web Site Permissions" later in this chapter.

See Chapter 12 to learn more about creating handler mappings, how preconditions affect them, and using the resource type and access restrictions.

If you are operating a Web server on which third parties can publish application content, be aware that they can modify the handler mappings in any way to control how requests to their applications are processed. They can add new handler mappings to any enabled module, remove any of the existing handler mappings, or map requests to other handlers. If you do not want this to happen, you should consider locking the system.webServer/handlers configuration section. For more information on locking down the handler mappings, see the section titled "Locking Down Extensibility" in Chapter 12.

Note Handler mappings that map requests to ISAPI extensions (IsapiModule), CGI programs (CgiModule), and FastCGI programs (FastCgiModule) are further limited by the ISAPI and CGI Restrictions and FastCGI program configuration at the Web server level, which can be set only by the administrator.

Setting Web Site Permissions

Web site permissions are an additional restriction that can be placed on a Web site, application, or URL in configuration to control what requests IIS is allowed to serve. These permissions are implemented at two levels. First, each handler mapping specifies the required permission level by using the requireAccess attribute. If the request that matches this handler mapping is made and the required permission is not granted for the requested URL, IIS will reject the request with a 403.X response status code. Second, some IIS components have hard-coded requirements for certain permissions, and they will reject the request if they are processing a request to a URL that does not have this permission.

Note Web site permissions control what functionality is enabled to be used at a particular URL. They do not consider the identity of the requesting user and therefore cannot be used to replace IIS authorization schemes when implementing access control.

Table 14-2 indicates the permission types that can be granted for a particular URL.

Table 14-2 Permission Types Granted for URLs

In IIS Manager, you can set the permission granted for a particular Web site, application, or URL by selecting the appropriate node in the tree view and then clicking Handler Mappings. There, you can set the Read, Script, and Execute permissions by clicking Edit Permissions in the Actions pane. Doing this also automatically shows the handlers that require a permission that is not granted as disabled, to let you know that requests to these handlers will be rejected.

You can set the permissions directly in configuration by editing the accessPolicy attribute of the system.web/handlers configuration section or by using Appcmd or other configuration APIs to do it. For example, to grant only the Read permission to the /files subfolder of the Default Web Site, you can use the following Appcmd syntax.

%systemroot%\system32\inetsrv\Appcmd set config "Default Web Site/files" 
/section:handlers /accessPolicy:Read

Note When you specify a configuration path to apply configuration to a specific Web site or URL, you may get an error indicating that the configuration is locked. This is because most security configuration sections, including all authentication sections, are locked at the Web server level to prevent delegated configuration. You can unlock these sections to allow delegated configuration, or you can persist the configuration to applicationHost.config by using the /commit:apphost parameter with your Appcmd commands.

Use the following guidelines when setting Web site permissions:

• Remove unnecessary permissions for URLs that do not require them. By default, Read and Script permissions are granted. For URLs that do not require the ability to execute dynamic application technologies, remove the Script permission. Do not grant additional permissions such as Execute unless necessary.
• Keep in mind that applications can configure handler mappings that do not require permissions. By default, applications can change existing handler mappings or create new handler mappings to not require permissions. Because of this, do not rely on Web site permissions for controlling which handler mappings can or cannot be created by applications that use delegated configuration. The permissions are only guaranteed for built-in IIS features including the static file handler, IsapiModule, CgiModule, and ASP.NET handlers, which hardcode the permission requirements. In other cases, the permissions are guaranteed only if the system.webServer/handlers configuration section is locked and prevents changes to the handler mappings set by the Web server administrator. For more information about locking down the handlers configuration section, see the section titled "Locking Down Extensibility" in Chapter 12.

Note Unlike in IIS 6.0, wildcard handler mappings no longer ignore Web site permissions. In IIS 7.0, they require the same level of permissions as they would when mapped with nonwildcard handler mappings. Because of this, configurations in which a wildcard-mapped ISAPI extension is used for URLs that do not allow the Script permission will now be broken and require the Script permission to be granted.

Configuring Minimal Sets of MIME Types

By default, to serve the corresponding physical file to the client, IIS handler mappings are preconfigured to direct all requests not mapped to other modules to the StaticFileModule (if the file does not exist, a 404 error response code is returned).

Note In IIS 7.0, the MIME types configured by default have been upgraded to contain many of the new common file extensions.

For security reasons, the StaticFileModule will serve only files whose extensions are listed in the MIME type configuration. This behavior is extremely important, because otherwise applications that contain scripts and other content that is processed by application framework technologies may end up serving these resources directly if the appropriate application framework handler mappings are not installed or become removed. In this situation, the MIME type configuration protects these resources from being served to the client and results in a 404.3 error returned to the client.

Note You can learn about configuring MIME types in the section titled "Enabling New Static File Extensions to Be Served" in Chapter 11.

The default list of MIME types in IIS 7.0 should be safe for most applications. You can further configure the MIME types at the server level—or for a Web site, application, or URL—to mandate which file extensions are servable by the StaticFileModule. By reducing this list to only the extensions of the files known to be safe to serve, you can avoid accidentally serving files that are part of an application and are not meant to be downloaded.

Caution MIME type configuration prevents only unlisted files from being downloaded directly through the StaticFileModule. It does not protect the resources from being accessed through the application, nor does it protect them from being downloaded if they are mapped to custom handlers. To protect application resources that are not meant to be accessed, you should forbid their extensions or use Request Filtering to place the content in a directory that is configured as a hidden segment. For more information, see the section titled "Request Filtering" later in this chapter.

You should use the following guidelines to securely configure the MIME types list:

• Do not add file extensions to the MIME types configuration that are not meant to be downloaded directly. This refers to any of the file types that are used by the application, such as ASP, ASPX, or MDB.
• Configure a minimal set of MIME types for each application. If possible, configure the MIME types for each application to contain only the minimal set of extensions. This can help prevent accidental serving of new files when they are added to the application. For example, if your application uses XML files to store internal data, you should make sure that your application does not include xml in its MIME type configuration even though the .xml extension is listed there by default when IIS is installed.

< Back      Next >

 

 

© Microsoft. All Rights Reserved.