guidancemap | Channel 9

* Engineering Practices Map
* Rules Library Map

.NET Framework 1.1

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
* Restrict class and member visibility.
* Restrict which users can call your code
* Strong Name the assemblies.
* Do not log or reveal sensitive information
* Constrain file I/O within your application's context.
* Inspect unmanaged code for "dangerous" APIs
* Validate input and output string parameters of unmanaged code
* Do Not Accept Delegates from Untrusted Sources
* Do Not Serialize Sensitive Data
* Use obfuscation to protect IP.
* Use platform-provided cryptographic services
* Use DPAPI to avoid key management
* Use PasswordDeriveBytes for password-based encryption
* Cycle Keys Periodically
* Protect Keys which needs to be persisted.

ASP.NET 1.1

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
* Use server-side input validation.
* Partition your Web site and Secure restricted pages with SSL.
* Validate all user inputs for type, length, format, and range
* Use encoding while outputting user input.
* Use URL Authorization for page and directory access control
* Secure the authentication cookie
* Use absolute URLs for navigation
* Use explicit role checks for fine-grained authorization
* Do not pass sensitive data from page to page.
* Avoid plain text passwords in configuration files
* Protect sensitive data over the wire
* Do not cache sensitive data
* Avoid storing sensitive data in view state
* Return generic error pages to the client.

.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
* Restrict class and member visibility
* Restrict access to your code.
* Strong Name the assemblies.
* Do not depend on strong name identity permissions in full trust scenarios
* Avoid using APTCA.
* Consider using SecurityTransparent and SecurityCritical
* Do not log or reveal sensitive information
* Constrain file I/O within your application's context
* Consider transport-level encryption to protect secrets on the network.
* Avoid accepting delegates from untrusted sources.
* Do not serialize sensitive data.
* Do not cache the results of security checks.
* Consider using obfuscation to make intellectual property theft more difficult.
* Use platform-provided cryptographic services.
* Consider using DPAPI to avoid key management.
* Use PasswordDeriveBytes for password-based encryption.
* Restrict access to persisted keys.
* Cycle keys periodically.
* Inspect unmanaged code for "dangerous" APIs
* Validate input and output string parameters of unmanaged code

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
* Validate input from all sources for type, length, format, and range
* Do not rely on client-side validation.
* Do not echo untrusted input.
* Use membership providers instead of custom authentication
* Enforce strong passwords
* Use SSL to protect credentials and authentication cookies
* Consider partitioning your site to restricted areas and public areas
* Choose Windows authentication when you can
* Use URL authorization for page and directory access control
* Use ASP.NET role manager for roles authorization
* Choose a trust level that does not exceed your application's requirements
* Do not reveal exception details to the client
* Avoid programmatic impersonation where possible
* Avoid storing sensitive data in ViewState
* Avoid plaintext passwords in configuration files
* Do not cache sensitive data
* Do not pass sensitive data from page to page

Checklists

.NET Framework 1.1

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
* 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
* 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
* Security decisions should not rely on client-side validations; they are made on the server side.
* 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.
* 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
* Output that includes input is encoded with HtmlEncode and UrlEncode.
* URL authorization is used for page and directory access control
* Secure Sockets Layer (SSL) is used to protect credentials and authentication cookies
* 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
* Sensitive data is not passed across pages; it is maintained using server-side state management.
* Plain text passwords are avoided in Web.config and Machine.config files. (Aspnet_setreg.exe is used to encrypt credentials.)
* SSL is used to protect sensitive data on the wire.
* Do not cache sensitive data. Output caching is off by default
* Sensitive data is not stored in the view state
* Generic error pages with harmless messages are returned to the client.
* 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
* 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.
* Membership providers are used instead of custom authentication.
* SSL is used to protect user credentials and authentication cookies.
* Strong passwords policies are enforced.
* Absolute URLs are used for navigation where the site is partitioned with secure and non-secure folders.
* Windows authentication is used where possible.
* URL authorization is used for page and directory access control.
* Role manager, instead of custom code, is used for roles authorization.
* The chosen trust level does not exceed your application's requirement.
* Generic error pages with harmless messages are returned to the client.
* 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.
* Application does not rely on only client-side validation.
* Programmatic impersonation is avoided where possible.
* Sensitive data is not stored in view state.
* 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