< Chap 12 TOC: .NET Framework Network Security | Main | Various Security Options & Implementations >



Chapter 13 Part 1:

.NET Framework Network Security



What do we have in this chapter 13 Part 1?

  1. Code Access Security

  2. Permissions

  3. Policy Levels

  4. Code Groups

  5. Conditions

  6. Internet Zone

  7. Intranet Zone

  8. My Computer Zone

  9. Untrusted Zone

  10. Trusted Zone

  11. Controlling Socket Applications

  12. Socket Permissions

  13. DNS Permissions

  14. DNS Spoofing


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.




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




Directory Services

Grants assemblies access to directory service paths


Grants assemblies access to DNS queries


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


Grants assemblies access to OLE DB providers

Performance Counter

Grants assemblies access to performance counters


Grants assemblies access to printers


Grants assemblies permission to discover information about other assemblies


Grants assemblies access to registry keys


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:


  1. Allow calls to unmanaged assemblies
  2. Allow domain policy control
  3. Allow evidence control
  4. Allow policy control
  5. Allow principle control
  6. Assert any permission that has been granted
  7. Create and control application domains
  8. Enable assembly execution
  9. Enable remoting configuration
  10. Enable serialization formatter
  11. Enable thread control
  12. Extend infrastructure
  13. 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:


  1. Enterprise
  2. Machine and
  3. 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. The following screenshots show the locations of the enterprisesec.config on the Windows XP Pro SP2 machine.


.NET Framework Network Security: the enterprise security configuration file


.NET Framework Network Security: the enterprise level security configuration file for .NET framework 2.x


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. The following screenshots show the version 1.x and 2.x security.config physical paths.


.NET Framework Network Security: the user security configuration file


.NET Framework Network Security: the user security configuration file for .NET 2.x


A useful configuration tool named Microsoft .NET Framework x.x Configuration can be found in the Control Panel under Administrative Tools.


.NET Framework Network Security: Microsoft .NET Framework <version> Configuration tool accessed from the Administrative tools


.NET Framework Network Security: the .NET Framework 2.0 Configuration utility GUI


.NET Framework Network Security: the tasks that can be carried out using the .NET Framework 2.0 Configuration utility


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. Do not edit the config file manually.


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.




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


All Code

Identifies any assembly

Application Directory

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


Allows you to develop a custom method to identify assemblies


Identifies an assembly with a unique hash key


Identifies an assembly using a certificate


Identifies an assembly by the site portion of a URL

Strong Name

Identifies an assembly using a public security key


Identifies an assembly by a URL


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.



.NET Framework Network Security: the Code Groups of the .NET framework Security


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.


.NET Framework Network Security: the trusted sites settings accessed from the Internet Options page of the Internet Explorer, a crap product full of bugs


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.





Controlling Socket Applications


CAS can be applied to running socket applications. This is important because a socket application potentially can talk with any network application on the Internet. Fortunately, CAS allows you to control how applications use sockets and Domain Name System (DNS) on your computer.


Socket Permissions


As we have seen, the .NET Framework provides CAS for the Socket class. Running a server requires having the Socket Access Accept permission in order to create a listening socket that can receive connections from a network. Running a client application requires the Socket Access Connect permission to connect a remote socket. These permissions apply to all instances of the Socket class, including Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). Having CAS on sockets helps prevent random applications from using network sockets. In version 1.1 of the .NET Framework, both the Socket Access Accept and Connect permissions are granted only to applications run in the My Computer zone. Code executed from other zones will result in a System.Security.SecurityException being thrown.


DNS Permissions


Most socket applications require DNS service to resolve names to network addresses when setting up network communication. Since DNS is designed to communicate over a network, CAS permissions are also required to allow an application to query DNS. You can configure the .NET Framework to either allow or deny assemblies to query DNS using the DNS CAS permission.


DNS Spoofing


Using DNS to resolve host names in your application can be hazardous because names in DNS can be spoofed by an attacker. DNS spoofing is an attack on a DNS server where an attacker fools a DNS system into believing a domain name is something other than it really is. As a result, you should be aware that DNS spoofing can cause your application to connect to another host that you do not intend to connect to.


< Chap 12 TOC: .NET Framework Network Security | Main | Various Security Options & Implementations >