Security Checklist: .NET Framework 2.0

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
	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.

Companion Guidance

Security Guidelines: .NET Framework 2.0

Feedback

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

• Wiki. Security Guidance Feedback page: https://channel9.msdn.com/wiki/securityguidancefeedback/.
• E-mail. Send e-mail to secguide@microsoft.com.

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:

• MSDN Newsgroups: https://www.microsoft.com/communities/newsgroups/default.mspx
• ASP.NET Forums: http://forums.asp.net

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