Chapter 13: .NET Framework Network Security


Security is critical in a networked world. When designing a networked application, developers must be constantly aware of security, because network programs can potentially expose data or users that interact through them. If the data or the users are compromised, then fewer people will use the application. The Microsoft .NET Framework and the underlying Common Language Runtime (CLR) were designed from the ground up with network security in mind.

In this chapter, we ll briefly describe security capabilities in the .NET Framework that can help you secure your networking application. We ll first present code access security that protects system resources from dangerous applications. After that, we ll present how you can tighten up security in a socket application, especially when it is connected to the Internet. Next, we ll look at the Hypertext Transfer Protocol (HTTP) and see how networking security can be improved in Web services and .NET remoting applications. Finally, we ll briefly describe other network security concepts, such as XML digital signatures, that can further protect your data when running network applications.

Code Access Security

Code access security (CAS) is a run-time security mechanism for managed code applications designed to help protect your computer resources using the .NET Framework. CAS is applied to applications based on the identity of running code instead of a user ID. For example, if a .NET application is downloaded from the Internet and executed from a Web browser, the .NET Framework can limit the application s ability to use operating system resources, including opening a file or using a network socket. CAS associates trust permissions to an assembly and enforces security when an assembly calls a protected resource.

Permissions

Table 13-1 outlines the available permission sets in the .NET Framework. Each permission set is a collection of multiple permissions for various resources on the computer. For example, the Socket Access permission set defines whether an application can use a socket to connect or accept a connection on a network. Permissions sets are managed and maintained by the .NET Framework s run-time security policy, which is defined in multiple security configuration XML files.

Table 13-1: .NET Framework Permissions

Permissions

Description

Directory Services

Grants assemblies access to directory service paths

DNS

Grants assemblies access to DNS queries

Environment

Grants assemblies access to event logs

Event Log

Grants assemblies access to environment variables

File IO

Grants assemblies access to files and directories

File Dialog

Grants assemblies access to file dialog boxes

Isolated Storage File

Grants assemblies access to file-based isolated storage where you can set disk quotas

Message Queue

Grants assemblies access to message queues

OLE DB

Grants assemblies access to OLE DB providers

Performance Counter

Grants assemblies access to performance counters

Printing

Grants assemblies access to printers

Reflection

Grants assemblies permission to discover information about other assemblies

Registry

Grants assemblies access to registry keys

Security

Grants assemblies specific security permissions

Service Controller

Grants assemblies access to control services

Socket Access

Grants assemblies access to sockets

SQL Client

Grants assemblies access to Microsoft SQL Servers

User Interface

Grants assemblies access to user-interface elements, such as windows , events, and the clipboard

Web Access

Grants assemblies access to specific Web sites

Most of the permissions have a limited number of actions they can do to enforce security on a resource. For example, the Registry permission set has one action, with which you list registry keys that assemblies can access. The Security permission set is larger. The following list outlines the many actions available for the Security permission set:

  • Allow calls to unmanaged assemblies

  • Allow domain policy control

  • Allow evidence control

  • Allow policy control

  • Allow principle control

  • Assert any permission that has been granted

  • Create and control application domains

  • Enable assembly execution

  • Enable remoting configuration

  • Enable serialization formatter

  • Enable thread control

  • Extend infrastructure

  • Skip verification

As mentioned earlier, permissions are applied by the CLR based on a security policy when an assembly attempts to access a protected resource.

Policy Levels

The CLR references a security policy to determine what security permissions are applied to what assembly at run time. Security policy in the .NET Framework is managed by three configurable policy levels: Enterprise , Machine , and User . These three policy levels determine what permissions an assembly receives. Enterprise is the highest level, followed by Machine and then User , which is the lowest level. When security policy is evaluated by the CLR, the minimum permission allowed by all three levels is applied.

The highest policy level determines the most that all the other policies can do. Lower-level policies can only further restrict policies. For example, if your machine s Enterprise policy allows all assemblies running on the machine to use sockets freely , the Machine policy level can restrict the use of sockets by disallowing any assembly to accept socket connections. The User policy can further restrict socket use by disallowing any assembly to make connections from a socket.

The User policy level is special because it is unique to a user account that logs onto the machine, meaning there can be multiple User policies on a computer if multiple accounts log on to the computer. So security policy can vary for different User accounts on the same computer.

