Return to GuidanceExplorer

---

Workflow Definitions

* (1) - The item has been created in the library and contains content from the existing patterns & practices guidance
* (2) - Content gaps have been filled in but problem and solution examples are not yet complete
* (3) - Content is complete, including examples. The item is ready for review
* (4) - Review is completed and all feedback has been addressed

.NET Framework 1.1

Performance
* (2) - Reduce boundary crossing.
* (2) - Do not make class thread safe by default.
* (2) - Avoid calling GC.Collect.
* (4) - Use the using statement in C# and Try/Finally blocks in Visual Basic .NET to ensure Dispose is called.
* (2) - Implement finalize only if you hold unmanaged resources across client calls
* (3) - Use thread pool when you need threads.
* (2) - Consider client side asynchronous calls for UI responsiveness.
* (3) - Do not catch exceptions that you cannot handle.
* (3) - Do not use exceptions to control application flow.
* (2) - Use Efficient String Concatenation.

* Use single large assemblies rather than multiple smaller assemblies
* Minimize hidden allocations
* Coordinate multiple readers and single writers by using ReaderWriterLock instead of lock.
* Use early binding and explicit types rather than reflection

Security
* Restrict class and member visibility.
* Restrict which users can call your code
* Strong Name the assemblies.
* Do not log or reveal sensitive information
* Inspect unmanaged code for "dangerous" APIs
* Validate input and output string parameters of unmanaged code
* Do Not Accept Delegates from Untrusted Sources
* Use obfuscation to protect IP.
* Use platform-provided cryptographic services
* Use DPAPI to avoid key management

* Constrain file I/O within your application's context.
* Use PasswordDeriveBytes for password-based encryption
* Cycle Keys Periodically
* Protect Keys which needs to be persisted.
* Do Not Serialize Sensitive Data

ASP.NET 1.1

Performance
* (4) - Tune the thread pool by using the formula to reduce contention
* (4) - Avoid per-request impersonation
* (4) - Use client-side validation.
* (4) - Partition page content to improve caching efficiency and reduce rendering
* (4) - Use Page.IsPostBack to minimize redundant processing.
* (2) - Trim your page size.
* (4) - Disable session state if you do not use it.
* (4) - Disable view state if you do not need it.
* (4) - Only use SSL for pages that require it
* (4) - Disable tracing and debugging

* (3) - Configure minIoThreads and minWorkerThreads for burst load
* (2) - Ensure pages are batch compiled.
* (4) - Avoid using Page.DataBind
* (4) - Use output caching to cache relatively static page
* (4) - Implement a Global.asax error handler
* (4) - Constrain unwanted Web server traffic

Security
* (3) - Use server-side input validation.
* (2) - Partition your Web site and Secure restricted pages with SSL.
* (3) - Validate all user inputs for type, length, format, and range
* (2) - Use encoding while outputting user input.
* (2) - Use URL Authorization for page and directory access control
* (2) - Secure the authentication cookie
* (2) - Do not pass sensitive data from page to page.
* (3) - Protect sensitive data over the wire
* (3) - Avoid storing sensitive data in view state
* (2) - Return generic error pages to the client.

* Use absolute URLs for navigation
* Use explicit role checks for fine-grained authorization
* Avoid plain text passwords in configuration files
* Do not cache sensitive data

ADO.NET 1.1

Performance
* (2) - Use Appropriate Normalization
* (3) - Connect Using Service Accounts
* (2) - Pool Connections
* (3) - Explicitly Close Connections
* (3) - Use Stored Procedures
* (2) - Cache Stored Procedure SqlParameter Objects
* (2) - Batch SQL Statements To Reduce Round Trips
* (2) - Use Output Parameters Where Possible
* (2) - Perform Bulk Updates and Inserts by Using OpenXML

.NET Framework 2.0

Performance
* Reduce boundary crossing.
* Use single large assemblies rather than multiple smaller assemblies
* Do not make class thread safe by default.
* Avoid calling GC.Collect.
* Minimize hidden allocations
* Use the using statement in C# and Try/Finally blocks in Visual Basic .NET to ensure Dispose is called.
* Implement finalize only if you hold unmanaged resources across client calls
* Use thread pool when you need threads.
* Consider client side asynchronous calls for UI responsiveness.
* Coordinate multiple readers and single writers by using ReaderWriterLock instead of lock.
* Do not catch exceptions that you cannot handle.
* Do not use exceptions to control application flow.
* Use + when the number of appends is known and StringBuilder when the number of appends is unknown.
* Use early binding and explicit types rather than reflection
Security
* (1) - Restrict access to your code.
* (2) - Strong Name the assemblies.
* (2) - Do not log or reveal sensitive information
* (2) - Consider transport-level encryption to protect secrets on the network.
* (2) - Avoid accepting delegates from untrusted sources.
* (2) - Consider using obfuscation.
* (2) - Use platform-provided cryptographic services.
* (2) - Consider using DPAPI to avoid key management.
* (2) - Inspect unmanaged code for "dangerous" APIs
* (2) - Validate unmanaged string parameters.

