Want to secure your MS .NET Application? Start with securing your web.config file?

Let me start this article saying that even the most secure VB.NET or C# code can still be vulnerable to various attack vectors if as a developer you neglect the enhanced security configurations of web.config file. To make matters worse Web.config files were designed to be changed at any time, even after the Web-based applications are in production and many default configuration settings are insecure by itself. Actually it is true that some of the most common vulnerabilities with ASP.NET applications come not with its backend server side codes VB.NET or C# but instead from the XML code that makes up its Web.config files.

In this article I will discuss some of these configurations of web.config file which if not properly configured might lead to application security holes such as session hijacking, Cross-Site Scripting attacks, and even allow the disclosure of private data to attackers.

Custom Error configuration:

Every piece of information an attacker receives about a targeted system or application is a valuable weapon. If the configuration is not set then in event of an unhandled exception the application returns details of that error to the end user which might reveal critical information about the underlying application/system.

Two most common misconfigurations:

Custom error message mode is turned off. An ASP.NET error message with detailed stack trace and platform versions will be returned.

Custom error message mode for remote user only. No defaultRedirect error page specified. The local user on the web server will see a detailed stack trace. For remote users, an ASP.NET error message with the server configuration setting and the platform version will be returned.

Secure configuration:

This will redirect the user to a custom error page when error occurs.

Debugging configuration:

If ASP.NET debugging is enabled and customError is not set then in the event of an exception, applications 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.

Vulnerable configuration:

Secure configuration:

“httpOnly” cookie attributes:

“httpOnly” attribute of cookies can guard your application against cookie theft through execution of client side scripts like JavaScript or VBScript. This shielding of cookies from the client helps to protect Web-based applications from Cross-Site Scripting attacks. Though it is possible to enable httpOnly cookie attribute in code however, it is easier and more reliable to configure the application to automatically enable HttpOnly for all cookies. To do this, set the httpOnlyCookies attribute of the element of web.config file to true.

Secure configuration:

Tracing feature enabled:

Any user can view detailed list of recent requests to the application by simply browsing to the page trace.axd if element of the web.config file is enabled for remote users. A trace log might disclose information such as ASP.NET version, 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.

Vulnerable configuration:

Secure configuration:

Cookieless Session State Enabled:

Microsoft added support for cookieless session tokens via use of the “cookieless” setting from .NET version 1.1 and onwards. Web applications configured to use cookieless session state now stored the session token in the page URLs rather than a cookie. For example, the page URL might change from http://www.example.com/myapp/index.aspx http://www.example.com/myapp/(123456789ABCDEFG)index.aspx

Where 123456789ABCDEFG is the session id for the user’s valid session.

While adding support for cookieless session state did improve the usability of ASP.NET Web applications for users who would not accept cookies, it also had the side effect of making those applications much more vulnerable to session hijacking attacks.

Vulnerable configuration:

Secure configuration:

Note that Web.config files operate in a hierarchical inheritance manner. Every Web.config file inherits values from any Web.config file in a parent directory. All Web.config files on the system inherit from the global configuration file called machine.config located in

Set up users and groups, and secure the pages of your site in ASP.NET 3.5 with no coding! Using Visual Studio 2008.
Video Rating: 4 / 5

Find More ASP.NET Articles