Implementing application security using the .net framework

Editor's Notes

• #2: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.
• #3: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. In this agenda topic, we will introduce application security by using the Microsoft® .NET Framework. Specifically, we will discuss: .NET Framework security features. Code access security. Role-based security. Cryptography. Securing Microsoft ASP.NET Web applications. Securing ASP.NET Web services.
• #4: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.
• #5: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. In this agenda topic, we will introduce the .NET Framework security features. Specifically, we will discuss: .NET managed execution. A type-safe system. Buffer overrun protection. Arithmetic error trapping. Strong-named assemblies. Isolated storage.
• #6: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. The .NET common language runtime controls the execution of .NET code. The .NET Framework security system is part of the common language runtime. The .NET Framework includes many features that you will learn about in this presentation, such as type checking for safe type-conversions, secure exception management, and code access security control. .NET Framework security is designed to complement the security provided by Microsoft Windows®. It does not override Windows-based security. For example, if a Windows access control list (ACL) restricts access to a file, the .NET Framework does not override this security.
• #7: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. Type-safety verification is the cornerstone of .NET Framework security because it prevents access to unauthorized memory locations. This allows you to consistently enforce security policy. For example, code cannot overrun a buffer and cause execution to jump to an arbitrary memory location. Type-safety verification allows the common language runtime to run more than one type-safe assembly in the same process. These sub-processes are called application domains. Application domains are especially useful in server scenarios in which the overhead of using many processes may slow system performance. In the past, the use of dynamic-link library (DLL)-based components was preferred for efficiency reasons, because EXE-based components were seen to be more secure and robust (due to the Microsoft Win32® virtual address space architecture). However, .NET supports the concept of an App Domain. An App Domain can be thought of as a process within a process, which provides good performance (like a DLL-based component), excellent security, and robustness.
• #8: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. Managed code typically does not deal with raw pointers (such as a char *). Instead, the .NET runtime uses classes such as System.String and System.Text.StringBuilder , which are managed by .NET type-verification checks. A String is an immutable object, which vastly alleviates the buffer overrun issue. Consider the following code: void CopyString (string src) { stringDest = src; } When the code executes, a new resultant string object will be created, and the reference stringDest will be altered to refer to that string. Therefore, a buffer overrun is not possible. Another string class found in the .NET Framework is StringBuilder. StringBuilder is also a robust class and will throw an exception if an attempt is made to overwrite its internal buffer.
• #9: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. Trapping arithmetic errors in unmanaged code (for example, Visual C++) is very difficult. However, with managed code, spotting arithmetic runtime errors is easier. For example, the Visual C# compiler enables automatic checking for arithmetic overflows and underflows. By default, the arithmetic error trapping feature is turned off (for optimization reasons). However, you can easily turn on this feature either from the project properties or by using the checked keyword in your code. If you have turned arithmetic checking on at the project level, you can override the settings by using the unchecked keyword in your code. This is useful if you are certain that arithmetic errors cannot occur in specific blocks of code and you want to optimize those blocks when your code is compiled.
• #10: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. In this demonstration, you will see: How .NET data-type safety works. How to use the checked keyword.
• #11: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. Strong names are unique identifiers for your assemblies. You can generate strong names and then use them to digitally sign your assemblies. Strong-naming solves problems (such as version control and backward compatibility issues) that are caused when components are shared by multiple applications. In effect, strong names associate a distinct build of a component assembly with the client application. A distinct build is indicated by a combination of a version number and a special value that is called the publicKeyToken. You can generate a public/private key pair for signing your assembly by using the Strong Name tool (Sn.exe). When you have a private key, you can specify the key file and the version number to be assigned when you compile the assembly, using attributes as shown: [assembly: System.Reflection.AssemblyVersion("1.0.0.0")] [assembly: System.Reflection.AssemblyKeyFile("orgKey.snk")] A strong-named assembly prevents attackers from tampering with the assembly's code, and allows confirmation of the assembly publisher's identity. Strong-named assemblies also allow side-by-side components to co-exist, which aids version control and backward compatibility.
• #12: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. For some applications, such as downloaded Web applications and code that may come from sources that are not trusted, the basic file system does not provide the necessary isolation and safety. Isolated storage is a data storage mechanism that provides isolation and safety by defining standardized ways of associating code with saved data. Administrators can use tools that are designed to manipulate isolated storage to configure file storage space, set security policies, and to delete unused data. With isolated storage, developers no longer have to invent unique paths to specify safe locations in the file system. Developers can now access safe locations by using either the application's identity or the user's identity. The code sample on the slide show an example of how to access the isolated storage based on a user's identity.
• #13: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. In this agenda topic, we will introduce code access security. Specifically, we will discuss: Evidence-based security. Security policies. Security checks. Using security checks. Permission requests. Partial trust applications. Sandboxing privileged Code.
• #14: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. Win32 security works on the principal of user authentication and authorization. For example, if a user places a floppy disk into the computer, lists the directory, and chooses to execute the file ‘trustme.exe’, the operating system will oblige, and run the application in the security context of the logged on user. Therefore, the application (which may be malicious) will have all of the system privileges granted to the user in question. .NET provides you with the concept of evidence-based security. This security works on top of Win32 security; it does not replace it. Irrespective of the logged on user, the .NET Framework collects evidence about an assembly and presents it to the security system. After the evidence has been gathered, the runtime will decide on whether or not the code will be allowed to complete all of the tasks that it requests. Some evidence is considered stronger by the runtime than other evidence. For example, strong names and Authenticode signatures are considered stronger than URL or zone evidence, because it is more difficult for an attacker to fake values for these elements. Developers can create their own unique evidence. For example, they can create evidence that indicates an assembly was developed internally and reviewed by the IT department for security flaws.
• #15: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. In contrast to many security systems, the .NET Framework security policy is based on assembly identity, rather than user identity. Security policies map assembly evidence to permissions that are granted for that assembly. Security policies use code groups and policy levels to achieve this mapping. The .NET Framework includes multiple levels of policy configuration, including enterprise, machine, and user settings. Developers use an intersection of different policy settings when determining permissions. Code groups and policy levels give administrators fine-grained control over security policy. Administrators can configure policies to grant a set of permissions for the assembly based on a variety of evidence. Administrators can use Active Directory to ease the deployment of security policies.
• #16: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. When the code accessing a protected resource demands a permission, a stack walk is performed. The security system checks the permission granted to each caller. If each caller is granted the permission, the demand succeeds, otherwise a security exception is thrown. This approach prevents an assembly without permissions, using your assemblies to perform unauthorized actions.
• #17: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. Imperative security checks involve creating instances of Permission objects at run time and invoking methods on them, such as the Demand method. For example, the developer may create an instance of the FileIOPermission object, and demand the Read permission for a specific file. If the call to the Demand method succeeds, execution continues, otherwise, a security exception is thrown. With declarative security checks, permissions are specified by using attributes instead of creating Permission objects at run time. At design time, developers specify permissions (such as the FileIOPermission Read access permission for a specific file) by including the attributes in class definitions or individual methods. Although the same types of permission can be managed as with the imperative approach, the declarative process makes it easier to review the required permissions for a class or method. However, because the permissions apply only to classes or methods, this approach is slightly less flexible than imperative checking. While obtaining evidence for both imperative and declarative security checks, the runtime will walk the stack, assuring that less privileged code further up the stack is not trying to execute code for which it does not normally have permission. However, you can use the Assert method to change the behavior of the stack walk. When the method in which you call Assert is reached, the stack walk stops. This means that permissions for the callers of your code are not checked. The Assert method is most useful when your code needs access to a protected resource, but your code does not give access to that resource to its callers.
• #18: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. Developers use permission requests to state the permission requirements of their assemblies. Permission requests are implemented as assembly attributes. Using permission requests makes it easier to run code with least privilege. If an assembly does not receive its minimum permission request at load time, it does not load, rather than waiting until an unauthorized operation is attempted and then failing. In the slide example, an assembly requests the Unmanaged code permission. If that permission is denied at load time, the assembly will not continue.
• #19: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. In this demonstration, you will see how to: Use the .NET Framework Configuration Tool to configure permissions. Perform security checks in your code. Requesting permissions for your code.
• #20: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. Prior to the .NET Framework 1.1, all ASP.NET Web applications ran with full trust, which meant that code access security could not be applied to them. The .NET Framework 1.1 allows an administrator to define the trust levels for all Web applications within the machine.config file, thereby gaining control on what code access is available. Five trust levels are available, as follows: Full . Unrestricted permissions enable applications to access any resource that is subject to operating system security, and all privileged operations are supported. High . Cannot call unmanaged code, message queues, serviced components, or OLE DB data sources. Medium . Can only access its own directory structure, and cannot access the registry. Low . Cannot access Microsoft SQL Server™, and no assertion permission. Minimal . Execute permission only. Each of these trust levels can be customized with its own .config file.
• #21: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. Rather than allowing a whole application maximum privileges, it is possible to sandbox privileged code while retaining partial trust for the Web application as a whole. The .NET sandboxing approach is as follows: Encapsulate the resource access in a wrapper assembly. Demand and then assert the relevant permission prior to accessing the resource. Add the AllowPartiallyTrustedCallersAttribute to the assembly. This is necessary to allow it to be called from a partial-trust Web application. Install the wrapper assembly in the global assembly cache (GAC). This automatically assigns the assembly full trust. Configure the Web application to use an appropriate trust level.
• #22: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. In this agenda topic, we will introduce role-based security. Specifically, we will discuss: Authentication and authorization. Identities and principals. Creating Windows identities and principals. Creating generic identities and principals. Performing security checks. Imperative and declarative security checks.
• #23: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. Authentication is the process of obtaining identification credentials, such as a name and a password, from a user and then validating those credentials against some authority, such as a database. If the credentials are valid, the entity that submitted the credentials is considered an authenticated identity. For example, all users must provide a user name and password every time they log on to a network. These credentials are then validated against an authority, such as a database or a Windows-based domain server. After an identity has been authenticated, the authorization process determines whether that identity has access to a specified resource. The authorization process limits access rights by granting or denying specific permissions to an authenticated identity. For example, you can authorize one user to access the color printer, but deny access to another user. Similarly, you can authorize only the users of a group to access the color printer and deny access to the rest of the users. Role-based security in the .NET Framework mostly involves authorization.
• #24: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. An identity contains information about the user’s identity, such as their logon name and whether the user is authenticated. A principal contains information about the role membership for a user or computer. The .NET Framework implements two major types of identities and principals. WindowsIdentity and WindowsPrincipal objects provide information about the Windows credentials for a user. GenericIdentity and GenericPrincipal objects enable the developer to implement their own authentication technique. The following slides show how to create Windows and Generic principals and identities, and then demonstrates how to use them to make role-based security checks.
• #25: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. You can create Windows identities and principals for users based on their Windows credentials. You can use either of the approaches that are shown on the slide to achieve this, but the first code sample is more efficient, if the principal and identity are retrieved for a single check, whereas the second sample is more efficient if multiple checks will be made. After you have created Windows identities and principals, you can use them to perform security checks.
• #26: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. Creating GenericIdentity and GenericPrincipal objects is useful when you want to implement custom authentication techniques, such as finding credentials in a database, rather than perform authentication based on a user's Windows credentials. The slide shows sample code for creating Generic identities and principals. After you have created generic identities and principals, you can use them to perform security checks, as we will discuss next.
• #27: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. Now that you have seen how to create identities and principals, you can use them to perform security checks in your code. The slide demonstrates two examples. The first code example performs a case-insensitive string comparison of the current identity’s Name property and a hard-coded string. The second code example uses the IsInRole method to check role membership. In this example, the code checks whether the principal is a member of the built in Administrators group.
• #28: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. You can also use imperative and declarative approaches for role-based security checks. The first code sample on the slide uses an imperative security check to determine whether the active principal object's permissions match the permissions of the newly created prinPerm object. The call to the Demand method will throw a security exception if the permissions do not match. This approach is useful if you want to secure specific actions within your code. The second sample on the slide uses declarative security. The attribute shown can be applied to a class or an individual method, so that a security check is performed when the class or method is used. Although the same types of check can be performed as with the imperative approach, the declarative process makes it easier to review the required permissions for a class or method. However, because the checks apply only to classes or methods, this approach is slightly less flexible than imperative checking.
• #29: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. In this demonstration, you will see how to: Use Windows role-based security in your code. Use Generic role-based security in your code.
• #30: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. In this agenda topic, we will introduce cryptography. Specifically, we will discuss: Cryptography review. Symmetric encryption. Asymmetric encryption. Signing data.
• #31: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. Symmetric encryption enables you to encrypt and decrypt data by using a single secret key. If the secret key is compromised, all of the data that you used the key to encrypt can be decrypted. Asymmetric encryption enables you to encrypt and decrypt data with a public/private key pair. You can distribute the public key freely, but the private key must be kept secret. Data encrypted with the public key can be decrypted only with the private key and vice versa. Hashing is the process of mapping a longer string of data, such as a file, to a small string of data that is a fixed size, such as a 160-bit hash value. Digital signing is the process of encrypting a hash value with a private key and distributing this signature with the data. When a recipient receives the data, the recipient can decrypt the data with the sender’s public key and compare it with the hash value of the data. If the values match, the integrity of the data is guaranteed.
• #32: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. The basic steps for using symmetric encryption algorithms are: Choose the algorithm you want to use. The .NET Framework provides wrapper classes for working with symmetric encryption, such as the TripleDESCryptoServiceProvider the RijndaelManaged classes. Generate a secret key by using the .NET wrapper class that you have chosen. Symmetric algorithms require this key to encrypt and decrypt data. The class constructor can create these values or you can provide your own. Use the same key to encrypt and decrypt data. You can encrypt data by using any class that derives from the Stream class, including FileStream , MemoryStream , and NetworkStream .
• #33: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. The basic steps for using asymmetric encryption algorithms are: Choose the algorithm that you want to use. The .NET Framework provides wrapper classes for working with asymmetric encryption, such as the RSACryptoServiceProvider and the DSACryptoServiceProvider classes. These classes use the well-known algorithms after which they are named Generate public and private keys by using the .NET wrapper class that you have chosen. Asymmetric algorithms use a public key and a private key to perform cryptographic operations. Some operations, such as signature creation and decryption, require a private key. Other operations, such as signature verification and encryption, require a public key. Use the appropriate key when encrypting or decrypting data. For example, if you are encrypting data, you would use the public key, whereas if you are decrypting data you would use the private key. You can encrypt and decrypt data by using any class that derives from the Stream class, including FileStream , MemoryStream , and NetworkStream .
• #34: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. Signing data prevents tampering and asserts the identity of the signer. In some situations, you will want to sign data so that other's can be assured of your identity, whereas at other times, you will want to verify a signature so that you are sure that the data originated from a specific source. Signing data and verifying signatures involves: Signing Data . Hash the data, and then use an asymmetric algorithm to create a signature. Verifying the signature . Decrypt the signature, hash the data, and then use an asymmetric algorithm to verify the signature.
• #35: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. In this demonstration, you will see how to: Perform symmetric encryption on data. Sign data programmatically
• #36: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. In this agenda topic, we will focus on securing ASP.NET Web applications. Specifically, we will discuss: ASP.NET authentication types. Configuring forms-based authentication. Forms-based authentication enhancements. Validation controls. Types of validation controls.
• #37: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. ASP.NET supports three types of authentication method: Windows-based authentication Forms-based authentication Microsoft Passport authentication With Windows-based authentication, the ASP.NET Web application relies on the Windows operating system to authenticate the user. ASP.NET uses Windows-based authentication in conjunction with Internet Information Services (IIS) authentication. With Windows-based authentication, the user requests a secure Web page from the Web application, and the request then passes through IIS. If the user's credentials do not match those of an authorized user, IIS rejects the request. The user then has to enter his or her name and password in the logon form. The credentials are again verified by IIS. If these credentials are accepted, IIS directs the original request back to the Web application. The secure Web page is then returned to the user. Forms-based authentication involves non-authenticated requests being redirected to a Hypertext Markup Language (HTML) form. The user provides their credentials and submits the form. If the application validates the credentials on the form, the system issues an authentication cookie to the user. Subsequent requests from the user are issued with the authentication cookie in the request headers, and then the user is authenticated on that basis. You will see how to set up forms-based authentication in the next slide. You will then see the .NET enhancements that are associated with forms-based authentication. Passport authentication is a centralized authentication service, provided by Microsoft, which offers a single logon option and core profile services for member sites. Users who sign up to use Passport are authenticated by Web sites with a single Passport account. Microsoft Passport is an XML Web service, and is an integral part of the .NET Framework.
• #38: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. Configuring forms authentication for your .NET Web application involves the following four tasks: Configure IIS to use Anonymous authentication so that the user is authenticated by ASP.NET and not by IIS. Set the authentication method to 'Forms' for the application in an <authentication> subsection of the <system.web> section in Web.config, If you set the authentication mode to 'Forms', you must add a <forms> element to the <authentication> section, as shown in the slide example. In the <forms> section, configure the settings of the cookie. Set the name attribute to the suffix to be used for the cookies and the loginUrl attribute to the Uniform Resource Locator (URL) of the page to which unauthenticated requests are redirected. Set up the <authorization> section in Web.config to deny or allow users access to your Web application. You can also mark the entire Web application as needing authorization or specify authorization on a page-by-page basis. Build a logon Web Form. This can be a simple page with two fields for a user name and a password. The page requires the users to enter their user name and password to access to your Web application. Although you can perform these tasks in any order, ensure they are all completed before deploying your solution, otherwise forms-based authentication will not work.
• #39: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. By default, there is no requirement for the authentication cookie submitted by the client with each request to be encrypted. Encryption is normally performed by implementing SSL across the site; however, this is controlled by the site administrators, rather than developers. Developers can ensure that the cookie is encrypted by adding the attribute requireSSL=”true” to the <forms> element in the web.config file. This will set the HttpCookie.Secure property, such that compliant browsers will only return the cookie over SSL. One consideration with secure cookies is the use of validation and decryption keys. These can be automatically generated for the application. However, it is possible for the same key to be generated for several Web applications on the same computer. To avoid this, developers can use the IsolateApps parameter within the machineKey element in the web.config file.
• #40: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. Input validation can take place on both the server and the client. Client-side validation is an option with some browsers. The validation controls in ASP.NET have both client-side and server-side support. Client-side validation uses JavaScript and dynamic HTML (DHTML) scripts. Server-side validation can be written in any .NET-based language. Client-side validation enhances the usability of the Web Form by checking user input as the user enters data. By checking for errors when data is being entered, client-side validation allows errors to be detected on the client before the Web Form is submitted. Writing multiple versions of validation code to support both the server and several different browsers can be extremely time-consuming for developers. ASP.NET validation controls eliminate this problem because the validation logic is encapsulated within the controls. The controls create browser-specific code so that users with client-side script support will have client-side input validation. Browsers that do not support scripts will not receive client-side validation scripts. In browser versions that support input validation, such as Microsoft Internet Explorer 4 or later, client-side validation occurs when the user clicks the Submit button. The page will not be posted back to the server until all client-side validation is true. In Internet Explorer 5 or later, using the TAB key to move from one input control to the next runs the client-side validation for the completed input control. All input validation controls also run on the server side. Client-side validations are repeated on the server side when the page is posted back to the server. This repetition avoids attackers bypassing the client-side script and trying to use provide input.
• #41: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. The ASP.NET page framework includes a number of validation controls: The CompareValidator control compares an input control to another input control, a fixed value, a data type, or a file. The CustomValidator control allows you to write your own code to create the validation expression. For example, this control can be used to verify that the input value is a prime number. The RangeValidator control is similar to the CompareValidator control, but this control can verify that the user input is between two values or the values of other input controls. The RegularExpression control verifies that the entry matches a pattern that has been defined by a regular expression. For example, social security numbers, e-mail addresses, telephone numbers, and postal codes. The RequiredFieldValidator control checks whether a value has been entered into a control. This is the only validation control that requires a value. The ValidationSummary control displays a summary of all of the validation errors for all of the validation controls on the page. This control is typically placed near the Submit button to provide immediate feedback on the page input status.
• #42: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. In this demonstration, you will see how to: Configure forms authentication Use validation controls
• #43: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. In this agenda topic, we will focus on securing ASP.NET Web services. Specifically, we will discuss: Message-level security. Web Service Enhancements.
• #44: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. Message-level security applies to the contents of a Simple Object Access Protocol (SOAP) message. This is extremely useful for XML Web Services, because developers and administrators cannot usually secure both end-points in this type of communication, so the actual message itself needs securing. The World Wide Web Consortium (W3C) have defined a set of specifications called WS-Security, which describe enhancements to SOAP messaging. These specifications define message integrity, message confidentiality, and single message authentication for SOAP messaging. With message-level security, authentication is provided by security tokens, which flow in SOAP headers. The security tokens may include Kerberos tickets, X.509 certificates, or a custom binary token. Secure communication is provided by digital signatures to ensure message integrity and by XML encryption for message confidentiality. WS-Security can be used to construct a framework for exchanging secure messages in a heterogeneous Web services environment. It is ideally suited to heterogeneous environments and scenarios where you are not in direct control of the configuration of both endpoints and intermediate application nodes. Message-level security: Can be independent from the underlying transport. Enables a heterogeneous security architecture. Provides end-to-end security and accommodates message routing through intermediate application nodes. Supports multiple encryption technologies. Supports non-repudiation.
• #45: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. Web Services Enhancements for Microsoft .NET (WSE) is a set of tools that can be used to implement security within a SOAP message, rather than relying on security features of other protocols (such as SSL). Microsoft developed WSE to conform with the WS-Security standards. The main security-oriented features of WSE are: Authentication through SOAP headers. This is based either on Username tokens, which are defined in the WS-Security standard, or binary tokens, such as an X.509 Certificate token. On the server-side, you can implement your own mechanism for storing user names and passwords. Message encryption. This is implemented through input and output filters, which allows developers to use both the SOAPWebRequest and SOAPWebResponse, thereby applying whichever encryption mechanism they require to the messages. Message signing. This is a signature element generated from an X509 security token. The signature is added to the security header within the SOAP header. It is possible to control which parts of the header, body, and message the signature applies to. This is useful if the message is routed, because the routing process may modify parts of the header which would otherwise invalidate the signature. Attachments can also be secured with WSE. As a developer, you can access the WSE functionality by using classes exposed in Microsoft.Web.Services.dll.
• #46: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. In this demonstration, you will see how to: Implement security for a Web service.
• #47: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.
• #48: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. Next steps include going to the Microsoft Web site to: Get the latest security information. Get additional security training.
• #49: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. More technical information for IT professional and developers is available on the following Web sites: Microsoft Security Site (all audiences) http://www.microsoft.com/security MSDN Security Site (developers) http://msdn.microsoft.com/security TechNet Security Site (IT professionals) http://www.microsoft.com/technet/security
• #50: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.
• #51: MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.