* Restrict class and member visibility
* Do not depend on strong name identity permissions in full trust scenarios
* Avoid using APTCA.
* Consider using SecurityTransparent and SecurityCritical
* Constrain file I/O within your application's context
* Do not serialize sensitive data.
* Do not cache the results of security checks.
* Use PasswordDeriveBytes for password-based encryption.
* Restrict access to persisted keys.
* Cycle keys periodically.

ASP.NET 2.0

Performance
* Tune the thread pool by using the formula to reduce contention
* Configure minIoThreads and minWorkerThreads for burst load
* Avoid per-request impersonation
* Use client-side validation.
* Partition page content to improve caching efficiency and reduce rendering
* Use Page.IsPostBack to minimize redundant processing.
* Trim your page size.
* Ensure pages are batch compiled.
* Avoid using Page.DataBind
* Use output caching to cache relatively static page
* Disable session state if you do not use it.
* Disable view state if you do not need it.
* Implement a Global.asax error handler
* Constrain unwanted Web server traffic
* Only use SSL for pages that require it
* Disable tracing and debugging
Security
* (2) - Validate input from all sources for type, length, format, and range
* (4) - Do not rely on client-side validation.
* (2) - Do not echo untrusted input.
* (3) - Use membership providers instead of custom authentication
* (2) - Use SSL to protect credentials and authentication cookies
* (2) - Use URL authorization for page and directory access control
* (2) - Use ASP.NET role manager for roles authorization
* (4) - Do not reveal exception details to the client
* (3) - Avoid storing sensitive data in ViewState
* (3) - Do not pass sensitive data from page to page

* (4) - Enforce strong passwords
* (3) - Consider partitioning your site to restricted areas and public areas
* (2) - Choose Windows authentication when you can
* (4) - Choose a trust level that does not exceed your application's requirements
* (3) - Avoid programmatic impersonation where possible
* (3) - Avoid plaintext passwords in configuration files
* (3) - Do not cache sensitive data

---

Checklists

.NET Framework 1.1

Performance
* (1) - Boundary crossings are reduced.
* (2) - Classes are not made thread safe by default.
* (2) - GC.Collect is not called.
* (3) - Using statement in C# and Try/Finally blocks in Visual Basic .NET is used to ensure Dispose is called.
* (1) - Finalize is implemented only if you hold unmanaged resources across client calls.
* (3) - Thread pool is used instead of creating threads.
* (2) - Efficient String Concatenation is Is Used
* (2) - Client-side asynchronous calls are used for UI responsiveness.
* Hidden allocations are minimized.
* Single large assembly is used rather than multiple smaller assemblies.
* Coordinate multiple readers and single writers by using ReaderWriterLock instead of lock.
* Exceptions are not caught if they can not be handled.
* Exceptions are not used to control application flow.
* Early binding and explicit types are used rather than reflection.
Security
* Assemblies have a strong name. (Dynamically generated ASP.NET Web page assemblies cannot currently have a strong name.)
* Assemblies include declarative security attributes (with SecurityAction.RequestMinimum) to specify minimum permission requirements.
* Class and member visibility is restricted. The most restrictive access modifier is used (private where possible).
* Restrict which users can call your code
* The information that is returned to the end user is limited and safe
* File access is constrained to the context of the application (by using a restricted FileIOPermission).
* Use of "dangerous" APIs by unmanaged code is closely inspected. These include LogonUser, RevertToSelf, CreateThread, Network APIs, and Sockets APIs
* Input and output strings that are passed between managed and unmanaged code are constrained and validated.
* Delegates are not accepted from untrusted sources.
* Sensitive Data is protected in memory, in configuration file and not stored in the code.
* Sensitive data is not serialized
* Use obfuscation to protect IP.
* Code uses platform-provided cryptography and does not use custom implementations.
* DPAPI is used to encrypt configuration secrets to avoid the key management issue
* PasswordDeriveBytes is used for password-based encryption.
* Keys are cycled periodically.
* Access to persisted keys is restricted.

ASP.NET 1.1

Performance
* (3) - Thread pool is tuned by using the formula to reduce contention
* (3) - Per-request impersonation is not used
* (3) - Client-side validation is used.
* (3) - Page content is partitioned to improve caching efficiency and reduce rendering
* (3) - IsPostBack is used to minimize redundant processing.
* (2) - Page size is trimmed.
* (3) - Session state is disabled if you do not use it.
* (3) - View state is disabled if you do not need it.
* (3) - SSL used only the for pages that require it
* (3) - Tracing and debugging is disabled

* minIoThreads and minWorkerThreads are configured for burst load
* Pages are batch compiled.
* DataBind is not used
* Output caching is used to cache relatively static page
* Global.asax error handler is implemented
* Unwanted Web server traffic is constrained.

