Implementing Security on the .NET Platform

When we talk about the .NET platform, we are referring to the combination of the Common Language Specification that enables code written in many languages to interoperate, the .NET Framework’s class libraries, the Common Language Runtime (CLR), and the Windows operating system (such as Windows 2000, Windows XP, or Windows Server 2003) on which .NET applications run. Figure 9.1 shows an illustration of the .NET Framework.

Figure 9.1: Diagram of OS/CLR/.NET Framework classes

Each of these aspects of the .NET platform provides features that can be used by .NET services to implement security—for example, restricting access to functionality based on user identity, encrypting data sent from a client to a Web service, and customizing the data displayed by an application based on a user’s assigned organizational role. Because a thorough understanding of how to secure services on .NET depends on details at both the NET Framework level and the operating system level, we will now present the features provided by each.

CLR and .NET Framework Security Features

The Common Language Runtime (CLR) is the lowest-level portion of the .NET Framework that is not considered part of the operating system. The CLR provides virtual machine-related capabilities to .NET applications, including the following:

• Memory management (including garbage collection)

• Type checking via code verification

• Code isolation via application domains (appdomains) and assemblies

• Authorization via code-access security

• Authorization via role-based security

Because the designers of the CLR had the advantage of considering security problems inherent in previous approaches to application platforms, they were able to incorporate new security features to help protect .NET applications and services from some common vulnerabilities that had plagued applications in the past.

Managed code, such as a compiled Visual Basic .NET project, runs in close cooperation with the CLR and can take advantage of the protections it provides.

The CLR’s automatic memory garbage collection functionality guards against a programmer allocating memory and then forgetting to release it (by, for example, setting an object to Nothing). This type of error would result in a program gradually using up more and more memory, until it (or the server itself) stopped operating correctly. The CLR’s garbage collector can determine when an object is no longer used and can free the memory it was using, without explicit instructions by the programmer.

A type of vulnerability frequently found in both desktop and network applications is a buffer overflow, which enables a malicious user to supply data to the application that causes it to behave in unexpected ways. Programs are susceptible to buffer overflows due to (sometimes very obscure) errors in their logic. Because buffer overflows can be exploited, even from across the Internet, to run the attacker’s code of choice on the server, they can make for a major hole in your application’s (and entire server’s) security. Managed code runs in a type-safe execution environment that verifies compatible data types and sizes when data is copied from one location to another, performs bounds-checking on array elements, and takes other precautions to minimize the occurrence of buffer overflow conditions.

In older architectures, security restrictions tended to be enforced process by process. The .NET platform features a new application architecture paradigm, introducing the concepts of the assembly and application domain (or appdomain).

The assembly is the basic building block for applications, analogous to a DLL in Win32. Assemblies have many security features, including the ability to be assigned a strong name, which gives the assembly a unique identity and ensures that the correct assembly is loaded when requested by an application. Instead of an application’s DLLs and EXEs being scattered around the file system (some in the application directory, some in Windows, some in Windows\System32, and so on), a .NET application’s assemblies are usually stored together within the application’s directory, or if assigned a strong name, optionally in a global cache of assemblies. This provides the advantage of allowing multiple versions of the same application to coexist, with less ambiguity about versioning than there has been in the past. The simple XCOPY installation process advocated by Microsoft eliminates the problems that can occur as a result of invalid or incomplete installations. The XCOPY technique to install an application is accomplished by simply copying the source directory from the installation location to the target computer, and to uninstall an application you simply remove that directory from the target computer. There is no longer a need, when not working with COM InterOp, to register application information in the registry or to add .dll's to the shared system directory.

Note 

If you use the Global Assembly Cache (GAC) for shared assemblies; you cannot use the XCOPY installation process.

.NET code is self-describing, which means that information about data types, method parameters, and so on, used by an assembly is available directly in the assembly file itself. Therefore, COM-style component registration is no longer required—and it’s no longer possible for component registration information and the component itself to get out of sync when new versions are deployed.

