Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Top 10 Security Vulnerabilities in .NET Configuration Files : Page 2

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.


advertisement
2. Leaving Tracing Enabled
The trace feature of ASP.NET is one of the most useful tools that you can use to debug and profile your applications. Unfortunately, it is also one of the most useful tools that a hacker can use to attack your applications if it tracing is left enabled in a production environment.

Vulnerable: Secure:

<configuration>
<system.Web>
<trace enabled="true" localOnly="false">

<configuration>
<system.Web>
<trace enabled="false" localOnly="true">


When the <trace> element is enabled for remote users (localOnly="false"), any user can view an incredibly detailed list of recent requests to the application simply by browsing to the page trace.axd. They'll see a page similar to Figure 3 and Figure 4.

 
Figure 3. Trace.axd Output: This detailed Trace output contains complete request information, including the values of form and server variables.
 
Figure 4. Trace.axd Output (continued): This detailed Trace output contains complete request information, including the values of form and server variables.
If a detailed exception message such as Figure 1 is like a gold mine to a hacker, a trace log as shown in Figure 3 and Figure 4 is like Fort Knox! Just look at the wealth of information: the .NET and ASP.NET versions that the server is running; a complete trace of all the page methods that the request caused, including their times of execution; the session state and application state keys; the request and response cookies; the complete set of request headers, form variables, and QueryString variables; and finally the complete set of server variables.

A hacker would obviously find the form variables useful because these might include email addresses that could be harvested and sold to spammers, IDs and passwords that could be used to impersonate the user, or credit card and bank account numbers. Even the most innocent-looking piece of data in the trace collection can be dangerous in the wrong hands. For example, the APPL_PHYSICAL_PATH server variable, which contains the physical path of the application on the server, could help an attacker perform directory traversal attacks against the system.

The best way to prevent a hacker from obtaining trace data is to disable the trace viewer completely by setting the enabled attribute of the <trace> element to false. If you must have the trace viewer enabled, either to debug or to profile your application, then be sure to set the localOnly attribute of the <trace> element to true. This setting allows users to access the trace viewer only from the Web server and disables viewing it from any remote machine.

3. Leaving Debugging Enabled
Deploying a Web application in debug mode is a very common mistake. Virtually every Web application requires some debugging. Visual Studio 2005 will even automatically modify the Web.config file to allow debugging when you start to debug your application. And, since deploying ASP.NET applications is as simple as copying the files from the development folder into the deployment folder, it's easy to see how development configuration settings can accidentally make it into production.

Vulnerable: Secure:


<configuration>
<system.Web>
<compilation debug="true">

<configuration>
<system.Web>
<compilation debug="false">


 
Figure 5. Detailed Error Message with Source Code: Leaving debugging enabled causes the server to output detailed information, including source code where the error occurred.
Like the first two security vulnerabilities described in this list, leaving debugging enabled is dangerous because you are providing inside information to end users who shouldn't have access to it, and who may use it to attack your applications. For example, if you have enabled debugging and disabled custom errors in your application, then any error message displayed to an end user will include not only the server information, a detailed exception message, and a stack trace, but also the actual source code of the page where the error occurred (see Figure 5).

Unfortunately, this configuration setting isn't the only way that source code might be displayed to the user. Here's a story that illustrates how developers can't concentrate solely on one type of configuration setting to improve security. In early versions of Microsoft's Atlas framework, some Atlas controls would return a stack trace with source code to the client browser whenever exceptions occurred. This behavior happened regardless of the custom error setting in the configuration. So, even if you properly configured your application to display non-descriptive messages when errors occurred, you could still have unexpectedly revealed your source code to your end users if you forgot to disable debugging.

To disable debugging, set the value of the debug attribute of the <compilation> element to false. This is the default value of the setting, but as we will see, it's safer to explicitly set the desired value rather than relying on the defaults.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap