Running Mobile Code in Internet Explorer

for RuBoard

Internet Explorer is the most popular Web browser on Windows operating systems. It has many different forms of mobile code available to it while executing. To add managed code to the list of mobile code formats Internet Explorer supports, the .NET Framework provides a MIME filter that Internet Explorer uses to determine whether downloaded executable code is managed or unmanaged.

NOTE

The setup process of the .NET Framework registers a MIME filter. This filter will recognize managed code images that are included on a Web page either in an object tag ( <object ...> ) or referred to by an HREF when they are clicked in a Web page hosted in Internet Explorer. After a managed image is recognized, the CLR is invoked and the managed image is executed.

Managed code executed from Internet Explorer is subject to the same security policy as code executed from other hosts . However, there are a couple of properties about managed code in Internet Explorer that are interesting. First, there are some ties between ActiveX control execution and managed code execution. Second, there are two different ways that managed code can execute in Internet Explorer.

If you want to find further information about how Internet Explorer interacts with the .NET Framework, look up Internet Explorer in the index of the .NET Framework SDK.

ActiveX Controls and Managed Controls

If you have performed administrative tasks involved with Windows client machines, you may be familiar with how ActiveX controls work within Internet Explorer. There are several Internet Explorer settings that control how ActiveX controls work. These settings include the following:

• Whether to download unsigned ActiveX controls

• Whether to download signed ActiveX controls

• Whether to allow scripting with ActiveX controls marked safe for scripting

• Whether to allow scripting with ActiveX controls not marked safe for scripting

• Whether to run ActiveX controls and plug-ins

There are no unique settings to dictate whether to download or run managed controls within Internet Explorer. However, managed controls share the same setting with Internet Explorer for running ActiveX controls and plug-ins. Managed controls will only run if ActiveX controls are set to run and if ActiveX controls marked safe for scripting can be scripted in the zone where the managed control is loaded. If ActiveX controls are set to not run or script, managed controls will not work, independent of .NET Framework security policy.

One other notable difference between ActiveX controls and managed controls is the fact that ActiveX controls can display an Authenticode dialog like the one shown in Figure 21.2. Managed controls will not display such a dialog when they execute.

Figure 21.2. Example of an Authenticode dialog used to verify the digital signature on an ActiveX control.

The Authenticode security mechanism was built with the premise that users could decide whether code was signed and/or by whom it was signed. However, many users do not really have the knowledge to make a well-informed decision. They just know to click Yes to run the code. Instead of using this paradigm, the .NET Framework relies on predetermined policies to make the decision of whether to execute code and how much trust to provide. Authenticode's trusted publisher list is a step in this direction, but not as expressive as the .NET Framework security policy.

One similarity that can be drawn between ActiveX controls and managed controls is the similarity between "Safe for Scripting" and APTCA. In the ActiveX world, "Safe for Scripting" is used to designate that a control is safe to be run in hostile environments. In the .NET Framework, APTCA is used to designate that a control is safe to be run by code with less than full trust. They basically mean the same thing. One important distinction between "Safe for Scripting" and APTCA is to see how security policies handle them. Default ActiveX policy decisions are directly based on the "Safe for Scripting" marking, but APTCA is completely unrelated to .NET Framework security policy. The .NET Framework model is cleaner in that developer decisions (that is, whether to use APTCA) are completely isolated from administrative decisions (that is, what permissions to grant to code).

Different Ways to Run Managed Code in Internet Explorer

There are two different ways to run managed code in Internet Explorer ”an <object> tag to a managed control and an HREF to a managed executable. An <object> tag is used to embed controls in a Web page, and an HREF executable is meant to launch a new managed application.

Note that neither way to run managed code will display any UI to the user . Thus, they won't see any Open/Save/Cancel dialog for HREF exes or Authenticode dialogs in either case. .NET Framework security policy is predefined to prevent malicious code from being able to perform any dangerous actions. Thus, displaying UI doesn't really help increase security and generally just gets in the way.

If you are concerned about the spread of viruses or worms through Internet Explorer, it would take one of two things to make this fear a reality. The first possibility is that an exploitable security hole would have be found in the .NET Framework. It would be foolish to say that no such bug will ever be found, although the use of managed code in the .NET Framework should greatly decrease problems like buffer overruns.

The second possibility is that security policy would have to be changed to grant an inappropriate level of trust for managed code from the location of a malicious assembly. As mentioned earlier, the default security policy starting at SP1 denies the ability to execute for managed code running from the Internet zone. Consequently, unless you modify default policy, malicious code would have to come from your intranet or a trusted site.

for RuBoard