Recently, Microsoft has undisclosed a high-risk security vulnerability in all versions of ASP.NET. An attacker using this vulnerability is able to request and download files within an ASP.NET Application. (e.g. web.config file). When the attacker also exploits this vulnerability he can decrypt data sent to the client in an encrypted state (e.g. ViewState of a page)

Before Microsoft releases a patch that can be used to correct the root cause of the issue, we recommend to use the following workaround for your ASP.NET Applications.

The workaround

A workaround you can use to prevent this vulnerability is to enable the <customErrors> feature of ASP.NET, and explicitly configure your applications to always return the same error page. By mapping all error pages to a single error page, you prevent the hacker from distinguishing between the different types of errors that occur on a server.

Enable the workaround

Depending on the ASP.NET version you are using the workaround slighty differs. Exact steps on how to enable this can be found at ScottGu's blog. The main thing that needs to be done is to modify the customErrors section in the web.config of your ASP.NET application.

Existing applications

If the application already uses a custom error page you need to make sure that the customErrors section in the web.config file is properly enabled and configured. If no custom error page available you'll need to include one in your application.

New applications

When developing new applications, provide a custom error page to redirect all errors and update the customError section in the web.config.

What about ADAM?

Existing ADAM out of the box studio's are not vulnerable for the security bug. The studio's already use a custom error page and the customErrors section is set to the correct mode.

Extra information about this vulnerability can also be found here.