Check | Description |
---|---|
| 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. |
Check | Description |
---|---|
| 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. |
Check | Description |
---|---|
| 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. |
Check | Description |
---|---|
| 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. |
Check | Description |
---|---|
| 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. |
Check | Description |
---|---|
| 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. |
Check | Description |
---|---|
| 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. |
Check | Description |
---|---|
| 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. |
Check | Description |
---|---|
| 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. |
Check | Description |
---|---|
| 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) . |