IIS Insider - June 2003

  • Article

By Brett Hill

Effect of Removing Extensions from ISAPI Application Mappings

Q: I would like to know what the consequences are for removing some extensions from ISAPI application mappings. What is the effect of the performance or operations of the web site for removing: .htw, .idq, .cer, .cdx, asa, .htr, .idc, .shtm, .stm, .printer, etc.

A: If you are using IIS 6 - by default, none of the application mappings can be invoked even if they are installed without first configuring the Web Service Extensions. Consequently, the mappings are more of a significant issue in IIS 4 and IIS 5 where they are installed and enabled by default. Presuming you are referencing IIS 5, the application mappings (as shown in Figure 1) can be found in the Internet Service Manager console in the WWW Master Properties, Home Directory, Configuration button.

If your browser does not support inline frames, click here to view on a separate page.

Figure 1   Application Configuration

As you have noted, locating them is one thing, but knowing what you can safely remove is another. You are wise to remove or otherwise disable all application mappings that you are not actively using. Conveniently, the IIS Lockdown tool will accomplish this task for you if you like. At the same time, the Script Maps screen in the tool shows the applications associated with file extension (as shown in Figure 2).

If your browser does not support inline frames, click here to view on a separate page.

Figure 2   Internet Information Services Lockdown Wizard

The most commonly used applications mappings are ASP followed by Server side includes. If you require these capabilities, you cannot remove them from the list. The rest of the mappings are as follows:

  • Index Server Web interface (.idq, htw, .ida) - .idq and .ida map to idq.dll and .htw maps to webhits.dll. The two programs provide a method by which you can query index server on Windows NT 4.0 or index services or Windows 2000 and return results to a web page. ASP includes much of this same functionality so these extensions are virtually obsolete. You can find more information about these abilities at https://msdn.microsoft.com/library/en-us/indexsrv/html/ixuwebov_4i0j.asp.

  • Internet Data Connecter – It is strongly recommended that you remove or disable this extension (.idc). This extension has been around a long time. The .idc extension was provided as an early way to connect to SQL servers. Like the index server extensions, .idc is obsolete since you can perform the same functions much easier and more securely in ASP.

  • .HTR Scripting – Frequently it is convenient for users to change their user account passwords with a web-based application. Outlook Web Access is an example of such an application. The .htr scripts provide this capability. You'll find these scripts located in the \winnt\system32\inetsrv\iisadmpwd folder on an upgraded file server and instructions on how to enable these scripts at https://support.microsoft.com/default.aspx?scid=kb;en-us;267596&sd=tech. See Knowledge Base article 269082 IISADMPWD Virtual Directory Is Not Created During Clean Install of IIS, if you did a clean installation of IIS.

    Even thought this is a useful feature, it is strongly advised that you not use the .htr files for password change services. Look for Microsoft to provide an alternative to these scripts in the near future. You can create your own routines that provide the same capabilities, and doing so provides you the opportunity to better integrate with your applications and avoids exposing the .htr dll to the public.

    One more important point: When you remove an application mapping in IIS, IIS will no longer regard that mapping as a script and will deliver it as text. Consequently, you must take action, such as removing all files with the associate extension so that when you remove a script mapping, the code that was previously parsed by the script engine is not delivered as text to the client.

  • Internet Printing – Internet Printing is an application that allows you to print a page to a printer using a URL. This permits IIS to act as an internet or intranet available print server. The protocol used to achieve this is the Internet Printing Protocol (IPP 1.0), defined by the Printer Working Group (PWG) of the Internet Engineering Task Force (IETF). While an interesting capability, it is a feature that is scarcely used. I wouldn't be surprised to see support for this feature dropped in future versions of IIS. For more information see https://msdn.microsoft.com/library/default.asp?url=/library/en-us/graphics/hh/graphics/inetpri_2muf.asp

How to Prevent the Opening of Others Files By Manually Entering the URL In the Browser's Address Bar

Q: I hope you can steer me to a solution regarding a web project. I have an employee login link from the main page. When employees log in, there is a page with a link to a CGI Perl script that lists the person's files. A person can click on any of them to open the file in a separate window. All of this works.

The problem is this: When an employee opens their files, the path to the files are shown in the URL in Internet Explorer. Because all the employee's files reside in the same virtual directory on the web server, an employee can easily construct a path to another employee's files.  For example, once someone opens their file, they see their file path as www.myserver.com/Voucher/myfile.html. They could then enter enter www.myserver.com/Voucher/yourfile.html to open someone else's file.

If I take away anonymous authentication in NTFS for the directory that takes away URL browsing but also prevents them from opening their own file when the CGI lists it. How do I get it to display and open the file via the CGI script only but prevent opening it by entering the path in the URL address bar?

A: If the content is in the web site's directory structure - meaning it is accessible at all through a URL - then someone can potentially deduce the URL and access it. One way to prevent unauthorized access is to authenticate users and control access with NTFS permissions. This will not prevent users from figuring out legal URLs, but will control what they can access. From your description, something is not quite right with the permissions if the user cannot open their own files. The specific user account (or group they belong to) needs to have at least the NTFS Read permission on the file. After the employee authenticates, they can open the file.

If the CGI process is reading the files, you will need to provide at least the NTFS Read permission to the user that invokes the CGI process. You can use Filemon from www.sysinternals.com to quickly troubleshoot access permissions related to NTFS permissions.

Secondly, the CGI process can be written to read and deliver files that is not part of the web directory structure. In other words, the CGI scripts could be at https://severname/scripts located in d:/webcontent/scripts. When the script is invoked, it could read files from any location on the disk subsystem such as d:/employeefiles. If there are no virtual directories or web sites that map to d:/files, then it is only accessible from the CGI program and not directly through a URL. If you did not allow anonymous access to your CGI program, then, in your code, you can deliver only the content for the authenticated user to the browser. In this way, the users cannot bypass the CGI program in order to gain unauthorized access.

How to Make HTTP Headers for All Content to

Q: In order to avoid Internet Explorer caching of our dynamic content, we set IIS 5 content expiration to expire immediately (as shown in Figure 3).

If your browser does not support inline frames, click here to view on a separate page.

Figure 3   Default Web Site Properties

When configured this way, an ASP file is rendered with the following headers from IIS:

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Wed, 21 May 2003 23:21:26 GMT
Connection: Keep-Alive
Content-Length: 8593
Content-Type: text/html
Cache-control: private

However, a .gif file is delivered with these headers:

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Cache-Control: no-cache
Expires: Wed, 21 May 2003 23:22:30 GMT
Date: Wed, 21 May 2003 23:22:30 GMT
Content-Type: image/gif
Accept-Ranges: bytes
Last-Modified: Sat, 21 Aug 1999 22:34:16 GMT
Content-Length: 359 

As you can see, the Cache-Control: no-cache and Expires headers are not included with the .asp file. Is there a way to cause IIS to apply these headers to all content?

A: You are quite right in your analysis that the Expire Content Immediately setting does not apply to all files. When Expires Content Immediately is set in the user interface, it only applies to static content, not dynamic content.

There is an effective solution to your problem: When you need headers to appear on all content, create a Custom Header. When a custom header is specified, it is added to all content, both static and dynamic.

Submit your questions to the IIS Insider. Selected questions along with the answers will be posted in a future IIS Insider column.

For a list of previous months questions and answers on IIS Insider columns, click here.