Module 10: Securing Windows Forms Applications

Module 10: Securing Windows Forms Applications

Contents Overview 1 Lesson: Security in the .NET Framework 2 Lesson: Using Code Access Security 14 Lesson: Using Role-Based Security 29 Review 40 Lab 10.1: Adding and Testing Permission Requests 42 Course Evaluation 46 Module 10: Securing Windows Forms Applications

Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

 2002 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, Windows, Windows NT, Active X, Authenticode, FrontPage, IntelliSense, MSDN, PowerPoint, Visual Basic, Visual C#, Visual Studio, Win32, and Windows Media are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Module 10: Securing Windows Forms Applications iii Instructor Notes This module starts with an overview of the Microsoft® .NET Framework security model. In this module, students learn how to use code access security and role-based security in their applications.

After completing this module, students will be able to:  Describe the .NET Framework security model.  Use code access security to secure an application.  Use role-based security to control access to an application. To teach this module, you need the Microsoft PowerPoint® file 2555A_10.ppt. To prepare for this module:  Read all of the materials for this module.  Review the animation for this module.  Complete the demonstrations, practice, and lab. Presentation: 75 minutes Lab: 30 minutes Required materials Preparation tasks

iv Module 10: Securing Windows Forms Applications How to Teach This Module This section contains information that will help you to teach this module.  If students are interested in referencing code examples in other languages, point them to “Language Equivalents” in the Microsoft Visual Studio® .NET Help documentation. This section provides examples in languages such as Microsoft Visual Basic® .NET, C#, and Java.  The lab at the end of this module is based on the Expense Report application in Course 2555A, Developing Microsoft .NET Applications for Windows (Visual C# .NET), and is intended to simulate a “real world” environment in which students will demonstrate what they learned during the lecture and practice portions of the module.

The lab does not provide step-by-step detailed instructions; instead, the students are given tasks to complete in the left column, and a list of resources that they can use (if they need help) in the right column. Students get hands-on experience that they need by completing the practice activity in the module.

Lesson: Security in the .NET Framework This section describes the instructional methods for teaching this lesson. This is an overview lesson. The main point of this lesson is to introduce the key concepts that will help students understand how the .NET Framework security model works. The other two lessons in the module cover the details of how to implement code access and role-based security in applications. Do not go into implementation details in this overview lesson. This topic defines code access security and presents an overview of how the .NET Framework uses security policy to map evidence about an assembly to a set of permissions for that assembly.

Point out the note regarding .NET Framework Service Pack 1.

In this animation, students see an example of how the permission grant for a Microsoft .NET Framework assembly is determined based on evidence and policy levels. This is a good time to check to make sure that students understand the key elements of code access security. This topic defines role-based security and the concepts of identity and principal. This topic defines authentication and provides some examples of authentication authorities. This topic defines authorization. Emphasize to students that there is an order relationship here: authentication is first, then authorization. How Does Code Access Security Work? Animation: Code Access Security What is Role-Based Security?

What is Authentication? What is Authorization?

Module 10: Securing Windows Forms Applications v Lesson: Using Code Access Security This section describes the instructional methods for teaching this lesson. This topic covers permission requests and why developers should use them in their applications. Stress to students that the .NET Framework applies the security policy to all applications whether they make permission requests in their applications or not. The motivation for adding permission requests to applications is to document what permissions the application needs and to test them in the different deployment situations.

This helps a developer to discover where to add additional exception handling related to permission request failures while the application while is still in the development phase instead of after it has been deployed.

This demonstration shows students how to use the .NET Framework configuration Microsoft Management Console (MMC) snap-in to view and modify security policy on their computers. This is useful so students can set up test environments for applications they are developing. This topic covers how to use Code Access Security tool (Caspol.exe) which is a command-line based utility for viewing and manipulating security policy. Caspol.exe is an alternative utility that students can use to set up test environments for applications they are developing.

Lesson: Using Role-Based Security This section describes the instructional methods for teaching this lesson.

To provide a transition from the previous lesson and this one, you can remind students that code access security controls what resources certain sections of code in their application can access and that role-based security allows developers to limit which users can run certain parts of an application. The main thing to emphasize in this lesson is the flexibility that role-based security provides and the benefit that much of the infrastructure required for security checking is provided by the .NET Framework, which simplifies the developer’s work.

This topic provides more detail about the types of principals and identities that can be used to implement role-based security. In this topic, students learn how to use the IsInRole method of the Principal object to control access to an application. In this demonstration, students follow the flow of an application in the debugger to see how an application implements role-based security. How to Use Code Access Security Demonstration: Administering Security Policy Settings How to Test the Code Access Security of an Application How Role-Based Security Works How to Use Principals and Identities to Control Access to an Application Demonstration: Using Role-based Security to Control Access to an Application

