Top 10 Security Vulnerabilities in .NET Configuration Files

Developers often concentrate on writing secure code but leave security vulnerabilities in application configuration files. Discover the most common configuration security problemsand how to avoid them.

by Bryan Sullivan

Sep 19, 2006

Page 1 of 5

hese days, the biggest threat to an organization's network security comes from its public Web site. Unlike internal-only network services such as databaseswhich can be sealed off from the outside via firewallsa public Web site is generally accessible to anyone who wants to view it. As networks have become more secure, vulnerabilities in Web applications have inevitably attracted the attention of hackers, both criminal and recreational, who have devised techniques to exploit these holes. In fact, attacks upon the Web application layer now exceed those conducted at the network level, and can have consequences which are just as damaging.

Some enlightened software architects and developers are becoming educated on these threats and are designing their Web applications with security in mind. By "baking in" security from the start of the development process, rather than trying to "brush it on" at the end, you are much more likely to create secure applications that will withstand hackers' attacks. However, even the most meticulous and security-aware C# or VB.NET code can still be vulnerable to attack if you neglect to secure the configuration files of your application. An incorrectly configured application can be just as dangerous as an incorrectly coded one. To make matters worse, many configuration settings default to insecure values.

An additional problem is that Web.config files were designed to be changed at any time, even after the application is in production. A well-intentioned system administrator could inadvertently open the Web site to attack just by modifying the configuration file. And because .NET configuration files operate in a hierarchical manner, a single change to the global Machine.config file could affect every Web site on the entire network.

This article lists ten of the "worst offenders" of security misconfigurations, and demonstrates their potential impact on your applications. It also provides some best practices for locking down your configuration files to ensure that they are not unintentionally modified by well-meaning (but uninformed) programmers or administrators.

In itself, knowing the source of an error may not seem like a security risk, but consider this: The more information a hacker can gather about a Web site, the more likely it is that he will be able to successfully attack it. For example, the error message lists the Web server being used, the operating system, database types, etc. All of these bits of data help hackers trying to compromise your application. An error message can be a gold mine of information to an attacker. For example, take the sample ASP.NET error page shown in Figure 1.

By simply looking at the error page in Figure 1, an attacker can see that the application is using the .NET framework version 2.0.50727.42 and ASP.NET version 2.0.50727.42. Knowing that, he can search the Web for known security advisories concerning these specific product versions. Also, knowing that the application uses ASP.NET 2.0 tells him that the server is running a recent version of Microsoft Windows (either XP or Server 2003) and that Microsoft Internet Information Server (IIS) 6.0 or later is being used as the Web server. This leads to more searching for security advisories. The hacker can also determine that the application is using Microsoft SQL Server as its database, because the exception type thrown was a SqlException, which is specific to Microsoft SQL Server. Finally, the real prize for the hacker is the exception message, which tells him that the command being sent to the database was created in an ad-hoc fashionand therefore that the page is likely vulnerable to SQL injection attacks.

You can prevent such information leakage by modifying the mode attribute of the <customErrors> element to On or RemoteOnly. This setting instructs the Web application to display a nondescript, generic error message when an unhandled exception is generated (see Figure 2).

Figure 1. Detailed Error Message: From the information shown in this error message, an attacker can discover the ASP.NET and .NET framework versions, that the application uses SQL Server, and that the application may be vulnerable to SQL injection attacks.

Another way to circumvent the problem is to create your own custom error page and redirect users to that page when errors occur. You can specify the page by setting the defaultRedirect attribute of the <customErrors> element. This approach can provide even better security because the default generic error page shown in Figure 2 still gives away too much information about the system (namely, that it's using a Web.config file, which reveals that the server is running ASP.NET). Your custom page can be as generic and unspecific as you like, and should not reveal any details of the application or the server environment.