We're no longer updating this content regularly. Check the Microsoft Product Lifecycle for information about how this product, service, technology, or API is supported.
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Chaitanya Bijwe
Microsoft Corporation
November 2005
Applies To
.NET Framework version 2.0
Summary
This checklist presents a set of consolidated security guidelines for .NET Framework version 2.0 applications. The answers and recommendations presented in this module are designed to supplement the companion modules and additional guidance. The guidelines are organized by various categories that represent those areas where mistakes are most often made.
Contents
How To Use This Module
Assembly Design Considerations
Class Design Considerations
Strong Names
APTCA
Exception Management
File I/O
Registry
Communication Security
Event Log
Data Access
Delegates
Serialization
Threading
Reflection
Obfuscation
Cryptography
Sensitive Data
Unmanaged Code
Companion Guidance
How to Use This Module
This checklist is a companion to Security Guidelines: .NET Framework 2.0. Use "Security Guidelines: .NET Framework 2.0" to learn about the .NET Framework 2.0 guidelines and to learn what you should do, why you should do it, and how you can implement each guideline. Use this checklist as you develop your managed code.
You should expand and evolve this security checklist by adding managed code practices that you discover during software development.
Assembly Design Considerations
Check
Description
Target trust environment is identified. Permissions available to partial trust code and APIs that require additional permissions are identified.
Design exposes a minimal number of public interfaces to limit the assembly's attack surface.
Class Design Considerations
Check
Description
To reduce visibility, classes and members use the most restrictive access modifier possible.
Base classes that are not intended to be derived from are sealed.
Strong naming or code access security is used to restrict code access.
Input is not trusted. Input is validated for type, range, format and length.
Fields are private. Properties are used to expose fields.
Properties are read-only unless write access is specifically required.
Where appropriate, private default constructors are used to prevent object instantiation.
Static constructors are private.
Strong Names
Check
Description
If required, strong names are used
Strong names are not relied upon to create tamper-proof assemblies.
Delay signing is used to reduce the chance of private key compromise or to enable the use of a single public key across a team.
In full trust scenarios, StrongNameIdentityPermission is not relied upon to restrict code that can call the assembly.
APTCA
Check
Description
Except where necessary, APTCA usage is avoided.
Assemblies marked with APTCA are subjected to thorough security code review.
SecurityTransparent and SecurityCritical attributes are used appropriately.
Exception Management
Check
Description
Structured exception handling is used instead of returning error codes.
Sensitive data is not logged.
System or sensitive application information is not revealed. Only generic error messages are returned to the end user.
Code is not subject to exception filter issues where the filter higher in the call stack executes before code in a finally block.
Where appropriate, an exception management system is used.
Code fails early to avoid unnecessary processing.
File I/O
Check
Description
Code avoids untrusted input for file names and file paths.
If file names must be accepted through input, the names and locations are first validated.
Security decisions are not based on user-supplied file names.
Where possible, absolute file paths are used.
Where appropriate, file I/O is constrained within the application's context.
Registry
Check
Description
Sensitive data stored in HKEY_LOCAL_MACHINE is protected by ACLs.
Sensitive data in the registry is encrypted.
Communication Security
Check
Description
Transport-level encryption is used to protect secrets over the network. IPSec is used to protect the communication channel between two servers, and SSL is used for more granular channel protection for an application.
Where appropriate, the System.Net.Security.NegotiateStream class is used for a TCP channel with .NET remoting.
Event Log
Check
Description
Sensitive data is not logged in the event log.
Event log data is not exposed to unauthorized users.
Data Access
Check
Description
Connection strings are not hard coded. Connection strings are stored in configuration files.
Connection strings are encrypted if they contain credentials.
To prevent SQL injection, input is validated and parameterized stored procedures are used.
Delegates
Check
Description
Delegates are not accepted from untrusted sources.
Where appropriate, permissions to the delegate are restricted.
Permissions are not asserted before delegate is called.
Serialization
Check
Description
The ISerializable interface or the NonSerialized attribute are used to control serialization of sensitive data.
Serialized data streams are validated when they are deserialized.
Threading
Check
Description
Multithreaded code does not cache the results of security checks.
Impersonation tokens are not lost; they flow to the newly created thread.
Static class constructors are synchronized.
Dispose methods are synchronized.
Reflection
Check
Description
Full assembly names are used when Activator.CreateInstance loads add-ins.
Separate, low-trust application domains are used for assemblies created with user input.
Assemblies are not loaded dynamically based on user input for assembly or type names.
Untrusted code does not use Reflection.Emit to create dynamic assemblies.
Unless required, dynamic assemblies created by Reflection.Emit are not persisted.
Assembly.ReflectionOnlyLoadFrom is used only if you need to inspect code.
Obfuscation
Check
Description
Secrets are not stored in code.
Where appropriate, obfuscation is used to make intellectual property theft more difficult.
Cryptography
Check
Description
Platform-provided cryptographic services are used. Custom cryptography algorithms are not used.
Appropriate key sizes are used.
GenerateKey is used to generate random keys for a managed symmetric cryptographic class.
Where appropriate, DPAPI is used to protect secrets and to reduce or eliminate key management.
PasswordDeriveBytes is used for password-based encryption.
Keys are not stored in code.
Access to persisted keys is restricted (for example with ACLs).
Keys are cycled periodically.
Exported private keys are protected.
Sensitive Data
Check
Description
Where appropriate, SecureString is used rather than System.String.
Secrets are held in memory for only a limited time.
Protected configuration is used to protect sensitive data and secrets in configuration files.
Unmanaged Code
Check
Description
Naming conventions are used (safe, native, unsafe) to identify unmanaged APIs.
Unmanaged API calls are isolated in a wrapper assembly.
String parameters that are passed to native code are constrained and validated to reduce the risk of buffer overrun, integer overflow, and other vulnerabilities.
Array bounds are validated when an array is used to pass input to a native API.
File path lengths are checked when a file name and path are passed to an unmanaged API.
Unmanaged code is compiled with the /GS switch to enable stack probes.
Unmanaged code is inspected for potentially dangerous APIs.
Unmanaged types or handles are not exposed to partially trusted code.
The SuppressUnmanagedCode attribute is used only if assembly takes precautions to ensure that malicious code cannot coerce it into performing unwanted operations.
Pointers are held in private fields to prevent access violation or attempt to dereference them to gain access to sensitive information.
We are particularly interested in feedback regarding the following:
Technical issues specific to recommendations
Usefulness and usability issues
Technical Support
Technical support for the Microsoft products and technologies referenced in this guidance is provided by Microsoft Support Services. For product support information, please visit the Microsoft Product Support Web site at https://support.microsoft.com.
Community and Newsgroups
Community support is provided in the forums and newsgroups:
To get the most benefit, find the newsgroup that corresponds to your technology or problem. For example, if you have a problem with ASP.NET security features, you would use the ASP.NET Security forum.
Contributors and Reviewers
External Contributors and Reviewers: Anil John, Johns Hopkins University–Applied Physics Laboratory; Frank Heidt; Jason Taylor, Security Innovation
Microsoft Product Group: Don Willits, Pablo Castro, Stefan Schackow
Microsoft IT Contributors and Reviewers: Akshay Aggarwal, Shawn Veney, Talhah Mir
Microsoft Services and PSS Contributors and Reviewers: Adam Semel, Tom Christian, Wade Mascia
Microsoft patterns & practices Contributors and Reviewers: Carlos Farre
Test team: Larry Brader, Microsoft Corporation; Nadupalli Venkata Surya Sateesh, Sivanthapatham Shanmugasundaram, Infosys Technologies Ltd.
Edit team: Nelly Delgado, Microsoft Corporation
Release Management: Sanjeev Garg, Microsoft Corporation
Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.