Security Checklist: .NET Framework 2.0

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.

patterns & practices Developer Center

patterns & practices Developer Center

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
Ff649200.z02bthcm01(en-us,PandP.10).gif Target trust environment is identified. Permissions available to partial trust code and APIs that require additional permissions are identified.
Ff649200.z02bthcm01(en-us,PandP.10).gif Design exposes a minimal number of public interfaces to limit the assembly's attack surface.

Class Design Considerations

Check Description
Ff649200.z02bthcm01(en-us,PandP.10).gif To reduce visibility, classes and members use the most restrictive access modifier possible.
Ff649200.z02bthcm01(en-us,PandP.10).gif Base classes that are not intended to be derived from are sealed.
Ff649200.z02bthcm01(en-us,PandP.10).gif Strong naming or code access security is used to restrict code access.
Ff649200.z02bthcm01(en-us,PandP.10).gif Input is not trusted. Input is validated for type, range, format and length.
Ff649200.z02bthcm01(en-us,PandP.10).gif Fields are private. Properties are used to expose fields.
Ff649200.z02bthcm01(en-us,PandP.10).gif Properties are read-only unless write access is specifically required.
Ff649200.z02bthcm01(en-us,PandP.10).gif Where appropriate, private default constructors are used to prevent object instantiation.
Ff649200.z02bthcm01(en-us,PandP.10).gif Static constructors are private.

Strong Names

Check Description
Ff649200.z02bthcm01(en-us,PandP.10).gif If required, strong names are used
Ff649200.z02bthcm01(en-us,PandP.10).gif Strong names are not relied upon to create tamper-proof assemblies.
Ff649200.z02bthcm01(en-us,PandP.10).gif 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.
Ff649200.z02bthcm01(en-us,PandP.10).gif In full trust scenarios, StrongNameIdentityPermission is not relied upon to restrict code that can call the assembly.

APTCA

Check Description
Ff649200.z02bthcm01(en-us,PandP.10).gif Except where necessary, APTCA usage is avoided.
Ff649200.z02bthcm01(en-us,PandP.10).gif Assemblies marked with APTCA are subjected to thorough security code review.
Ff649200.z02bthcm01(en-us,PandP.10).gif SecurityTransparent and SecurityCritical attributes are used appropriately.

Exception Management

Check Description
Ff649200.z02bthcm01(en-us,PandP.10).gif Structured exception handling is used instead of returning error codes.
Ff649200.z02bthcm01(en-us,PandP.10).gif Sensitive data is not logged.
Ff649200.z02bthcm01(en-us,PandP.10).gif System or sensitive application information is not revealed. Only generic error messages are returned to the end user.
Ff649200.z02bthcm01(en-us,PandP.10).gif Code is not subject to exception filter issues where the filter higher in the call stack executes before code in a finally block.
Ff649200.z02bthcm01(en-us,PandP.10).gif Where appropriate, an exception management system is used.
Ff649200.z02bthcm01(en-us,PandP.10).gif Code fails early to avoid unnecessary processing.

File I/O

Check Description
Ff649200.z02bthcm01(en-us,PandP.10).gif Code avoids untrusted input for file names and file paths.
Ff649200.z02bthcm01(en-us,PandP.10).gif If file names must be accepted through input, the names and locations are first validated.
Ff649200.z02bthcm01(en-us,PandP.10).gif Security decisions are not based on user-supplied file names.
Ff649200.z02bthcm01(en-us,PandP.10).gif Where possible, absolute file paths are used.
Ff649200.z02bthcm01(en-us,PandP.10).gif Where appropriate, file I/O is constrained within the application's context.

Registry

Check Description
Ff649200.z02bthcm01(en-us,PandP.10).gif Sensitive data stored in HKEY_LOCAL_MACHINE is protected by ACLs.
Ff649200.z02bthcm01(en-us,PandP.10).gif Sensitive data in the registry is encrypted.

Communication Security

Check Description
Ff649200.z02bthcm01(en-us,PandP.10).gif 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.
Ff649200.z02bthcm01(en-us,PandP.10).gif Where appropriate, the System.Net.Security.NegotiateStream class is used for a TCP channel with .NET remoting.

Event Log

Check Description
Ff649200.z02bthcm01(en-us,PandP.10).gif Sensitive data is not logged in the event log.
Ff649200.z02bthcm01(en-us,PandP.10).gif Event log data is not exposed to unauthorized users.

Data Access

Check Description
Ff649200.z02bthcm01(en-us,PandP.10).gif Connection strings are not hard coded. Connection strings are stored in configuration files.
Ff649200.z02bthcm01(en-us,PandP.10).gif Connection strings are encrypted if they contain credentials.
Ff649200.z02bthcm01(en-us,PandP.10).gif To prevent SQL injection, input is validated and parameterized stored procedures are used.

Delegates

Check Description
Ff649200.z02bthcm01(en-us,PandP.10).gif Delegates are not accepted from untrusted sources.
Ff649200.z02bthcm01(en-us,PandP.10).gif Where appropriate, permissions to the delegate are restricted.
Ff649200.z02bthcm01(en-us,PandP.10).gif Permissions are not asserted before delegate is called.

