.NET Framework 1.1 Security Checklist

From Guidance Share

Revision as of 03:55, 13 December 2007; JD (Talk | contribs)
(diff) ←Older revision | Current revision | Newer revision→ (diff)
Jump to: navigation, search

- J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan


Contents

General Code Review Guidelines


Managed Code Review Guidelines

If an entry is preceded by a star (*), it indicates that the checks are performed by the FXCop analysis tool. For more information about FXCop security checks, see http://www.gotdotnet.com/team/libraries/FxCopRules/SecurityRules.aspx.


Assembly-Level Checks

  • (*) Assemblies have a strong name. (Dynamically generated ASP.NET Web page assemblies cannot currently have a strong name.)
  • You have considered delay signing as a way to protect and restrict the private key that is used in the strong name and signing process.
  • (*)Assemblies include declarative security attributes (with SecurityAction.RequestMinimum) to specify minimum permission requirements.
  • Highly privileged assemblies are separated from lower privileged assemblies.
  • If the assembly is to be used in a partial-trust environment (for example, it is called from a partial-trust Web application), then privileged code is sandboxed in a separate assembly.


Class-Level Checks

  • Class and member visibility is restricted. The most restrictive access modifier is used (private where possible).
  • Non-base classes are sealed.
  • Input from outside the current trust boundary is validated. Input data is constrained and validated for type, length, format, and range.
  • Code implements declarative checks where virtual internal methods are used.
  • Access to public classes and methods are restricted with principal permission demands (where appropriate).
  • Fields are private. When necessary, field values are exposed by using read/write or read-only public properties.
  • Read-only properties are used where possible.
  • Types returned from methods that are not designed to be created independently contain private default constructors.
  • Unsealed public types do not have internal virtual members.
  • Use of event handlers is thoroughly reviewed.
  • Static constructors are private.


Cryptography

  • Code uses platform-provided cryptography and does not use custom implementations.
  • Random keys are generated by using RNGCryptoServiceProvider (and not the Random class).
  • PasswordDeriveBytes is used for password-based encryption.
  • DPAPI is used to encrypt configuration secrets to avoid the key management issue.
  • The appropriate key sizes are used for the chosen algorithm, or if they are not, the reasons are identified and understood.
  • Keys are not held in code.
  • Access to persisted keys is restricted.
  • Keys are cycled periodically.
  • Exported private keys are protected.


Secrets

  • Secrets are not hard coded.
  • Plain text secrets are not stored in configuration files.
  • Plain text secrets are not stored in memory for extended periods of time.


Exception Management

  • Code uses exception handling. You catch only the exceptions that you know about.
  • Exception details are logged on the server to assist in diagnosing problems.
  • The information that is returned to the end user is limited and safe.
  • Code that uses exception filters is not sensitive to filter execution sequence (filter runs before finally block).
  • Code fails early to avoid unnecessary processing that consumes resources.
  • Exception conditions do not allow a user to bypass security checks to run privileged code.


Delegates

  • Delegates are not accepted from untrusted sources.
  • If code does accept a delegate from untrusted code, it constrains the delegate before calling it by using security permissions with SecurityAction.PermitOnly.
  • Permissions are not asserted before calling a delegate.


Serialization

  • Serialization is restricted to privileged code.
  • Sensitive data is not serialized.
  • Field data from serialized data streams is validated.
  • ISerializable.GetObjectData implementation is protected with an identity permission demand in scenarios where you want to restrict which code can serialize the object.


Threading

  • Results of security checks are not cached.
  • Impersonation tokens are considered when new threads are created (any existing thread token is not passed to the new thread).
  • Threads are synchronized in static class constructors for multithreaded application code.
  • Object implementation code is designed and built to be thread safe.
  • Threads are synchronized in static class constructors.

Reflection

  • Caller cannot influence dynamically generated code (for example, by passing assembly and type names as input arguments).
  • Code demands permission for user authorization where assemblies are loaded dynamically.


Unmanaged Code Access

  • Input and output strings that are passed between managed and unmanaged code are constrained and validated.
  • Array bounds are checked.
  • File path lengths are checked and do not exceed MAX_PATH.
  • Unmanaged code is compiled with the /GS switch.
  • Use of "dangerous" APIs by unmanaged code is closely inspected. These include LogonUser, RevertToSelf, CreateThread, Network APIs, and Sockets APIs.
  • Naming conventions (safe, native, unsafe) are applied to unmanaged APIs.
  • Assemblies that call unmanaged code specify unmanaged permission requirements using declarative security (SecurityAction.RequestMinimum).
  • Unmanaged API calls are sandboxed and isolated in a wrapper assembly.
  • Use of SuppressUnmanagedCodeSecurityAttribute is thoroughly reviewed and additional security checks are implemented.
  • Types are not annotated with SuppressUnmanagedCodeSecurityAttribute. (This attribute is used on specific P/Invoke method declarations instead.)
  • Calling code is appropriately authorized using a full stack walk Demand (using either a .NET Framework permission or custom permission).
  • Unmanaged types or handles are never exposed to partially trusted code.
  • Pointers are private fields.
  • Methods that use IntPtr fields in a type that has a finalizer call GC.KeepAlive(object).


Resource Access Considerations

File I/O

* No security decisions are made based on filenames. * Input file paths and file names are well formed. * Environment variables are not used to construct file paths. * File access is constrained to the context of the application (by using a restricted FileIOPermission). * Assembly file I/O requirements are specified using declarative security attributes (with * * SecurityAction.RequestMinimum).


Event Log

  • Event log access code is constrained using EventLogPermission.
  • This particularly applies if your event logging code could be called by untrusted callers.
  • Event sources are created at installation time (or the account used to run the code that writes to the event log must be allowed to create event sources by configuring an appropriate ACL in the registry).
  • Security-sensitive data, such as passwords, is not written to the event log.


Registry

  • Sensitive data, such as database connection strings or credentials, is encrypted prior to storage in the registry.
  • Keys are restricted. If a key beneath HKEY_CURRENT_MACHINE is used, the key is configured with a restricted ACL. Alternatively, HKEY_CURRENT_USER is used.
  • Registry access is constrained by using RegistryPermission. This applies especially if your registry access code could be called by untrusted callers.


Environment Variables

  • Code that accesses environment variables is restricted with EnvironmentPermission. This applies especially if your code can be called by untrusted code.
  • Environment permission requirements are declared by using declarative security attributes with SecurityAction.RequestMinimum.
Personal tools