How to protect SharePoint servers from the ASP.NET vulnerability

On Friday an ASP.NET vulnerability was announced at an Argentine security conference, Microsoft posted Security Advisory 2416728 within a few hours, and by early Saturday morning Scott Guthrie described steps to mitigate ASP.NET sites against the vulnerability. Scott also posted a FAQ about the vulnerabilty that describes steps being taken towards a permanent solution, and how to detect attacks by monitoring server logs. Monday the SharePoint Products and Technologies team posted Steps to protect SharePoint 2010 sites from the vulnerability.

This post answers a few questions that colleagues and I had after reading through those links.

Q: What about SharePoint 2007?  

A: The WSS 3.0 and MOSS 2007 guidance would be nearly identical. One difference is that the application page to report the generic error will be stored in ...\12\template\layouts (or a subfolder of this) rather than 14.

Important Updates, Sept 21 and 24: The product team changed its guidance to explicitly include WSS 3.0 and MOSS 2007, and published an extra step that removes the resource loader from the application [Link].

Q: What if I want my company's branding on the error page?  

A: You can customize the error page to include branding, though it would be wise not to include any SharePoint controls or additional assembly references. If you must include branding then hard-code it; references to the images folder (e.g.: /{SharePoint Root}/layouts/images/{myImageFolder} ) are fine. What you must avoid is introducing any elements that rely on user context or availability of the API (breadcrumbs, etc.) that might cascade their own exceptions or provide further information about the nature of the root exception. The sample error page includes a random timer to vary page load times in order to obfuscate the nature of the exception. Note that the page is otherwise dead simple and does not reference any API except to produce a random number.

Q: What if I rely on error codes for load balancing or analytics?  

A: Once a patch is released that resolves the underlying issue, you will be able to reset web.config files to serve more granular errors. In the meantime, look into your application paths and make sure nothing is there that would pose a risk if it walked out the door. If against all guidance you have credentials hard-coded in web.config or custom code, perhaps now you understand why this is considered bad form.

Q: What if I follow best practices? I already encrypt all secrets in web.config, don't have anything to hide in ViewState that users shouldn't see, and monitor for trouble using the Dynamic IP Restrictions module in IIS 7 (or some other protection from DoS attacks). What's my risk?

A: If your security and practices are such that all the files in your web application could walk out the door without exposing any vulnerabilities, then you've done a great job, and based on what I know about the vulnerability, your risk is minimal. If you have any doubt, follow the prescribed steps to protect your environment until the permanent fix is released.

 As near as I can tell, this vulnerability should only be of concern to administrators and developers who do not follow well-known security practices. As the advisory says: "An attacker who exploited this vulnerability could view data, such as the View State, which was encrypted by the target server, or read data from files on the target server, such as web.config." It should go without saying that no secrets should be available through ViewState or web.config. Only encrypted secrets (e.g. database credentials) should ever be stored in web.config, and your applications should be developed to remain secure even if full source is available or the assembly compromised.

Thanks to all the product teams involved for their incredible response, and fingers crossed for a speedy resolution.