.NET Framework 2.0 Security Guidelines
From Guidance Share
J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Chaitanya Bijwe
[edit]
Assembly Design Considerations
[edit]
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
[edit]
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
[edit]
APTCA
[edit]
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
[edit]
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
[edit]
Registry
- Consider using ACLs to restrict access to data stored in HKLM
- Consider encrypting sensitive data in the registry
[edit]
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
[edit]
Event Log
[edit]
Data Access
[edit]
Delegates
- Avoid accepting delegates from untrusted sources
- Consider restricting permissions to the delegate
- Avoid asserting permissions before calling a delegate
[edit]
Serialization
[edit]
Threading
- Do not cache the results of security checks
- Avoid losing impersonation tokens
- Synchronize static class constructors
- Synchronize Dispose methods
[edit]
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
[edit]
Obfuscation
- Avoid storing secrets in code
- Consider using obfuscation to make intellectual property theft more difficult
[edit]
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
[edit]
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
[edit]
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
[edit]
Related Items
[edit]
References
- See Security Guidelines: .NET Framework 2.0 at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/PAGGuidelines0003.asp