Note 

Deployment-related security features and concerns are discussed in more detail in Chapters 10 and 11.

All managed code runs within an application domain, which is a logical segment of a process at the operating system level. More than one application domain can be hosted within each operating system–level process. Each application domain within a process is isolated from the others, so that it cannot access resources in other application domains, and a failure in one application domain will not affect any other application domain.

The .NET Framework implements two major types of security models:

Code-access security   With code access security, the CLR takes advantage of security policies to determine when code is allowed to run and what it is allowed to do, based on evidence such as the origin of the code, its publisher, and (for components) the assembly that has called the code. Much like the Internet Explorer browser, the CLR can classify code as trusted or nontrusted and assign different permissions based on the location (or zone) of the module being executed, as well as other criteria such as the code’s publisher, strong name, and URL. Permissions granted to code can be easily configured by the administrator without the need to recompile.

Role-based security  With role-based security, the identity of the user running the code is used to determine what the code can do. The .NET Framework includes two versions of role-based security: a COM+ style model as well as a new .NET Framework–native implementation.

It is possible to combine code access security and role-based security within the same application. All of these models are discussed in more detail in the "Using Code Security Models" later in this chapter.

The .NET Framework class libraries include many objects related to security, which the .NET programmer can incorporate into service code. Table 9.1 lists the namespaces that contain security features.

Table 9.1: Security-Related Namespaces in .NET

Namespace	Contents
System.Security	Helper types for handling security exceptions, persisting security objects, improving code performance, and working with permissions and policies
System.Security.Cryptography	Types used to encrypt and decrypt data, and supporting functionality such as generation of hash values to uniquely identify sets of data
System.Security.Permissions	Types used to apply and verify permission attributes
System.Security.Policy	Types used to apply and verify policies
System.Security.Principal	Types used to manage role-based security
System.Web.Security	Types related to web-based security, such as passport authentication

The .NET Framework also includes a variety of authentication mechanisms, which determine how the calling user’s identity is determined and verified. These are summarized in Table 9.2. The implications of the different types of authentication for different types of processes (such as XML Web services and .NET Remoting objects) are discussed in Chapter 11. Not all authentication mechanisms are available for all types of processes.

Table 9.2: Selected .NET Authentication Mechanisms

Authentication Mechanism	Description
Forms authentication	Unauthenticated requests are redirected to an HTML form. The user inputs credentials and submits the form. If the application properly authenticates the request, the client machine is sent back a cookie containing a credentials identifier. This cookie is then sent in the request header of future HTTP requests.
Passport authentication	Authentication is provided by a centralized service, which offers participating applications the ease of use of “single sign on,” enabling users to authenticate once and have their credentials subsequently passed to other applications participating in passport -based authentication.
Client certificate authentication	Clients are authenticated based on the content of the client’s digital certificate. This avoids the exchange of user/password information across the network.
Anonymous authentication	Users are not authenticated by ASP.NET. Processes run as the specified user. In IIS6, this is configured by using the Internet Services Manager. In IIS5, code runs as the user defined in the machine.config file in the system.web section under the <processModel> element.
Windows authentication	Clients are authenticated by one of the mechanisms built into IIS (ASP.NET).
IIS Basic authentication	A specific type of Windows authentication in which user credentials are sent from the client to the server in plain text. Although sending user and password information unencrypted sounds like a bad idea, Basic authentication can work well when used in conjunction with SSL.
IIS Digest authentication	A specific type of Windows authentication in which client-supplied passwords are encrypted with a weak algorithm prior to transmission. Digest authentication is somewhat more secure than Basic authentication, but less secure than Integrated Windows authentication.
IIS Integrated Windows authentication	A specific type of Windows authentication formerly known as NTLM authentication or Windows NT Challenge/Response authentication. This mechanism provides for a higher level of security by using computed challenge/response communication to authenticate, rather than passing encrypted or unencrypted user and password data across the network. Whereas Basic and Digest authentication work over an HTTP or HTTPS connection, Integrated Windows authentication directly uses the Windows operating system’s authentication features and requires communication over additional ports that might not be open on a corporate firewall, so this option might not always be available.

