.NET Framework Security

The .NET Framework was designed with mobile code solutions in mind. There are a couple of different ways that .NET assemblies can be used in mobile code situations. First, they can be downloaded and run just like unmanaged executables. Second, they can be loaded into a browser and run like Java applets or ActiveX controls.

NOTE

Chapter 21, "Administering Clients for .NET Framework Mobile Code," covers particular administrative concerns for mobile code, regardless of how it is executed. However, there is no chapter in this book specifically tailored at developing mobile code solutions in the .NET Framework. Developing secure mobile code on the .NET Framework has generally the same concerns as developing secure code users might install from a CD-ROM. Thus, much of Part V, ".NET Framework Security for Developers," is important for developers of mobile code.

TIP

Some software has used mobile code in the past because server-side programming does not always provide the flexibility or prewritten components needed for rich functionality. The ASP.NET programming environment has greatly improved on previous possibilities with ASP, so make sure to investigate this before deciding to use mobile code solutions. Security aspects of ASP.NET are covered in Part III, "ASP.NET and Web Services Security Fundamentals," Chapter 20, "Administering an IIS Machine Using ASP.NET," Chapter 27, "Writing a Secure Web Site Using ASP.NET," and Chapter 28, "Writing a Secure Web Application in the .NET Development Platform."

Direct Execution

In Internet Explorer, you might download and directly execute a .NET assembly when you click on an HREF link to an EXE file on a Web page. When this is done for unmanaged executables, a dialog opens asking whether you want to open or save the file. Also, depending on browser security settings, another warning dialog might appear if the EXE is not signed with a digital certificate. For managed EXEs, though, the assembly is simply executed. No warning dialogs are presented, regardless of whether or not the assembly is signed. Because the security policy is always used to evaluate trust of .NET assemblies, displaying dialogs doesn't really provide much benefit. If you mean to block execution from most sites, you can set the security policy that way before any applications are run.

Direct execution of .NET assemblies has these benefits:

• Like unmanaged executables, .NET assemblies are very easy for end users to handle. Simply click on a link and they run in a safe environment that provides semitrusted execution. Assemblies are not hindered by the Authenticode dialogs of ActiveX controls.

• Many security properties can be verified and enforced on the assembly simply because it is managed code. These properties include type safety, metadata validation, garbage collection, and automatic bounds checking on arrays.

• Because the .NET Framework is not tied to one OS, you might be able to use the same files for different platforms. Just as with Java applets, cross-platform compatibility is possible as long as native API calls are not made.

Directly running .NET assemblies has these pitfalls:

• As with Java applets and scripts, certain software must be installed first. In the case of .NET assemblies, the .NET Framework must be installed before assemblies can execute.

• As with Java applets, decompilation is quite possible with .NET assemblies.

• There is some skepticism regarding cross-platform compatibility of .NET assemblies. Portions of the .NET Framework specs have been standardized by ECMA, and there are efforts to make those portions run on other platforms. Only time will tell what level of compatibility will be possible between different .NET Framework implementations .

Browser-Hosted Controls

In addition to running directly, managed assemblies can be hosted inside a Web browser in much the same way as ActiveX controls and Java applets. Using <OBJECT> tags in HTML, types in assemblies can be referenced and used in Web pages. For version 1 of the .NET Framework, assemblies hosted in IE are partially controlled by the ActiveX settings. If ActiveX controls are barred from running in a certain Web page, so are browser-hosted .NET controls.

Browser-hosted .NET assemblies have these benefits:

• Unlike ActiveX controls, browser-hosted .NET assemblies do not pop up an Authenticode UI that requires user interaction. They just load and run in the secured environment.

• Like directly executed assemblies, browser-hosted assemblies have all the benefits provided by the .NET Framework.

• For organizations that do not permit browser-based code execution, .NET assemblies can be shut off without affecting other .NET Framework code execution paths.

Browser-based .NET assemblies have the following drawbacks:

• Browser-based .NET controls cannot be enabled if ActiveX controls are disabled. This lack of flexibility might prevent the adoption of browser-based .NET controls in some situations.

• Like directly executed .NET assemblies, browser-based .NET controls require the presence of the .NET Framework. Thus, existing clients will not be able to leverage these controls without extra work.

• Again, cross-platform assembly compatibility is still up in the air. It seems likely that some level of compatibility will be achieved, but the details are not yet known.