Web Server Access Control Permissions in IIS 7

Two types of access control permissions apply to IIS: IIS Handler Permissions and NTFS. Handler permissions are specific to IIS and guide how various types of content are accessed. NTFS permissions are the ultimate deciding access control method, but IIS permissions also play an important role.

Note

Share permissions do not affect IIS web or FTP connections.

IIS Handler Permissions

Internally, IIS divides its own permissions into two subsets, Resource and Execution permissions. IIS has its own handler permissions that apply to each Web site, virtual directory, folder, and file, or to the web server as a whole. Permission applied to parent objects is inherited by the child objects unless more specific settings are applied to the child object. The IIS handler permissions are:

• Read

• Script

• Execute

Read permissions allow a client to download a web page, view or download files, navigate folders, serve up default documents, or allow directory browsing. Read is the default permission for all Web sites, pages, files, and folders. If you disable this permission, static content cannot be displayed, although scripts, ISAPI filters, and other executables will still be active and able to render if they have the other appropriate permissions. Script permissions allow scripts (ASP, CGI, and so on) to run. If the user needs to see content returned by the script, you should also enable Read permissions. Execute permissions allow executable content (ISAPI filters, applications, DCOM objects, and so on) to be executed.

To set handler permissions, select the web server object you want to set the permission on in IIS Manager (Web site, folder, file, virtual directory, and so on), and then double-click the Handler Mappings icon under Features view (see Figure 1).

Figure 1: Selecting Handler Mappings in the IIS Manager

Next, select Edit Handler Permissions in the Actions pane. Choose the appropriate permissions for the web server object selected (i.e., Read, Script, Execute) as shown in Figure 2.

Figure 2: Choosing the appropriate Handler permission

You can double-click on each Handler Mapping (StaticFile, CGI-Exe, and so on) and choose whether the referenced handler handles files, folders, or both (see Figure 3).

Figure 3: Choosing handler focus