Modern Windows Operating System Security Features

The .NET security features discussed previously are layered on top of the features provided by the Windows operating system. It is important to note that many Windows security features appearing in Windows 2000, XP, and Server 2003 are not available in older consumer versions such as Windows 98. Therefore, for optimal security, it is recommended that .NET applications be deployed on one of these more full-featured editions of Windows.

Some Windows security features include the following:

• User accounts and groups

• User rights

• File permissions

• Policies

User accounts include built-in accounts, such as Administrator and LocalSystem, as well as custom accounts created at a site for each user, such as Tsmith or Bdawson. Built-in accounts ship with Windows-defined default permissions and are often used to run Microsoft-supplied services at a relatively high level of privilege. Individual user accounts have a lower level of permission that is sufficient for typical nonadministrative use of the network. You saw when discussing Windows services that code might sometimes require a higher level of permission than that provided by a standard user account, to perform required tasks (for instance, to run as a Windows service). Fortunately, that is not necessarily the case for other types of services that might be developed with Visual Studio .NET.

For ease of administration, accounts are often combined into sets known as groups. Assigning permissions and rights at the group level rather than the user level reduces the amount of system administration effort required to keep security settings up to date as staff join the organization, leave it, or are transferred to positions with other duties. This advantage of operating system–level groups is also found in role-based security mechanisms employed by .NET. In fact, one of the role-based security models supplied with .NET directly uses these Windows groups as roles.

User rights are privileges that can be granted to users. For instance, standard users typically have the right to log on locally to network desktop computers. They usually do not have higher-level rights (such as the right to back up files), which are typically enjoyed only by administrators and staff with network operator duties. User rights are the lowest level at which the administrator can control the basic activities that the user is allowed to perform on the system.

To set user rights effective on the local system only, use the Local Security Policy applet (available at Start Ø Settings Ø Control Panel Ø Administrative Tools in Windows 2000 Professional) and choose Security Settings Ø Local Policies Ø User Rights Assignment. User rights applicable to all computers in the domain can be set by using the Domain Security Policy applet. Figure 9.2 shows the interface used to set user rights on the local system.

Figure 9.2: Local security policy user rights

Additionally, you might further restrict access to individual resources on the system, by group and user, through the use of access control lists (ACLs) on resources such as files. For example, if your application writes certain text files to the folder C:\myapp\exportdata, but you don’t wish to allow nonadministrative users to view the names of files in that folder, you can use an ACL to deny that type of access. To do that, navigate to the C:\myapp folder in Windows Explorer, right-click the exportdata folder, choose Properties, and select the Security tab. Click the Deny check box for List Folder Contents to select it, click Apply, and then click OK. The dialog box you will see looks similar to Figure 9.3.

Figure 9.3: Setting file access permissions

The permissions that a .NET application has when running are a layered combination of those granted at the .NET Framework level (via code access security and role-based security) and those granted the user under whose identity the application is running, at the operating system level (via resources, ACLs, and user rights.)

The application cannot be granted permissions at the .NET Framework level that the user is not authorized to have at the operating system level. For example, if the user cannot access files in the C:\PrivateAdmins folder with a standard system application such as Notepad, you will not be able to give an application running under that user’s identity permission to access those files within your Visual Basic .NET application. Assigning permissions under the various security models available on the .NET platform is covered in the next section of this chapter.

Policies are groups of configuration settings that customize Windows in line with the operational policies of an organization. Policies can be set on various levels, including for the entire enterprise, particular machines, particular users, and particular groups of users. As you will see later in this chapter, the concept of policies makes an appearance in the .NET Framework.

Now that you have had the opportunity to look at some of the features available to implement security in .NET services, you’re ready to take a closer look at some of them, such as permissions, code security models, and support for cryptography.