List of Figures


Chapter 1: Understanding .NET Security

Figure 1.1: A view of the output from an IsInRole() method check
Figure 1.2: Managed files use a unique signature system that ensures their integrity.

Chapter 2: .NET Framework Security Overview

Figure 2.1: The method used to design an object determines the client access type.
Figure 2.2: Rely on the SecurityManager class to learn about code and user rights.
Figure 2.3: The sample program can encrypt and decrypt files using the Rijndael algorithm.
Figure 2.4: Although the encrypted file looks like garbage, it really does contain data.
Figure 2.5: The WinNT path tends to produce easy-to-read DirectoryEntry values.
Figure 2.6: LDAP paths tend to produce copmlex DirectoryEntry values that you'll need to clean up for user displays.
Figure 2.7: The LDAP output is more complete than the WinNT output, but requires more work as well.

Chapter 3: Avoiding Common Errors and Traps

Figure 3.1: Use enumerated types to eliminate data range problems whenever possible.

Chapter 4: .NET Role-Based Security Techniques

Figure 4.1: Code access permissions generally appear in XML format.
Figure 4.2: Even small security additions can greatly affect the execution of a program.
Figure 4.3: Add assembly level information to your application for general security needs.
Figure 4.4: Include declarative elements in your code when you want to control access to individual elements.
Figure 4.5: Add the .NET Framework Configuration Tool to your list of security aids.
Figure 4.6: Add or edit code groups using this help screen.
Figure 4.7: Use this dialog box to change the characteristics of a code group.
Figure 4.8: Define the permissions for your new permission set carefully to avoid security breaches.
Figure 4.9: Define the permissions for your new permission set carefully to avoid security breaches.
Figure 4.10: Use the information gathered from the Evidence property to validate objects loaded by your program.

Chapter 5: Policies and Code Groups in Detail

Figure 5.1: Employ various lists as needed to see a snapshot of the information on your system.
Figure 5.2: When adding a new group, CASPol asks whether you want to change the security policy.
Figure 5.3: Defining a new group adds the entry to the specified location in the group hierarchy.
Figure 5.4: Removing a group is relatively easy using CASPol, which makes the policy change notice more important.
Figure 5.5: Adding a permission lets you create custom setups for a code group.
Figure 5.6: Setting access permissions using a property changes the way CASPol makes the policy change.
Figure 5.7: Adding any assembly with a strong name to the Policy Assemblies list lets you reference that assembly.
Figure 5.8: Check for security errors in an assembly by using one of the resolve commands.
Figure 5.9: Depend on the .NET Wizards to help you make simple configuration changes.
Figure 5.10: Look for the default .NET Framework groups at the machine level.
Figure 5.11: Define a custom code group for specific situations where you don’t want any changes.
Figure 5.12: Use the strong name information from the component to create a strong name membership.
Figure 5.13: Signing the test program automatically adds it to the strongly named group.
Figure 5.14: Create the specialized XML used for security needs in the FromXml() and ToXml() methods.
Figure 5.15: Define the location of the XML file containing the new permission you want to create.
Figure 5.16: A view of the Permission Sets folder with custom permissions added.
Figure 5.17: Viewing the output of the named permission program shows custom permissions really work.

Chapter 6: Validation and Verification Issues

Figure 6.1: Security information in a .NET IL file is easily readable.
Figure 6.2: Reading what should be protected information is excessively easy in .NET.
Figure 6.3: Creating a disassembly of a .NET application lets you modify the code.
Figure 6.4: Casual crackers are unlikely to remain undetected during the standard CLR checks.
Figure 6.5: The initial Dotfuscator display shows that this product can perform a number of tasks.
Figure 6.6: Renaming all of the elements in your program makes it harder for crackers to locate specifics.
Figure 6.7: Reading the GUI generated XML files can help you build your own custom versions.
Figure 6.8: Building the application generates information on the Output tab and in the lower window.
Figure 6.9: Using Dotfuscator will make your code harder to read and interpret.

Chapter 7: .NET Cryptographic Techniques

Figure 7.1: Use the Certificate Authority console to view your certificates.
Figure 7.2: Use the Active Directory Users and Computers console to configure the CA.
Figure 7.3: Select the Default Domain Policy entry.
Figure 7.4: Choose the Automatic Certificate Request Settings entry.
Figure 7.5: Highlight the certificate you want to install automatically.
Figure 7.6: Selecting the User certificate is useless for a developer.
Figure 7.7: Wait for the ActiveX Control to download so you can see this form.
Figure 7.8: Validate the information for a class entry using the assembly folder information.
Figure 7.9: Viewing the output of the cryptographic program shows that the text is completely garbled.
Figure 7.10: Viewing the output of the cryptographic program shows that the text is completely garbled.
Figure 7.11: The Details tab of the Certificate dialog box provides interesting facts about the certificate and its origin.