vi Module 10: Securing Windows Forms Applications Lab: Adding and Testing Permission Requests  Ensure that you have demonstrated the lab application Expense Report Application in Course 2555A, Developing Microsoft .NET Applications for Windows (Visual C# .NET), before students attempt the lab. To see how to demonstrate the lab scenario, see Module 0 in Course 2555A, Developing Microsoft .NET Applications for Windows (Visual C# .NET).  The practice exercise will enable students to successfully complete the lab exercise. Therefore, ensure that students have completed the practice exercise.

Module 10: Securing Windows Forms Applications 1 Overview  Security in the .NET Framework  Using Code Access Security  Using Role-Based Security * * ILLEGAL FOR NON-TRAINER USE * * The Microsoft® .NET Framework provides many new features to secure an application.

In this module, you will learn about the .NET Framework security model and learn how to use .NET Framework security features in your applications. After completing this module, you will be able to:  Describe the .NET Framework security model.  Use code access security to secure an application.  Use role-based security to control access to an application. Introduction Objectives

2 Module 10: Securing Windows Forms Applications Lesson: Security in the .NET Framework  Security Basics  What is Evidence?  What are Permissions?  How Does Code Access Security Work?  Animation: Code Access Security  What is Role-Based Security?  What is Authentication?  What is Authorization? * * ILLEGAL FOR NON-TRAINER USE * * The Microsoft Windows® 2000 security model protects a system by preventing unauthorized users from accessing that system. The security model in the .NET Framework protects application code and data from being misused or damaged by other code by enforcing security restrictions on managed code.

The .NET Framework security model is based on type safety, code signing, encryption of data, code access security, role-based security, and isolated storage. In this lesson, you will learn about the .NET Framework security model. After completing this lesson, you will be able to:  Define evidence and describe its role in the security system in the .NET Framework.

 Define Authentication and Authorization and describe their roles in the security system in the .NET Framework.  List the major characteristics of code access security and role-based security.  Describe the .NET Framework security model. Introduction Lesson objectives

Module 10: Securing Windows Forms Applications 3 Security Basics  Code access security Permissions granted to code based on:  Evidence  Permissions and permission sets  Security policy  Role-based security Permissions granted to users based on:  User name  Roles Windows group(s) Generic and custom principals and identities Microsoft .NET Passport * * ILLEGAL FOR NON-TRAINER USE * * Two important aspects of the .NET Framework security model are code access security, which controls what resources your code can access, and role-based security, which allows developers to limit which users can run certain parts of an application.

The .NET Framework code access security model allows code to use protected resources only if it has permission to do so. This is implemented by using the concept of permissions, which represent the right for code to access protected resources. Evidence about an assembly is used to grant code a set of permissions based on security policy. When code accesses resources to perform a task, a demand for the permissions it needs is made, and the .NET Framework security system determines whether all of the callers to that code have been granted the permissions being demanded.

The .NET Framework includes support for role-based security.

This allows code to determine the identity and role membership for the user of an application and make access decisions based on identity. For more information about building secure applications, see Writing Secure Code, by Howard, Michael, and David LeBlanc. Redmond, WA: Microsoft Press, 2002. Introduction Code access security Role-based security

4 Module 10: Securing Windows Forms Applications What is Evidence?  A set of information about the identity and origin of an assembly  Used by the .NET Framework security system at load time to determine the permissions that an assembly receives based on existing security policy  Examples of items that make up evidence  Strong name signature, code publisher, location, and zone  Other custom-defined items  Strength of evidence * * ILLEGAL FOR NON-TRAINER USE * * The security system uses this evidence about the assembly to determine which permissions to grant it based upon existing security policy.

Evidence is a set of information about the identity and origin of an assembly. Evidence may include:  The assembly’s strong name, consisting of a unique public key, a simple name, and a version.

 The assembly’s publisher, from the Microsoft Authenticode® signature.  The zone from which the assembly originates, such as the local computer, intranet, or Internet zones.  The location from which the assembly originates, expressed as a URL, universal naming convention (UNC) path, or local computer folder.  The cryptographic hash of the assembly. The creator of an assembly can also include custom evidence with the assembly. This custom evidence is evaluated only if security policy is configured to use the custom evidence.

Some forms of evidence are stronger than others and can therefore be used to make more far-reaching security policy decisions.

Strong names, for instance, provide an extremely reliable form of evidence, because they are very difficult to falsify unless the publisher’s private key has been compromised. Authenticode signatures are also strong forms of evidence. Conversely, evidence such as an assembly’s zone or URL is weaker. Web sites can be hacked, and packets can be tampered with over the Internet. It is a risk to grant permissions based heavily on weaker forms of evidence. However, both strong and weak forms of evidence can be combined in an effective security policy.

Introduction Definition Examples Strength of evidence

Module 10: Securing Windows Forms Applications 5 What are Permissions? Examples of built-in permission classes UIPermission, PrintingPermission, WebPermission, IsolatedStorageFilePermission Code access permissions are the rights to access certain computing resources * * ILLEGAL FOR NON-TRAINER USE * * Code access permissions represent rights to access certain computing resources. Actions protected by permissions include reading and writing files on the file system, accessing environment variables, and making calls to ADO.NET for database access.

The .NET Framework has many built-in code access permission classes that are designed to protect access to system resources. The .NET Framework uses the built-in permission classes to protect system resources. You, as a developer, do not need to take any further action to use system resources, because the .NET Framework will make the appropriate security checks. The built-in permission classes are listed in the following table. Code access permission class Resource protected DirectoryServicesPermission Directory services DnsPermission DNS services EnvironmentPermission Environment variables EventLogPermission Event logs FileDialogPermission File dialog boxes in the UI FileIOPermission Files and folders on the file system IsolatedStorgeFilePermission Isolated storage MessageQueuePermission Message queues OleDbPermission Databases accessed by the OLEDB data access provider PerformanceCounterPermission Performance counters PrintingPermission Printers ReflectionPermission Type information at run time RegistryPermission Registry Introduction Example Built-in code access permission classes

6 Module 10: Securing Windows Forms Applications (continued) Code access permission class Resource protected SecurityPermission Execute code, assert permissions, call unmanaged code, skip verification, and other rights ServiceControllerPermission Running or stopping services SocketPermission Connections to other computers by means of sockets SqlClientPermission Databases accessed by the Microsoft SQL Server™ data access provider UIPermission Windows and other UI elements WebPermission Connections to other computers by means of HTTP In addition to the built-in permission classes, developers can add new permissions to the security system by implementing custom permissions.

Module 10: Securing Windows Forms Applications 7 How Does Code Access Security Work? Gather evidence for assembly Gather evidence for assembly Assign assembly to code group(s) Assign assembly to code group(s) Per assembly grant Assembly gets INTERSECTION of permission sets for all policy levels Per assembly grant Assembly gets INTERSECTION of permission sets for all policy levels Policy levels  Enterprise  Machine  User  Application domain (optional) Code Groups Repeat this same security check for all security policy levels Repeat this same security check for all security policy levels Each assembly in an application can have a different permission grant Assembly gets UNION of permission sets for its code groups Assembly gets UNION of permission sets for its code groups * * ILLEGAL FOR NON-TRAINER USE * * The .NET Framework enforces security restrictions on managed code.

Every assembly that is loaded is granted a set of permissions by the .NET Framework to access various system resources. A group of permissions is called a permission set. These permissions are based on security policy. The security policy uses evidence about an assembly to determine which permissions to grant that assembly. In other words, the .NET Framework uses security policy to map evidence about an assembly to a set of permissions for that assembly. A code group consists of a membership condition and a set of permissions that an assembly might be granted if it meets that membership condition.

The runtime evaluates the membership condition specified in the code group against the evidence about the assembly. If the assembly meets the membership condition, it is eligible to be granted the permission set associated with the code group. When an assembly meets the membership conditions for a code group, it is said to be a member of that code group.

As an example, the membership condition for a code group could specify that the publisher of an assembly is Microsoft. Therefore, any assembly published by Microsoft would satisfy the membership condition and be eligible to receive the permission set associated with the code group. This permission set could represent the right to access the C:\temp directory and the USERNAME environment variable, for instance. An assembly receives the union of permissions for all code groups to which it belongs. Introduction Code groups

8 Module 10: Securing Windows Forms Applications Security policy is organized into different policy levels: enterprise policy level, machine policy level, user policy level, and an optional application domain policy level.

Security Policy Levels Description Enterprise Enterprise-level policy is specified by the network administrator, and contains a code group hierarchy that applies to all managed code on the entire network. Machine Machine-level policy is specified by the local computer administrator, and contains the code group hierarchy that applies to all managed code on the computer. User User-level policy contains a code group hierarchy that applies to all managed code run by a particular user. Either the local computer administrator or the user sets user policies Application domain (optional) Application domain policy level is an optional level that provides isolation, unloading, and security boundaries for executing managed code.

A final permission grant is assigned on a per assembly basis, so each assembly in an application can have a different permission grant. The common language runtime provides a default security policy and uses the following named permission sets to implement that policy:  Nothing Provides code with no permissions. Code cannot run. Under default security policy, code in the untrusted zone gets this permission set.  Execution Provides permission for code to run only. Does not allow code to use any protected resources.

 Internet Allows code to execute, to create safe top-level windows and file dialog boxes, to make Web connections to the same site that the assembly originates from, and to use isolated storage with a quota.

Under default security policy, all code from the Internet and trusted zones receives this permission set. Service Pack 1 of the .NET Framework changes default security policy for code executed from the Internet zone. Under the new policy, code from the Internet receives no permissions by default.  LocalIntranet Allows code to execute, to create user interface elements without restrictions; to use isolated storage with no quota; to use DNS services; to read the USERNAME, TEMP, and TMP environment variables; to make Web connections to the same site the assembly originates from; and to read files in the same folder as the assembly.

Under default security policy, all code from the LocalIntranet zone receives this permission set. Security policy levels Default security policy Note