IIS Informant: Handling the Script Source Access Permission for IIS

[Editor's Note: Do you have an IIS-related question? Send it to [email protected] and you might see the answer in this column!]

I can't determine how IIS's Script Source Access permission functions. Can you explain how this permission works and when I would want to enable or disable it?

The permission you refer to (in webbasedpermissions.tif) is one of a group of permissions (Read, Write, Directory Browsing, and Script Source Access). You can find them on the Properties page of a Web Site (through the Web Site tab), directory (through the Directory tab), or virtual directory (through the Virtual Directory tab). You can even specify some of these permissions on an individual file. These permissions are difficult to explain because they don't always behave as you might expect. Think of these permissions as Web-based because IIS—rather than any underlying programs or OS function—enforces them and because doing so helps clarify their role in the security chain of events, which is important for IIS administrators. Here's the sequence of security checks that IIS performs when it receives a request.

As you can see, IIS enforces the Web-based permissions noted in Step 3 before the OS checks NTFS permissions. Knowing this sequence can help you with troubleshooting. For example, if you permit Everyone Full Control on a resource and clients are still denied access, you might have a problem with Web-based permissions.

As I mentioned, Web-based permissions might not behave as you'd expect. For example, the Read and Write Web-based permissions apply only to static content. Therefore, an Active Server Pages (ASP) script requires the NTFS Read permission but doesn't require the Read Web-based permission. This situation occurs because IIS doesn't read the script directly. The asp.dll reads the script, and asp.dll doesn't check to see whether the Web-based permissions permit the Read permission. The Web-based Read permission also isn't required for executables (e.g., .exe, .dll).

Similarly, the Web-based Write permission doesn't prevent an ASP script executable from writing to a Web site, directory, virtual directory, or file—even if you disable the Web-based Write permission.

Directory Browsing performs much as you'd think it would. If you haven't defined a default document for a Web site, directory, or virtual directory, IIS displays a list of the files and folders to the user, presuming that you've enabled the Web-based Read permission.

Note that in addition to Read, Write, Directory Browsing, and Script Source Access, another setting for Web-based permissions exists—the Execute permission. You can set the Execute permission to None, Scripts Only, or Scripts and Executables.

Now, let's look at the Script Source Access permission. In describing the Script Source Access permission, IIS documentation at http://www.microsoft.com/windows2000/en/server/iis/default.asp?url=/windows2000/en/server/iis/htm/core/iiwspsc.htm (and the online documentation) states "Users can access source files. If Read is selected, source can be read, if Write is selected, then source can be written to. Script Source Access includes the source code for scripts, such as the scripts in an ASP application. This option is not available if neither Read nor Write is selected."

As usual, the details are a bit more involved. First, let's clarify what script means in this context. Relative to the Script Source Access permission, a script is a file that has an extension mapped in the Application Mappings.

Second, let's clarify what a write and a read for a script are in this context. A standard HTTP Get request is a read. However, as far as IIS is concerned, the script processor performs the read and thereby renders the script. This read doesn't constitute an attempt to access the script "source" but rather to access the script's processed output.

If users don't use an HTTP Get, how can they request to read the script source? IIS uses two methods to request a script source: The first involves FrontPage Server Extensions; the second involves WWW Distributed Authoring and Versioning (WebDAV). To keep this explanation short but useful, I'll look only at WebDAV access using a Web Folder on a Web site that doesn't have FrontPage Server Extensions installed.

You can create a Web folder with Microsoft Internet Explorer (IE) by using the File Open command, typing the URL you want to access, and selecting the Open as a Web Folder check box. If the server is WebDAV enabled, permits anonymous access, and has the Read and Directory Browsing permissions enabled, a window similar to Windows Explorer will open and show you the Web site contents (minus virtual directories). With this configuration, you can study how Script Source Access works by simply dragging a script or program to or from the Web Folder of a Windows XP or Windows 2000 desktop. This action will publish (write) or retrieve (read) the script or program (or any document you choose to move around) to the Web server using HTTP.

For this test, presume that NTFS permissions are Everyone (Full Control) and you've enabled the Web-based permissions Read, Write, and Directory Browsing. For each test, the Web-based Execute permission is Change. We'll try to copy a DLL and an ASP script to the Web server with the Script Source Access permission first enabled, then disabled.

Table 1, page 10, shows that if you set the Execute permission to None, Script Source Access doesn't affect copying the DLL but prevents copying an .asp file (and thus also prevents viewing that file). With this configuration, you can't transfer scripts to the server but you can transfer executables. Table 2 shows that if you set the Execute permission to Scripts Only, the results are the same as if it were set to None.

Table 3, however, shows that if you set the Execute permission to Scripts and Executables and disable the Script Source Access permission, you can prevent anyone from copying Scripts and Executables. If you didn't know how these permissions work together, you might wonder why you can't publish Executables to your site even though the NTFS permissions are correct and you've enabled the Web-based Write permission. From the tests, we can draw these conclusions:

Clearly, the Script Source Access permission has some security benefits even though it seems paradoxical that you can prevent Executables from being transferred to the server by enabling Scripts and Executables.