Security policy levels are managed in the following XML configuration files. Enterprise settings are managed in %SystemRoot%\Microsoft.NET\Framework\v1.1.4322\config\enterprisesec.config. Machine settings are managed in %SystemRoot%\Microsoft.NET\Framework\v1.1.4322\config\security.config. User settings are managed in %SystemDrive%\Documents and Settings\<user account name >\Application Data\Microsoft\CLR\Security Config\v1.1.4322\security.config.

A useful configuration tool named Microsoft .NET Framework 1.1 Configuration can be found in the Control Panel under Administrative Tools. This tool enables you to manage code access security permissions in the XML configuration files by presenting a graphical user interface that shows each policy level and allows the user to set up permissions by defining code groups.

Code Groups

Every security policy level configures specific security permissions by defining security code groups. Code groups enable you to associate specific security permissions with security conditions that an assembly must meet in order to run with permissions available in a code group. For example, you could define a code group named MyCoolGroup with a condition stipulating that any assembly downloaded and run from the Internet can only have the File IO permission to read certain files on the local computer. For every policy level, one or more code groups can be arranged in a hierarchy to define the level s security policy.

Conditions

When a code group is defined, it must specify a condition that an assembly must meet to use security permissions associated with the code group. Several condition types can be defined in a code group, as described in Table 13-2.

Table 13-2: Condition Types for Code Groups

Condition Type

Description

All Code

Identifies any assembly

Application Directory

Identifies the current directory of a running assembly and any child directory

Custom

Allows you to develop a custom method to identify assemblies

Hash

Identifies an assembly with a unique hash key

Publisher

Identifies an assembly using a certificate

Site

Identifies an assembly by the site portion of a URL

Strong Name

Identifies an assembly using a public security key

URL

Identifies an assembly by a URL

Zone

Identifies an assembly by a zone ”Internet, Intranet, My Computer, Trusted, and Untrusted ”where the assembly is running from

The .NET Framework 1.1 comes configured with Zone conditional access defined in code groups at the Machine policy level. The Enterprise and User policy levels allow full trust, so Zone conditional access is the default policy. Zone conditional access defines access for five security zones ”Internet, Intranet and My Computer, Untrusted, and Trusted, as shown in Table 13-2. Each conditional zone identifies where an application comes from and what run-time restrictions are placed on the application.

Internet Zone

The Internet zone identifies applications that are downloaded and executed from the Internet. Applications downloaded from the Internet are generally considered unsafe to run on your computer. The .NET Framework places the highest level of restrictions on applications running in the Internet zone.

Intranet Zone

The Intranet zone is designed for running applications that are run from a local Intranet, such as a company s private networking infrastructure. For example, applications running in the Intranet zone are applications running from a company s private Web server or even applications running from mapped drives and UNC shares. Typically a company s private network runs behind a firewall and is protected from the Internet. Applications running in this zone generally have a higher level of trust as compared to applications running from the Internet and have fewer code access restrictions as compared to applications downloaded from the Internet.

My Computer Zone

The My Computer zone is designed for running applications originating from the local computer, such as an application running from your local hard drive on your computer. This does not include mapped drives or UNC shares, which are a part of the Intranet zone. Applications running in the My Computer zone are allowed access to all resources.

Untrusted Zone

The Untrusted zone identifies applications that come from the Microsoft Internet Explorer list of restricted Web sites. Internet Explorer allows a user to identify a list of restricted Web sites through the Internet Options menu Security tab. If an application is downloaded and matches one of these restricted Web sites, then it is considered unsafe and the application will not run on your computer.

Trusted Zone

The Trusted zone is a security zone controlled by the user. The user is responsible for identifying URLs that can run in this zone through the Internet Explorer list of trusted Web sites. This list can be found using the Internet Options menu and selecting the Security tab. Applications running in this zone can perform limited actions, such as open windows and create files.

Zone conditional security is a great way to protect resources from running assemblies. Table 13-2 outlines other conditional ways security permissions can be applied to running assemblies in the .NET Framework. Since the focus of this book is on networking, we will take a closer look at how CAS can be applied to sockets using Zone security.




Network Programming for the Microsoft. NET Framework
Network Programming for the MicrosoftВ® .NET Framework (Pro-Developer)
ISBN: 073561959X
EAN: 2147483647
Year: 2003
Pages: 121

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net