.NET Framework 2.0 Security Guidelines

From Guidance Share

J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Chaitanya Bijwe

Contents 1 Assembly Design Considerations 2 Class Design Considerations 3 Strong Names 4 APTCA 5 Exception Management 6 File I/O 7 Registry 8 Communication Security 9 Event Log 10 Data Access 11 Delegates 12 Serialization 13 Threading 14 Reflection 15 Obfuscation 16 Cryptography 17 Sensitive Data 18 Unmanaged Code 19 Related Items 20 References

Assembly Design Considerations

• Identify your target trust environment
• Explicitly design your public interface

Class Design Considerations

• Restrict class and member visibility
• Consider using the sealed keyword
• Restrict access to your code
• Do not trust input
• Use properties to expose fields
• Use properties to expose fields
• Use read-only fields appropriately
• Use private default constructors to prevent unwanted object instantiation

Strong Names

• Evaluate whether you need strong names
• Do not expect strong names to make your assembly tamper proof
• Use delay signing appropriately
• Use .pfx files to protect your private key if you do not use delay signing
• Do not depend on strong name identity permissions in full trust scenarios

APTCA

• Avoid using APTCA
• Consider using SecurityTransparent and SecurityCritical

Exception Management

• Use structured exception handling
• Do not log sensitive data
• Do not reveal system or sensitive application information
• Consider exception filter issues
• Consider using an exception management system
• Fail early to avoid unnecessary processing that consumes resources

File I/O

• Avoid untrusted input for file names and file paths
• If you accept file names, validate them
• Use absolute file paths where you can
• Consider constraining file I/O within your application's context

Registry

• Consider using ACLs to restrict access to data stored in HKLM
• Consider encrypting sensitive data in the registry

Communication Security

• Consider transport-level encryption to protect secrets on the network
• If you use the TCP channel with .NET remoting, consider System.Net.Security.NegotiateStream

Event Log

• Do not log sensitive data
• Do not expose event log data to unauthorized users

Data Access

• Do not hard code connection strings
• Consider encrypting connection strings
• Prevent SQL injection

Delegates

• Avoid accepting delegates from untrusted sources
• Consider restricting permissions to the delegate
• Avoid asserting permissions before calling a delegate

Serialization

• Do not serialize sensitive data
• Validate serialized data streams

Threading

• Do not cache the results of security checks
• Avoid losing impersonation tokens
• Synchronize static class constructors
• Synchronize Dispose methods

Reflection

• Use full assembly names when you dynamically load assemblies
• Avoid letting untrusted code or data control run-time assembly load decisions
• Avoid letting untrusted code or data control Reflection.Emit
• Consider restricting the permissions of dynamically generated assemblies
• Only persist dynamically created assemblies if necessary
• Use ReflectionOnlyLoadFrom if you only need to inspect code

Obfuscation

• Avoid storing secrets in code
• Consider using obfuscation to make intellectual property theft more difficult

Cryptography

• Use platform-provided cryptographic services
• Use appropriately sized keys
• Use GenerateKey to generate random keys
• Consider using DPAPI to avoid key management
• Use PasswordDeriveBytes for password-based encryption
• Do not store keys in code
• Restrict access to persisted keys
• Cycle keys periodically
• Protect exported private keys

Sensitive Data

• Use protected configuration to protect sensitive data in configuration files
• Minimize the exposure of secrets in memory
• Where possible, use SecureString rather than System.String

Unmanaged Code

• Use naming conventions (safe, native, unsafe) to identify unmanaged APIs
• Isolate unmanaged API calls in a wrapper assembly
• Constrain and validate string parameters
• Validate array bounds
• Check file path lengths
• Use the /GS switch to compile unmanaged code
• Inspect unmanaged code for dangerous APIs
• Avoid exposing unmanaged types or handles to partially trusted code
• Avoid exposing unmanaged types or handles to partially trusted code
• Use SuppressUnmanagedCodeSecurity with caution
• Hold pointers in private fields

Related Items

• What's New in .NET Framework 2.0 Security

References

• See Security Guidelines: .NET Framework 2.0 at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/PAGGuidelines0003.asp