Introduction to Security In Windows Forms
In the past, all code running on your computer had the same rights or permissions to access resources that you did as a user of the computer. For example, if you were allowed to access the file system, that code was allowed to access the file system; if you were allowed to access a database, that code was allowed to access that database. Although this may be acceptable for code in executables that you have explicitly installed on your local machine, it may not be acceptable for all code running on your machine - for example, code coming from the Internet should not be able to access the files on your hard disk unless you explicitly allow it to.
The .NET Framework introduces an infrastructure called Code Access Security that allows you to differentiate the permissions, or rights, that code has from the rights that you have. For example, by default, code coming from the Internet can only access a pre-defined portion of your hard disk. (This portion is called isolated storage. For more information on isolated storage, see Introduction to Isolated Storage.) The .NET Framework controls the resources that code is allowed to access based on the identity of that code -where it came from, whether it has a strong name, whether it is signed with a certificate and so on.
To provide the best possible user safety while enabling meaningful application functionality, Windows Forms provides alternative, more secure ways to implement features when your application has fewer permissions.
Understanding Security in the .NET Framework
Code access security allows code to be trusted to varying degrees, depending on where the code originates and on other aspects of the code's identity. For more information on the evidence the common language runtime uses to determine security policy, see Evidence. It protects computer systems from malicious code and protects trusted code from intentionally or accidentally compromising security. Code access security also gives you more control over what actions your application can perform, because you can specify the set of permissions you would like to have granted to your application and the set of permissions you do not want your application to have. Code access security affects all managed code that targets the common language runtime, even if that code does not make a single code-access-security pemission check. For more information about security in the .NET Framework, see Key Security Concepts and Code Access Security Basics.
Now let's shift focus from code running on your machine to code you write that runs on other's machines. The degree of trust granted to your application depends upon where the code resides, and how it is started. When an application runs, it is automatically evaluated and it receives a named permission set from the runtime. By default, the code from the local computer is granted the Full Trust permission set, code from a local network is granted the Local Intranet permission set, and code from the Internet is granted the Internet permission set. (In .NET Framework 1.0 Service Pack 1 and Service Pack 2, the Internet zone code group receives the Nothing permission set. In all other releases of the .NET Framework, the Internet zone code group receives the Internet permissions set.) The default permissions granted in each of these permission sets are listed in the Default Security Policy topic. Depending on the permissions that the application receives, it either runs properly or generates a security exception. The actual permissions granted to your application can be different than the default values, because the security policy can be modified; this means that your application can have permission on one computer, but not on another.
Writing Your Windows Forms Application
Security is important in all steps of application development. Start by following the Secure Coding Guidelines. Next, decide how you want your application to behave when it runs in a semi-trusted, or less than full trust, environment. Windows Forms provides alternative, more secure ways to implement features when in a semi-trusted environment. Certain parts of your application, for example persistence of settings, can be designed and written differently for semi-trusted environments and fully-trusted environments.
The following topics describe these Windows Forms security features:
- Secure File and Data Access in Windows Forms
Describes how to access files and data in a semi-trusted environment.
- Secure Printing in Windows Forms
Describes how to access printing features in a semi-trusted environment.
- Additional Security Considerations in Windows Forms
Describes performing window manipulation, using the Clipboard, and making calls to unmanaged code in a semi-trusted environment.
Developing Your Application
As you add features to your application, your need for certain security permission may increase. When writing your application, you should keep track of what permissions your application needs to run and what permissions your application could optionally use. When all the permissions are known, you should make a declarative request for permission at the application level. Requesting permissions informs the .NET Framework run time about which permissions your application needs and which permissions it specifically does not want. For more information about requesting permissions, see Requesting Permissions and Permission Requests.
When requesting optional permissions, you must handle security exceptions that will be generated if your application performs an action that requires permissions not granted to it. Proper handling of the SecurityException will ensure that your application can continue to operate. Your application can use the exception to determine whether a feature should become disabled for the user. For example, an application can disable the Save menu option if the necessary file permission is not granted.
Requesting More Permissions for Your Application
When running in a semi-trusted environment, your application might not be granted the permissions it needs. In some cases, the only way to get the functionality you desire will be to elevate permissions for your application. Elevating permission is a task that must be done by an administrator at the Network, computer, or user level.
There are three basic steps involved:
- First, evaluate the instances your application will need to diverge from the default security policy, because elevating permissions should be done with care. For more information, see Determining When to Modify Security Policy.
- Next, you need to think about increasing the permissions granted to the application's assemblies. For more information, see Increasing Permissions.
- Finally, investigate the best method for deploying security policy changes. For more information, see Deploying Security Policy.For more information about elevating permissions and policy administration, see Code Access Security and ADO.NET.
Testing Your Application
You should test your application to see how it behaves when running in different code group zones. To test your application in the Local Intranet zone, access your computer using a Universal Naming Convention (UNC), such as \\ServerNameHere\ShareNameHere, to start your application. To test your application in the Internet zone, access your computer using its IP address, such as \\127.0.0.1\ShareNameHere, to start your application.