Export (0) Print
Expand All
23 out of 66 rated this helpful - Rate this topic

Handling MIME Types in Windows Internet Explorer

When Windows Internet Explorer downloads a file, it goes through several steps to ensure that the type of the file matches the MIME type declared by the HTTP server. This is known as MIME handling. Some MIME handling steps have changed in Microsoft Internet Explorer 6 for Windows XP Service Pack 2 (SP2) to enhance security.

Determining File Name Extensions

Internet Explorer sets the file name extension of a downloaded file based on a few pieces of information available from the HTTP server and from the file itself. Internet Explorer confirms or resets the file name extension of a downloaded file to ensure that if the file is executed, Windows launches the proper application to handle it.

Internet Explorer first consults the Content-Type and Content-Disposition headers for the MIME type from the HTTP server, if they exist. Next, Internet Explorer consults the registry entry for that MIME type under HKEY_CLASSES_ROOT\MIME\Database\Content Type and looks at the Extension key for the correct file name extension. Internet Explorer then ensures that the file has that extension, before placing it in the local browser cache.

If Internet Explorer knows the Content-Type specified and there is no Content-Disposition data, Internet Explorer performs a "MIME sniff," scanning the first 200 bytes of the file to determine if the file structure matches any known MIME types. For more information on MIME sniffing, see MIME Type Detection in Internet Explorer. If the MIME sniff detects a MIME type known to Internet Explorer, and the file has not been loaded by a mimefilter already, Internet Explorer sets that file name extension before placing the file in the local browser cache.

Lastly, if there is no Content-Type or Content-Disposition data, and the MIME sniff does not recognize a known MIME type, the file name extension is set to the same extension as the URL used to download the file.

If the file is marked as "content-disposition=attachment" in the HTTP header, Internet Explorer treats the file name from the URL as final and does not rename it before placing it in the cache.

Executing a Downloaded File

In Windows XP SP2 and later, after downloading a file, Internet Explorer consults the registry to find out which ProgID and CLSID is associated with the MIME type of the file. The browser then finds the ProgID and CLSID associated with the file name extension. If these ProgIDs do not match, and the CLSIDs do not match, Internet Explorer prompts the user before executing the file, as a safety precaution. Internet Explorer launches only the program associated with the MIME type of the downloaded file and not the program associated with the file name extension (if they are different programs). In Windows XP SP2 and later, if the MIME handler rejects the file, and the MIME handler and shell extension handler don't match, Internet Explorer shows an error dialog. Prior to Windows XP SP2, Internet Explorer opened the file using the shell extension handler if the MIME handler rejected the file.

If the MIME handler rejects the file with an error code of INET_E_CANNOT_LOAD_DATA, then Internet Explorer does not load the shell extension handler even if the ProgIDs or CLSIDs match. This is an extra security measure designed to prevent the shell extension handler from executing corrupt files.

If the file is marked as "content-disposition=attachment" in the HTTP header, Internet Explorer does not look at the MIME handler, shows a file download prompt, and, if instructed to run the attachment, it executes the file.

Updating your MIME Handler for Windows XP SP2 and Later

If you have developed a MIME handler that relies on Internet Explorer to load rejected files using the shell extension handler, there are a few changes you can make:

  1. Update your MIME handler to handle the file directly rather than reject it.
  2. Register a MIME handler and a shell extension handler with the same PROGID. Internet Explorer uses the shell extension handler automatically if its PROGID matches the MIME handler.
  3. Tell Internet Explorer to skip the MIME handler in the case of a mismatch. If the MIME handler has the PreferExecuteOnMismatch key set to '1' in the registry, Internet Explorer does not use the MIME handler if the ProgID and CLSID of the shell extension handler does not match the MIME handler. Instead, Internet Explorer uses only the shell extension handler. The PreferExecuteOnMismatch key is a DWORD key placed under the ProgID of the MIME handler, for example:

    HKEY_CLASSES_ROOT
       PROG_ID_OF_MIMEHANDLER_TO_IGNORE
          PreferExecuteOnMismatch = DWORD:00000001
  4. Register your MIME handler as a secure MIME handler. A secure MIME handler is constructed to securely process any file that is delegated to it. For example, a secure MIME handler should never allow an attacker to gain more privilege than allowed by the zone of the original file. Developers of a MIME handler should use threat modeling and code review to ensure secure failure modes and ensure that the handler is not vulnerable to buffer overruns. When a MIME handler is determined to be safe, it can be registered as safe by adding a registry key named after the ProgID of the MIME handler to the following locations:

    HKEY_LOCAL_MACHINE
       Software
          Microsoft
             Windows
                CurrentVersion
                   InternetSettings
                      Secure Mime Handlers

    HKEY_CURRENT_USER
       Software
          Microsoft
             Windows
                CurrentVersion
                   InternetSettings
                      Secure Mime Handlers

    The new key should have a value of DWORD=00000001.

Altering MIME Handling for the Web Browser Control

In Windows XP SP2 and later, developers hosting the WebBrowser Control can change the way the control handles MIME types using the FEATURE_MIME_HANDLING feature control. For more information, see Introduction to Feature Controls.

Related topics

Other Resources
Microsoft Security
MSDN Security Developer Center
TechNet Security Resources
Security Best Practices

 

 

Show:
© 2014 Microsoft. All rights reserved.