ASP.NET security setting recommendations

Weak password account lockout policy and password change functionality

Optimizely Content Management System (CMS) uses standard ASP.NET mechanisms for password handling, which lets you configure password complexity policies. You also can configure CMS to use Windows or Active Directory for authentication, meaning that password changes and lockout policy is delegated.

You should have strong password complexity requirements on user accounts and ensure that any changes to user accounts involve the user's current password. You can also use a different CMS membership provider that does not allow password changes. Subclassing the SqlServerMembershipProvider or using the ActiveDirectoryMembership provider work equally well.

See the following Microsoft references for information about managing membership accounts.

• Storage of membership information
• Password evaluation and complexity
• Account lockout policy

Cross-site request forgery (CSRF)

CMS uses a stateless token-based pattern for CSRF mitigation. If you intend to add functionality to CMS that includes state-changing operations, you should include CSRF mitigation; ASP.NET provides standard libraries for implementing this. See Cross-Site Request Forgery.

Ineffective session termination

CMS uses standard ASP.NET authentication mechanisms, which do not support active logout and are session-less. You might extend ASP.NET, but that is not a feature provided by CMS. You should use HTTPS for secure communication because this does not let third parties sniff the session token.

You can extend ASP.ASP.NET's ticket with active logout, but that is not a feature Optimizely provides.

Header disclosure

Using IIS and ASP.NET, some informational HTTP headers are added to a response, which might expose security-related information like ASP.NET and IIS versions. You can modify this using standard ASP.NET techniques; it is not specific to CMS, and you should deal with it as part of standard application hardening. You can remove the X-AspNetMvc-Version header with a simple set of the MvcHandler.DisableMvcResponseHeader property.

Disable autocomplete

You should build a custom login page with auto-complete disabled, replacing the default login page. Forms containing user names and passwords or other sensitive information should have the autocomplete option disabled on the form and the sensitive fields.

Vulnerability to clickjacking attacks

You can avoid clickjacking attacks on websites by ensuring that content is not embedded into other sites using frames. Use the X-Frame-Options HTTP response header to defend against clickjacking attacks. This header indicates that you should not load the current page in a frame, and through code, you can blank the page's contents if another domain frames it.

See the recommendations in The X-Frame-Options response header.