MIME Types (IIS 6.0)
To reduce the available attack surface, IIS serves only a small number of default static file types unless you add an approved extension to the MIME types list in IIS Manager. MIME types instruct a browser or mail application about how to handle the files received from a server. For example, when a browser requests an item on a server, the browser also requests the MIME type of the object. When IIS delivers a Web page to a client browser, IIS also sends the MIME type of the data it is sending. If there is an attached or embedded file in a specific format, IIS also tells the client application the MIME type of the embedded or attached file. The client application then knows how to process or display the data being received from IIS.
A MIME type consists of two required parts (the media-type and sub-type) and one optional part (the parameter-list) in the following format:
IIS does not support the optional parameter-list. Instead, IIS attempts to match the entire string that follows the media-type/.
Known extensions are handled somewhat differently for static pages and for dynamic content, but you can add, change, or remove allowable extensions for both static and dynamic content. For more information about enabling dynamic content, see Enabling Dynamic Content.
If a user requests a file with an extension that is not permitted, the user receives a 404 error (File not found), rather than a 403 error (Access is denied). This reduces the amount of information that is supplied to a would-be attacker. For more information about interpreting substatus error codes, see Analyzing Log Files.
Inheritance and Merge Behavior
IIS merges the MIME type mappings that it finds on different levels into one in-memory representation. For example, when IIS receives a request, it searches for the MimeMap property for the level, such as lm/w3svc/1/root/MimeMap, and the closest inherited level. If the MIME type for an extension is not in the resulting array, IIS looks for the MIME type in the registry (HKEY_CLASSES_ROOT\extension). If no matching MIME type is found, IIS can use a wildcard mapping if one is configured. Otherwise, the user receives a 404 error. The default wildcard for IIS is .*, application/octet-stream.
Using a wildcard mapping can pose a security risk, and is recommended for troubleshooting only. By default, wildcard mapping is not configured in IIS, and only extensions that are defined at the MimeMap node in the IIS metabase are served.
If you use IIS Manager to remove a MIME type mapping, you must also verify that the MIME type does not exist in the registry. If the MIME type continues to exist in the registry, files with that extension continue to be served. Be aware, however, that removing MIME type mappings from the registry may affect other applications, because the registry database is shared by multiple applications.
When you configure MIME types, be aware of the restrictive MIME merge behavior of IIS 6.0. Values that are set on nodes are inherited by default by child nodes, but values that are set on child nodes do not propagate back up to parent nodes. For example, if you allow the .ini MIME type on LocalComputer/Directory, but you do not allow this MIME type on the root directory, users might not receive the files that you expect. In this situation, if a user requests http://server/directory/default.ini, the user receives the file. However, if the user requests http://server/default.ini, the user does not receive the file because IIS uses the MimeMap property for LocalComputer/Directory and does not merge it with entries in LocalComputer/Root. Instead, the user receives a 404 error.