.NET Framework 2.0 Security Inspection Questions - What's New in 2.0

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Jason Taylor, Rudolph Araujo


Contents

What's New in 2.0

This section describes the most important changes in .NET Framework 2.0 that you should be aware of when you perform a security code review. The main changes include:

  • Security Exception. The SecurityException object has been enhanced to provide more information in the case of a failed permission.
  • DPAPI managed wrapper. .NET Framework 2.0 provides a set of managed classes to access the Win32 Data Protection API (DPAPI). This makes it easier to secure sensitive data in memory when you write managed code. You no longer need to use P/Invoke. Code requires the new DataProtectionPermission to be able to use DPAPI.
  • XML Encryption. The EncryptedXML class can be used to secure sensitive data, such as database connection strings, that must be stored on disk.
  • SecureString. This new type uses DPAPI to ensure secrets stored in string form are not exposed to memory or disk sniffing attacks.


Use the following questions to make sure that the code uses the new .NET Framework 2.0 features properly:

  • Does the code take advantage of the improvements to SecurityException?
  • Does the code use DPAPI to protect sensitive data in memory?
  • Does the code use EncryptedXML to store sensitive data on disk?
  • Does the code ensure that SecureStrings are not passed unnecessarily as regular strings?


Does the code take advantage of the improvements to SecurityException?

If your application is running in a partial trust environment, use the SecurityException object to gracefully handle permission request failures. The following table shows the properties on this object that make debugging security issues easier.

SecurityException Object Properties

Name

Type

Description

Action

SecurityAction

The SecurityAction that failed the security check.

Demanded

Object

The permission, permission set, or permission sets that were demanded and triggered the exception.

DenySetInstance

Object

If a Deny stack frame caused the security exception to fail, then this property will contain that set; otherwise it will be null.

FailedAssemblyInfo

AssemblyName

AssemblyName of the assembly that caused the security check to fail.

FirstPermissionThatFailed

IPermission

The first permission in failing PermissionSet (or PermissionSetCollection) that did not pass the security check.

Method

MethodInfo

The method that the failed assembly was in when it encountered the security check that triggered the exception. If a PermitOnly or Deny stack frame failed, this will contain the method that put the PermitOnly or Deny frame on the stack.

PermitOnlySetInstance

Object

If the stack frame that caused the security exception had a PermitOnly permission set, this property will contain it, otherwise it will be null.

Url

String

URL of the assembly that failed the security check.

Zone

SecurityZone

Zone of the assembly that failed the security check.


Does the code use DPAPI to protect sensitive data in memory?

If your application is manipulating sensitive data, it should use DPAPI to store the data in encrypted form. Encrypting sensitive data until it is used reduces the chances that it will be stolen out of memory. DPAPI is now accessible through the System.Security.Cryptography.ProtectedMemory class.


Does the code use EncryptedXML to store sensitive data on disk?

If your application stores sensitive information, such as database connection strings, on disk in XML format, it should use the System.Security.Cryptography.XML.EncryptedXML class to protect the information. Encrypting sensitive information when it is stored on disk reduces the chances that it will be stolen.


Does the code ensure that SecureStrings are not passed unnecessarily as regular strings?

SecureString protects sensitive data only if the data is never stored as a string. Avoid storing sensitive data as a string if possible because a string is immutable (read-only). Each time you change the value of a string, the original value of the string is kept in memory along with the new value. If sensitive data is stored in memory as a string and then is encrypted, the original string in memory could still be stolen. The best way to make sure that a string in memory cannot be stolen is to make sure it is only stored with SecureString.

Personal tools