W3C home > Mailing lists > Public > www-tag@w3.org > January 2004

Re: MIME type handling: unexpected christmas present from Microsoft

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 15 Jan 2004 22:56:21 -0500
Message-Id: <F236CB05-47D7-11D8-894A-00039396E15A@mnot.net>
Cc: www-tag@w3.org
To: Julian Reschke <julian.reschke@gmx.de>

Now if only Apple's Safari would catch on...

On Dec 18, 2003, at 8:02 AM, Julian Reschke wrote:

> Quoting from:  
> <http://download.microsoft.com/download/8/7/9/879a7b46-5ddb-4a82-b64d 
> -64e791b3c9ae/WinXPSP2_Documentation.doc>
> What new functionality is added to this feature in Windows XP Service  
> Pack 2?
> MIME-handling file type agreement enforcement
> Detailed description
> When files are served to the client, Internet Explorer uses the  
> following pieces of information to decide how to handle the file:
> •	File name extension
> •	Content-Type from the HTTP header (MIME type)
> •	Content-Disposition from the HTTP header
> •	Results of the MIME sniff
> In Windows XP Service Pack 2, Internet Explorer requires that all  
> file-type information that is provided by Web servers is consistent.  
> For example, if the MIME type of a file is “text/plain” but the MIME  
> sniff indicates that the file is really an executable file, Internet  
> Explorer renames the file by saving the file in the Internet Explorer  
> cache and changes its extension. (In a MIME sniff, Internet Explorer  
> examines, or sniffs, a file to recognize the bit signatures of certain  
> types of files.)
> Why is this change important? What threats does it mitigate?
> If file type information is misreported by the server and that  
> information is saved to the computer, a file could be handled  
> incorrectly later. For example, in the above example, Internet  
> Explorer might download the file, assuming it is a text file. If the  
> file has the .exe file name extension, the file might run later  
> without prompting the user.
> What breaks or works differently? Are there any dependencies?
> Internet Explorer renames files in the Internet Explorer cache to  
> enforce consistent handling of the file by all applications.
> Web developers can isolate breaks due to this behavior by switching  
> off the functionality, as covered in the Settings section later in  
> this document.
> How do I fix the breaks?
> Web developers must change their Web servers to host files, using  
> consistent headers and file name extensions.
> MIME sniffing file type elevation
> Detailed description
> One of the backup criteria for determining a file type is the result  
> of the MIME sniff. By examining (or sniffing) a file, Internet  
> Explorer can recognize the bit signatures of certain types of files.  
> In Windows XP Service Pack 2, Internet Explorer MIME sniffing will  
> never promote a file of one type to a more dangerous file type. For  
> example, files that are received as plain text but that include HTML  
> code will not be promoted to the HTML type, which could contain  
> malicious code.
> Why is this change important? What threats does it mitigate?
> In the absence of other file type information, the MIME sniff might be  
> the only information that determines how to handle a given file  
> download. If, for instance, Internet Explorer upgrades a text file to  
> an HTML file, the file might execute code from the browser and  
> possibly elevate the file’s security privilege.
> What breaks or works differently? Are there any dependencies?
> Web servers that do not include the Content-Type header with their  
> files and that use non-standard file name extensions for HTML pages  
> now have their pages rendered as plain text rather than HTML.
> How do I fix the breaks?
> You should configure Web servers to use the correct Content-Type  
> headers or you can name the files with the appropriate file name  
> extension for the application that should handle the file.
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Thursday, 15 January 2004 22:56:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:03 UTC