Security
* (3) - Security decisions should not rely on client-side validations; they are made on the server side.
* (2) - The Web site is partitioned into public access areas and restricted areas that require authentication access. Navigation between these areas should not flow sensitive credentials information.
* (3) - All user input is validated for type, length, format, and range. Input is checked for known valid and safe data and then for malicious, dangerous data
* (2) - Output that includes input is encoded with HtmlEncode and UrlEncode.
* (2) - URL authorization is used for page and directory access control
* (2) - Secure Sockets Layer (SSL) is used to protect credentials and authentication cookies
* (2) - Sensitive data is not passed across pages; it is maintained using server-side state management.
* (3) - SSL is used to protect sensitive data on the wire.
* (3) - Sensitive data is not stored in the view state
* (3) - Generic error pages with harmless messages are returned to the client.

* Absolute URLs are used for navigation where the site is partitioned with secure and non-secure folders.
* Explicit role checks are used if fine-grained authorization is required
* To enforce machine-wide policy, Web.config settings are locked by using allowOveride="false" in Machine.config
* Plain text passwords are avoided in Web.config and Machine.config files. (Aspnet_setreg.exe is used to encrypt credentials.)
* Do not cache sensitive data. Output caching is off by default
* The session state service is disabled if not used

.NET Framework 2.0

Performance
* Boundary crossings are reduced.
* Single large assembly is used rather than multiple smaller assemblies.
* Classes are not made thread safe by default.
* GC.Collect is not called.
* Hidden allocations are minimized.
* Using statement in C# and Try/Finally blocks in Visual Basic .NET is used to ensure Dispose is called.
* Finalize is implemented only if you hold unmanaged resources across client calls.
* Thread pool is used instead of creating threads.
* Client-side asynchronous calls are used for UI responsiveness.
* Coordinate multiple readers and single writers by using ReaderWriterLock instead of lock.
* Exceptions are not caught if they can not be handled.
* Exceptions are not used to control application flow.
* Early binding and explicit types are used rather than reflection.
Security
* Visibility of classes and members are reduced using the most restrictive access modifier possible.
* In full trust scenarios, StrongNameIdentityPermission is not relied upon to restrict code that can call the assembly
* Assemblies are strong named.
* Except where necessary, APTCA usage is avoided.
* System or sensitive application information is not revealed. Only generic error messages are returned to the end user.
* Where appropriate, file I/O is constrained within the application's context
* Sensitive data is not logged in the event log.
* Delegates are not accepted from untrusted sources.
* The ISerializable interface or the NonSerialized attribute are used to control serialization of sensitive data.
* Multithreaded code does not cache the results of security checks.
* Where appropriate, obfuscation is used to make intellectual property theft more difficult.
* Platform-provided cryptographic services are used. Custom cryptography algorithms are not used
* PasswordDeriveBytes is used for password-based encryption.
* Access to persisted keys is restricted (for example with ACLs)
* Keys are cycled periodically
* String parameters that are passed to native code are constrained and validated to reduce the risk of buffer overrun, integer overflow, and other vulnerabilities
* Unmanaged code is inspected for potentially dangerous APIs

ASP.NET 2.0

Performance
* Thread pool is tuned by using the formula to reduce contention
* minIoThreads and minWorkerThreads are configured for burst load
* Per-request impersonation is not used
* Client-side validation is used.
* Page content is partitioned to improve caching efficiency and reduce rendering
* Page.IsPostBack is used to minimize redundant processing.
* Page size is trimmed.
* Pages are batch compiled.
* Page.DataBind is not used
* Output caching is used to cache relatively static page
* Session state is disabled if you do not use it.
* View state is disabled if you do not need it.
* Global.asax error handler is implemented
* Unwanted Web server traffic is constrained.
* SSL used only the for pages that require it
* Tracing and debugging is disabled
Security
* (2) - Membership providers are used instead of custom authentication.
* (2) - SSL is used to protect user credentials and authentication cookies.
* (2) - URL authorization is used for page and directory access control.
* (2) - Role manager, instead of custom code, is used for roles authorization.
* (4) - Generic error pages with harmless messages are returned to the client.
* (4) - All the input is validated for length, range, format, and type. Input is checked for known valid and safe data and then for malicious, dangerous data.
* (4) - Application does not rely on only client-side validation.
* (3) - Sensitive data is not stored in view state.
* (2) - Windows authentication is used where possible.
* (3) - The chosen trust level does not exceed your application's requirement.

* The Web site is partitioned into public access areas and restricted areas that require authentication access. Navigation between these areas should not flow sensitive credentials information.
* The site has granular authorization checks for pages and directories.
* Strong passwords policies are enforced.
* Absolute URLs are used for navigation where the site is partitioned with secure and non-secure folders.
* Programmatic impersonation is avoided where possible.
* Sensitive data passed over wire is secured using SSL or IPSec where appropriate.
* Configuration settings are locked by setting allowOverride to false where appropriate to enforce policy settings.

---

Return to GuidanceExplorer