Code Acceptance Checklist in .NET

Code Acceptance Checklist in .NET

1. .NET
2. Validation
3. Dot Net Security
4. Log and Exception Handling
5. Others

Note: Please mark "Y" for implementing, "N" for not implementing standards, and "-" for the section that is not applicable.

 

.NET

• Assemblies must have a strong name. (Dynamically generated ASP.NET Web page assemblies cannot currently have a strong name.)
• You use 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 an 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 in a separate assembly.
• You rely on a native configuration file to support the application instead of changing the configuration to the Web.config.
• You use .NET Framework 2.0, 3.0, or 3.5.
• You use a single .NET Framework version. You do not mix multiple versions.
• Your code is 64 bit compatible.
• You avoid hard coding strings and labels. You use resource or language files instead.

Validation

1. Data is validated for type, length, format, and range.
2. Input validation is applied at all identified entry points (including form fields, querystrings, cookies, HTTP headers, and Web Service parameters).
3. Security does not rely on client-side validation. Instead, validation is done on the server-side.
4. The ASP.NET validateRequest option is enabled, if possible.

.Net Security

• The application uses an inclusion list (known, valid, and safe input) rather than an exclusion list (rejecting known malicious or dangerous input).
• Plain text passwords are not present in Web.config, Machine.config, or any files that contain configuration settings. Utilities such as Aspnet_setreg.exe and Trustee or the identity setting in AppPool on IIS 6.0 or IIS 7.0 are used to encrypt credentials.
• Sensitive data is not stored in cookies.
• If cookies contain sensitive data, they are marked secure.
• Session state is strong, unpredictable, and protected from unauthorized access or replay attacks.
• Session lifetime is limited to 30 minutes maximum of inactivity.
• Session identifiers are not passed in the URL and the ASP.NET feature, cookieless session, is not used.
• The session state service is disabled if not used.
• The application consistently uses standardized input validation such as RegEx throughout.
• The application does not log sensitive data in cleartext.
• Sensitive data is not stored in unencrypted, hidden form fields or query strings. It is maintained by using server-side state management.
• SSL, IPSEC with encryption, or application-layer encryption prior to transmittal is used to protect sensitive data during transmission.
• Sensitive data is not cached. Output caching is off by default.
• Sensitive data that is transferred via e-mail uses S/MIME encryption or Information Rights Management (IRM), depending upon the intended recipient.
• Input surfaces in Web parts and other customizations include boundary checks, input data integrity checks, and appropriate exception handling to protect from cross-site scripting and SQL injection.
• All user input is encoded with IOSec when displayed to clients.
• Character encoding is set by the server (ISO-8859-1 is recommended).
• If you display or download user-uploaded documents then you must append the X-Content-Type-Options: nosniff. HTTP response header when returning the document.
   
  If the document does not need to render in the browser, you must send two additional HTTP response headers to prevent this. The following are the HTTP response headers to send:
   
  • X-Download-Options: noopen, Content-Disposition: attachment

Log and Exception Handling

• The application uses a standardized approach to structured error and exception handling throughout.
• Error-handling code inherits from the SPException class to maintain a consistent SharePoint look and feel for errors.
• Exception conditions do not allow a user to bypass security checks to run privileged code.
• The application returns generic custom error messages to the client.
• The application fails securely in the event of error and exceptions.
• The code uses exception handling. The code catches only the exceptions that you know about. For example, do not use try{} catch(Exception ex){} unless you throw the error again.
• If the code uses exception filters, it is not sensitive to filter execution sequence (the filter runs before the final block).
• When logging code, you use the Portal Log class to log the SharePoint Unified Logging Service (ULS) logs.
• Installation and deployment logging are provided in the event logs to enable appropriate operational troubleshooting during installation and uninstallation.
• Application errors do not contain sensitive information or information that could be used to exploit the fault.

Others

• The design addresses potential canonicalization issues.
• You use the SharePoint Web part infrastructure's standardized set of connection interfaces for Web parts to exchange information with each other at run time.
• Source code for third-party Web parts solutions, whenever possible, is provided with adequate documentation to ensure good technical support.
• All custom Web Parts utilize the SharePoint architecture to ensure consistent behavior across the application for functionality such as single sign-on, feature deployment, and so on.
• Customizations are accompanied by installation instructions that detail how to install and uninstall the package. Architecture diagrams that are related to the installation of the solution are included. If it is not possible to roll back a solution, this must be explained in the installation instructions so that you can discuss the risks and prepare a plan for system recovery.
• Customizations are accompanied by test documents and results.
• Customizations are accompanied by a list of all dependencies. This could include accounts/passwords, Web Services, databases, other solutions or features, patches, toolsets or libraries, and other dependencies.
• A list of all event entries that are generated by the customizations and the actions to use are supplied. This can take the form of a table of error codes, where the severity and root cause of each code is supplied.
• Optionally, source code is provided to expedite validation and testing by the IT organization.
• The solution uses the AppSettings object to implement XML mapping. (This can be provided using the settings persistence framework in .NET 2.0, 3.0, or 3.5.) The solution avoids creating custom XML files and a strongly typed object for XML mapping.
• Custom Web parts (including resource files) are contained within a SharePoint Feature and are packaged as a SharePoint solution to be deployed.
• The configuration of Web Parts that are being deployed gives the administrator the flexibility to deploy to the web application level or lower.
• Customizations that are an upgrade of previously deployed customizations are accompanied by documentation that describes the changes and considerations in upgrading the customizations and rollback instructions.