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.
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.
|
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.
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.
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.
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.
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 1 indicates the permission types that can be granted for a particular URL.
Table 1. Permission Types Granted for URLs
| Permission | Description |
|---|
| None | No permissions are granted. |
| Read | Read
access to files and directories is enabled.
In particular, this enables the following: static file
handler serving static files, directory listings, and default documents. |
| Script | Script
processing is enabled.
In particular, this enables the following: ISAPI extensions,
CGI programs, FastCGI programs, and ASP.NET handlers. ISAPI extensions
and CGI programs must specify a fixed script processor. |
| Execute | Running
executables is enabled.
In particular, this enables the following: ISAPI extensions
and CGI programs with no script processor set (that execute the file
provided in the request path). If granted, this permission will by
default lead to IIS trying to execute EXE files as CGI applications and
load DLL files as ISAPI extensions instead of downloading them. |
| Source | In
previous versions of IIS, this permission enables WebDav requests to
access the source of script files. No special handling of this
permission is present in IIS 7.0. |
| Write | In
previous versions of IIS, this permission enables WebDav requests to
write files. No special handling of this permission is present in IIS
7.0. |
| NoRemoteRead | Prevents remote requests from using the Read permission. |
| NoRemoteScript | Prevents remote requests from using the Script permission. |
| NoRemoteExecute | Prevents remote requests from using the Execute permission. |
| NoRemoteWrite | Prevents remote requests from using the Write permission. |
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.
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.
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.
|
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.
