INFO: Executing Files by Hyperlink and the File Download Dialog Box
ID: Q232077
|
The information in this article applies to:
-
Microsoft Internet Explorer (Programming) versions 4.0, 4.01, 4.01 SP1, 4.01 SP2, 5.0
SUMMARY
Many Web sites, particularly on corporate intranets, have hyperlinks to files that the user needs to execute on the local system. For obvious security reasons, Internet Explorer prevents any hyperlink action from automatically running any downloaded executable or other possibly dangerous files without displaying some form of dialog box prompt to the user.
In these situations, the File Download dialog box is not preventable in any way. This includes the use of HTML tags, script in the page, hosting the WebBrowser control, and changing security zone options.
Unfortunately, this dialog box can be disruptive to a Web-based interface that relies on these sorts of links to simplify the use of executable files stored on the Web server. This article discusses two alternative safe methods for automatically executing files by hyperlink.
MORE INFORMATION
Internet Explorer displays the File Download dialog box for two primary reasons: safety and choice. To be safe, the browser must never execute a potentially dangerous file on the user's system automatically without potential user intervention. Furthermore, Web sites have traditionally used links to executable files with two different intentions: the site intends for the user either to execute the linked file or to save it. Unfortunately, there is nothing in the HTML specification for the anchor tag (<A>) or any current scripting object model that provides a means for the Web site to indicate which is desired for a particular link. Thus, the burden of choice is on the user. The user must decide whether they want to run or save the file.
Internet Explorer decides whether to display the File Download dialog box primarily by checking the file's extension and looking in the registry for an application that reads that file. For most types of files, the user can clear the "Always ask before opening this type of file" option in the dialog box, which grants permission to Internet Explorer to not display the dialog box in the future for those specific file types. Users can also change this setting in the Edit File Types dialog box accessible from the shell's Folder Options by flipping the "Confirm open after download" check box.
However, Internet Explorer contains a predefined, hard-coded list of file
extensions that it inherently distrusts. These extensions correspond to generic
executables and other kinds of files that have the capability to harm the user's
machine without the proper security safeguards. The File Download dialog box
cannot be prevented for any files of these types. The "Always ask before
opening" option will be grayed out on the dialog box and you won't be able to
select it. Following is the list of the file extensions for these file types. (NOTE: Files marked
with the "IE5 only" option force a prompt on Internet Explorer 5 and later browser versions;
previous browser versions leave the Always Ask option enabled)
EXE, COM, BAT, LNK, URL, CMD, INF, REG, ISP, BAS, PCD, MST, PIF,
SCR, HLP, CHM (IE5 only), HTA (IE5 only), ASP, JS, JSE, VBS, VBE, WS, WSH
As a convention, this article refers to any of these types of files as
"executable" files.
Now consider the scenario of a simple corporate intranet Web site that includes a list of executable links on a friendly Web page. The links are intended to be downloaded and run immediately. Given that the executables are most likely guaranteed by the corporation to be safe (well, as safe as any other typical computer program), it can be extremely tedious to have the user repeatedly deal with the File Download dialog box, especially if this page is used on a daily basis.
Even if the executable files have been signed and the signer is trusted by the user, Internet Explorer will still display the File Download dialog box. Worse yet for the hapless Web authors, Windows UNC hyperlinks -- "\\server\share" hyperlinks that bypass the Web server -- are subject to the same iniquity.
For corporate intranets, there is an alternative to pure hyperlinks that this article refers to as "IFRAME linking." Internet sites can't use this method but can use the method this article refers to as "Internet Code Download linking." (The latter method is available to corporations, too.)
NOTE: At default security levels, both techniques still show security dialog boxes. Unlike the troublesome File Download dialog box, though, all of these security dialog boxes are controllable through standard zones-based security options. For the IFRAME linking technique, the dialog box that may appear reads "Running a system command on this item may be unsafe..." and is controlled by the custom security option "Launching programs and files in an IFRAME." For the Internet Code Download linking technique, the dialog box that may appear reads "Do you want to install and run..." and is controlled by the custom security option "Download signed ActiveX controls."
If you use the techniques in this article in an intranet environment, it is highly recommended that these settings changes are approved and changed for all users of the Web site by corporate administrators. The Internet Explorer Administration Kit (IEAK) provides an easy mechanism for administrators to control and broadcast browser settings such as this. Refer to the IEAK Web site for more information.
Public Internet sites should not require users to alter any security settings to view their Web site. Rather, sites that require altered security should request that the user add the site to their "Trusted Sites" list in the Internet Options security property page. This specific site will then operate under low enough security that both techniques in this article will work without prompt.
IFRAME Linking
In this alternative, the Web page exploits Internet Explorer's ability to display Explorer-style file list views inside floating frames (<IFRAME>). Follow these steps:
- Move the files to a special server, share, and directory on the corporate Intranet that the entire intended user audience has permissions to access via Windows UNC.
- Create a separate directory for each executable file and copy the files into the directories. The directories should be empty except for the single executable file.
- Wherever a hyperlink to the executable would have been used, include HTML of the following form:
Click on the icon in the following window to run this very special
program automatically without annoying dialog boxes:
<IFRAME SRC="\\server\share\directory"></IFRAME>
Note that the HTML code points to the directory that the file is located in, not the file itself.
The intended file's directory appears in an Explorer-style file view. When the user clicks the icon in the view, the file executes just as if the user had clicked the file icon in a traditional Windows Explorer window.
Internet Code Download Linking
In this complicated alternative, the Web page bypasses the ordinary File Download process by utilizing Internet Code Download. Internet Code Download is the Internet Explorer feature that allows Web pages to automatically download ActiveX controls and other native code Objects. Files obtained through Internet Code Download pass through the ActiveX security framework, which is controllable by security options.
- If the "executable file" is not a signable PE (EXE) such as a .bat file, then the file must be packaged in a .cab file with an INF in the following form:
[version]
signature="$CHICAGO$"
AdvancedINF=2.0
[Add.Code]
file.zzz=file.zzz
[file.zzz]
clsid={15589FA1-C456-11CE-BF01-00AA0055595A}
FileVersion=1,0,0,0
hook=zzzinstaller
[zzzinstaller]
run=%EXTRACT_DIR%\file.zzz
Replace the instance of File.zzz above with the executable file to be run.
For more information on packaging the CAB file, refer to the MSDN Web Workshop tutorial Packaging Components for Internet Distribution.
- Ensure that the EXE (or CAB) is code-signed. If the EXE has not been signed, this can be done using the CryptoAPI Authenticode Code Signing tools. Refer to the CryptoAPI documentation in the MSDN Platform SDK under the "Security" heading for more information.
For security reasons, the process of signing code for an organization is best handled by a central authority that is trusted by the entire organization. Code signing requires either the purchase of costly certificates from external vendors such as VeriSign or the maintenance of a certificate server such as Microsoft Certificate Server on the intranet.
- Use this example page as a guideline for the link and script necessary to launch the signed code without prompt:
<HTML><HEAD><TITLE>Page of executable links</TITLE></HEAD>
<BODY>
<BR/>
<!-- hyperlink uses central script function called linkit() -->
<A HREF="" onclick="return linkit('signed-testfile.exe');">
SIGNED-CLOCK.EXE</A>
<SCRIPT>
// linkit puts filename into HTML content and spews it into iframe
function linkit(filename)
{
strpagestart = "<HTML><HEAD></HEAD><BODY><OBJECT CLASSID=" +
"'CLSID:15589FA1-C456-11CE-BF01-00AA0055595A' CODEBASE='";
strpageend = "'></OBJECT></BODY></HTML>";
runnerwin.document.open();
runnerwin.document.write(strpagestart + filename + strpageend);
window.status = "Done.";
return false; // stop hyperlink and stay on this page
}
</SCRIPT>
<!-- hidden iframe used for inserting html content -->
<IFRAME ID=runnerwin WIDTH=0 HEIGHT=0 SRC="about:blank"></IFRAME><BR/>
</BODY></HTML>
© Microsoft Corporation 1999, All Rights Reserved. Contributions by Jason Strayer, Microsoft Corporation
Additional query words:
Keywords : kbDHTML kbIE400 kbIE401 kbNavigation kbSecurity kbIE401sp1 kbIE401sp2 kbGrpInet kbIE500
Version : WINDOWS:4.0,4.01,4.01 SP1,4.01 SP2,5.0
Platform : WINDOWS
Issue type : kbinfo
|