Serialization

Check Description
Ff649200.z02bthcm01(en-us,PandP.10).gif The ISerializable interface or the NonSerialized attribute are used to control serialization of sensitive data.
Ff649200.z02bthcm01(en-us,PandP.10).gif Serialized data streams are validated when they are deserialized.

Threading

Check Description
Ff649200.z02bthcm01(en-us,PandP.10).gif Multithreaded code does not cache the results of security checks.
Ff649200.z02bthcm01(en-us,PandP.10).gif Impersonation tokens are not lost; they flow to the newly created thread.
Ff649200.z02bthcm01(en-us,PandP.10).gif Static class constructors are synchronized.
Ff649200.z02bthcm01(en-us,PandP.10).gif Dispose methods are synchronized.

Reflection

Check Description
Ff649200.z02bthcm01(en-us,PandP.10).gif Full assembly names are used when Activator.CreateInstance loads add-ins.
Ff649200.z02bthcm01(en-us,PandP.10).gif Separate, low-trust application domains are used for assemblies created with user input.
Ff649200.z02bthcm01(en-us,PandP.10).gif Assemblies are not loaded dynamically based on user input for assembly or type names.
Ff649200.z02bthcm01(en-us,PandP.10).gif Untrusted code does not use Reflection.Emit to create dynamic assemblies.
Ff649200.z02bthcm01(en-us,PandP.10).gif Unless required, dynamic assemblies created by Reflection.Emit are not persisted.
Ff649200.z02bthcm01(en-us,PandP.10).gif Assembly.ReflectionOnlyLoadFrom is used only if you need to inspect code.

Obfuscation

Check Description
Ff649200.z02bthcm01(en-us,PandP.10).gif Secrets are not stored in code.
Ff649200.z02bthcm01(en-us,PandP.10).gif Where appropriate, obfuscation is used to make intellectual property theft more difficult.

Cryptography

Check Description
Ff649200.z02bthcm01(en-us,PandP.10).gif Platform-provided cryptographic services are used. Custom cryptography algorithms are not used.
Ff649200.z02bthcm01(en-us,PandP.10).gif Appropriate key sizes are used.
Ff649200.z02bthcm01(en-us,PandP.10).gif GenerateKey is used to generate random keys for a managed symmetric cryptographic class.
Ff649200.z02bthcm01(en-us,PandP.10).gif Where appropriate, DPAPI is used to protect secrets and to reduce or eliminate key management.
Ff649200.z02bthcm01(en-us,PandP.10).gif PasswordDeriveBytes is used for password-based encryption.
Ff649200.z02bthcm01(en-us,PandP.10).gif Keys are not stored in code.
Ff649200.z02bthcm01(en-us,PandP.10).gif Access to persisted keys is restricted (for example with ACLs).
Ff649200.z02bthcm01(en-us,PandP.10).gif Keys are cycled periodically.
Ff649200.z02bthcm01(en-us,PandP.10).gif Exported private keys are protected.

Sensitive Data

Check Description
Ff649200.z02bthcm01(en-us,PandP.10).gif Where appropriate, SecureString is used rather than System.String.
Ff649200.z02bthcm01(en-us,PandP.10).gif Secrets are held in memory for only a limited time.
Ff649200.z02bthcm01(en-us,PandP.10).gif Protected configuration is used to protect sensitive data and secrets in configuration files.

Unmanaged Code

Check Description
Ff649200.z02bthcm01(en-us,PandP.10).gif Naming conventions are used (safe, native, unsafe) to identify unmanaged APIs.
Ff649200.z02bthcm01(en-us,PandP.10).gif Unmanaged API calls are isolated in a wrapper assembly.
Ff649200.z02bthcm01(en-us,PandP.10).gif String parameters that are passed to native code are constrained and validated to reduce the risk of buffer overrun, integer overflow, and other vulnerabilities.
Ff649200.z02bthcm01(en-us,PandP.10).gif Array bounds are validated when an array is used to pass input to a native API.
Ff649200.z02bthcm01(en-us,PandP.10).gif File path lengths are checked when a file name and path are passed to an unmanaged API.
Ff649200.z02bthcm01(en-us,PandP.10).gif Unmanaged code is compiled with the /GS switch to enable stack probes.
Ff649200.z02bthcm01(en-us,PandP.10).gif Unmanaged code is inspected for potentially dangerous APIs.
Ff649200.z02bthcm01(en-us,PandP.10).gif Unmanaged types or handles are not exposed to partially trusted code.
Ff649200.z02bthcm01(en-us,PandP.10).gif The SuppressUnmanagedCode attribute is used only if assembly takes precautions to ensure that malicious code cannot coerce it into performing unwanted operations.
Ff649200.z02bthcm01(en-us,PandP.10).gif Pointers are held in private fields to prevent access violation or attempt to dereference them to gain access to sensitive information.

Companion Guidance

Security Guidelines: .NET Framework 2.0

Feedback

Provide feedback by using either a Wiki or e-mail:

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 http://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

patterns & practices Developer Center

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.