Chapter 8: LAN Security Requirements

Figure 8.1: Make sure you start the Telnet service before you run the program.
Figure 8.2: The COM+ application setup for this example
Figure 8.3: Choose which users or groups will perform the task specified by the role.
Figure 8.4: Creating a typical role-based security setup
Figure 8.5: Set security at the application level before you can use role-based security.
Figure 8.6: You can use any roles that you’ve created for a COM+ application at all application levels.

Chapter 9: Web Server Security

Figure 9.1: The Directory Security tab contains three groups of security entries.
Figure 9.2: Check the authentication methods allowed by the Web server.
Figure 9.3: Verify that your test Web site is part of the Trusted zone for your browser.
Figure 9.4: Determining the ability of various authentication modules to use pre-authentication
Figure 9.5: Select the identity and scanning options for the test system.
Figure 9.6: Typical output from MBSA after a security scan
Figure 9.7: The IIS Lockdown Tool uses templates to make the configuration process easier.
Figure 9.8: Use the supplied template screens to customize the template configuration.
Figure 9.9: Use a performance counter to help detect DDOS attacks.

Chapter 10: Web Data Security

Figure 10.1: Ensure you eliminate the MSADC folder on your server unless you actually need it.
Figure 10.2: The Regular Expression Editor helps you choose a predefined expression or create one of your own.
Figure 10.3: IIS errors such as this one become common after an IIS Lockdown Tool session.
Figure 10.4: Make certain you add the groups you create to SQL Server.
Figure 10.5: Add validators to any Web page that requires user input of any kind.
Figure 10.6: Test the reality of using remoting by turning the listener off and clicking Test on the client.
Figure 10.7: Make sure you can add SSL from the current location by looking at the Server Certificate button.
Figure 10.8: Select a client authentication certificate.
Figure 10.9: Choose the client authentication option.
Figure 10.10: Typical certificate information you can use to validate a Web site caller.

Chapter 11: Securing XML and Web Services

Figure 11.1: Attributes don’t work very well for Web service security needs.
Figure 11.2: Use imperative security as needed to address Web service requirements.
Figure 11.3: The input document is a basic XML file.
Figure 11.4: Creating a signed document means no one can change the content without also changing the signature.
Figure 11.5: Use the Web Services Enhancements Settings dialog box to make configuring WSE easier.
Figure 11.6: Adding support for SOAP to your COM+ application is relatively easy.
Figure 11.7: Setting the SOAP support options automatically creates some application files for your IIS setup.
Figure 11.8: The WSDL output of the Web page describes the class and the functionality it provides.
Figure 11.9: The Add Web Reference dialog box can help you locate and use services.
Figure 11.10: Web services set up through COM+ retain COM+ security features.

Chapter 12: Active Directory Security

Figure 12.1: The New Object dialog box enables you to create a connection to the server.
Figure 12.2: Opening a new object browser allows you to see the Active Directory schema for your server.
Figure 12.3: Some containers and leaf objects provide special buttons that help you perform tasks.
Figure 12.4: Use the WinNT path to access hard to read information.
Figure 12.5: A typical view of the ADSIEdit too
Figure 12.6: Using PInvoke can help you learn a lot about the domain controller.
Figure 12.7: The WinNT path tends to produce easy-to-read DirectoryEntry values.
Figure 12.8: The LDAP output is more complete than the WinNT output, but requires more work as well.

Chapter 13: Wireless Device Security

Figure 13.1: Use the display option settings to filter the output of the Class Library Comparison Tool.
Figure 13.2: Display an individual class and you see how the two frameworks compare.
Figure 13.3: Locate the Settings.TXT file in the MyDevice folder so you can change the hash value.
Figure 13.4: Throwing a security exception when the hash values don’t match alerts the user to the problem.
Figure 13.5: The wireless device user will see a message similar to this one when an application hash error occurs.
Figure 13.6: Use filters to define custom setups based on the caller type.
Figure 13.7: Use property overrides to change the page appearance and functionality.

Chapter 14: Win32 API Overview

Figure 14.1: The Advanced features of the Access Control Editor provide the administrator with full access control.
Figure 14.2: Each of the security templates contains the same security elements.

Chapter 15: Win32 API Advanced Techniques

Figure 15.1: Windows NT–based systems can support up to 28 privileges.
Figure 15.2: Verify the program worked by checking the advanced security settings for the selected file.
Figure 15.3: The example application will tell you who owns a particular file.




.Net Development Security Solutions
.NET Development Security Solutions
ISBN: 0782142664
EAN: 2147483647
Year: 2003
Pages: 168

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net