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 (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.
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.
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.
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.
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.
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.
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.
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.
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.
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.