You can also click the Verb tab and choose which HTTP verbs are valid when used against a particular handler and its related content (see Figure 3). This was a feature previously available only if you installed URLScan (http://www.microsoft.com/technet/security/tools/urlscan.mspx) or the IIS Lock-down Tool (http://www.microsoft.com/downloads/details.aspx?FamilyID=&DisplayLang=en) for legacy systems on IIS hosts. It is a very important, secure setting.

HTTP verbs, known as HTTP methods in RFC 2616 (http://www.tools.ietf.org/html/rfc2616), which defines the current HTTP 1.1 specification, determine whether users can request (GET) or write (PUT or POST) information to a Web site. Current HTTP verbs include:

• GET

• POST

• HEAD

• PUT

• POST

• OPTIONS

• DELETE

• TRACE

• CONNECT

Note

Read RFC 2616 for more details on HTTP verbs and what they allow.

IIS allows you to specify which HTTP verbs are allowed to be used in a connection string (i.e., request) from a client (see Figure 4). Officially, per the RFC, GET and HEAD (which allow the client to request the server's identifying information) must be enabled on all Web sites to be RFC-compliant. Other verbs should be disabled unless needed.

Figure 4: Configuring HTTP verbs

Three previous IIS permissions that some administrators may expect to be present are no longer available in the handler's permission configuration location. They are Write, Script Source Access, and Directory Browsing. Write is tied to WebDAV (along with Script Source Access), which has not yet been added to IIS 7. WebDAV will eventually be added back in as a separate module. Write permission access is now handled by the underlying NTFS permissions. Write allows the connecting user to upload and modify content. This permission should not be given unless writing and modifying content (via HTTP PUTor POST verbs, or WebDAV) are allowed. In some cases, write permissions may not be required when using a program specifically designed for this purpose, such as FrontPage Server Extensions or a custom application.

Script Source Access allows the client to read the web page's source code. This is normally okay, but you may want to disallow this if revealing the web page's source code or scripts can inadvertently reveal sensitive information (such as passwords).

Directory Browsing is now a separate feature available in the Features view in IIS (see Figure 5). The Directory browsing permission has always been a unique one. If selected, browser clients will not download and display HTML content as they normally would. Instead, if the specific document requested is not available, the directory is shown along with a listing of its contained files and folders (much like how an FTP directory might be displayed). Most Web sites normally do not have this permission enabled, and it is disabled by default in IIS 7. However, enabling directory browsing is a convenient way to allow users to view, upload, and download files. To enable Directory Browsing, select the web server object you want to allow Directory Browsing on (typically a Web site, folder, or virtual directory), and double-click on the Directory Browsing feature. Then click the Enable button in the Action pane. You can then modify the file attributes shown in the Directory Browsing window (see Figure 6). Directory Browsing is commonly enabled on intranet platforms and applications.

Figure 5: The Directory Browsing Feature in IIS Admin

Figure 6: Modifying Directory Browsing attributes

Administrators looking for an alternative to secure FTP, which has had trouble becoming a commonly supported standard, should consider using directory browsing instead. Secure FTP clients and servers that talk to one another without issues are hard to find. Instead, enable directory browsing on an HTTPS Web site containing the needed files and folders. Every user's browser will be able to connect and the content and authentication credentials will be authenticated and encrypted by default. Users will be able to right-click and Save As any file and they can drag-n-drop upload files (or save directly to the Web site using their local application if WebDAV is also enabled). Table 1 summarizes IIS permissions and their customary use.

Table 1: IIS Resource Permission Summary
Open table as spreadsheet

PERMISSION	DESCRIPTION
Read	Users can view the content and properties of directories or files, and execute script content. This permission is set by default and is required for Web sites that have static content. If all of your content is scripted, such as a Web site that only uses ASP content, you can remove the Read permission, but this is not generally recommended as it may interfere with rendering static content that may be mixed with the Web site's application.
Write	Users can create, upload, modify, and delete content.
Script	Source Access Users can access source files and scripts. If the Read permission is set, then users can read source or script files; if the Write permission is set, then users can modify source or script files. Must have either the Read or Write permissions set to enable. Set this permission when using WebDAV. If enabled, make sure that you require authentication for this site and that your file permissions are set correctly.
Directory browsing	Users can view file lists and collections, and download files. Enable Write permissions, too, to allow file uploading.

Note

FTPS (FTP using SSL/TLS), along with other significantly improved FTP features, are arriving as a separate add-on for IIS 7 running on Longhorn. The new FTP features may be back ported to Vista.

Note

You can keep the Directory Browsing permission disabled, but allow Write permission to create a "blind drop" Web site, where users can drop off files.

NTFS Permissions

NTFS permissions play a huge role in IIS. Ultimately, if the connecting client "breaks out" of IIS, the NTFS permissions assigned to the web pool identity and impersonated user account are the security mechanism of last resort. All of this assumes you install IIS and the Web site content on an NTFS partition. And you should never install IIS on anything but an NTFS partition!

Web server content files are installed to \Inetpub\wwwroot by default. Default permissions are:

• System and Administrator have full control.

• Users group has Read & Execute.

• IIS_IUSRS group has Read & Execute.

When creating any Web site, the NTFS permissions assigned should be the bare minimum needed by the connecting user, impersonated account, and web application pool identity to reflect the Web site accurately and thoroughly. Although this might seem confusing at first, the effective permission security of any IIS Web site is determined by the union of:

• The NTFS permissions given to the application pool identity account.

• The NTFS permissions given to the user account the client uses to authenticate to the web server (for example, anonymous or an authenticated user account).

• The IIS permissions set on the Web site, virtual directory, folder, or file.

• The IIS execute permissions set on the Web site, virtual directory, or folder.

Understanding the effective outcome of these permissions on each folder and file in each IIS Web site is essential to being a knowledgeable IIS administrator. Read only Web sites should be restricted by Read only NTFS permissions. If executable program files are not needed, the execution permissions should not be set to Scripts and Executables. Permissions are at the core of IIS security, but the features and functionality that IIS is running also play a huge part.