Application Security in Web.config Files

hey guys,

here is a tip for application Security for web.config files

Custom Errors Disabled
When you disable custom errors as shown below, ASP.NET provides a detailed error message to clients by default.
Vulnerable configuration:
<configuration>
<system.web="Off">
Secure configuration:
<configuration>
<system.web="RemoteOnly">

__________________
H2O

Without us, no one can survive..

hi,

Leaving Tracing Enabled in Web-Based Applications

The trace feature of ASP.NET is one of the most useful tools that you can use to ensure application security by debugging and profiling your Web-based applications. Unfortunately, it is also one of the most useful tools that a hacker can use to attack your Web-based applications if it is left enabled in a production environment.

Vulnerable configuration:<configuration>
<system.web="true" localOnly="false">
Secure configuration:
<configuration>
<system.web="false" localOnly="true">

When the <trace> element is enabled for remote users of Web-based applications (localOnly="false"), any user can view an incredibly detailed list of recent requests to the application simply by browsing to the page "trace.axd." If a detailed exception message is like a gold mine to a hacker looking to circumvent application security, a trace log is like Fort Knox! A trace log presents a 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.

__________________
G.A.P

hi,

Debugging Enabled

Deploying Web-based applications in debug mode is a very common mistake. Virtually all Web-based applications require 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, compromising application security.

Vulnerable configuration:

<configuration>
<p> <system.web="true"> </p>
Secure configuration:
<configuration>
<system.web="false">

Like the first two application 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 Web-based applications. For example, if you have enabled debugging and disabled custom errors in your application, then any error message displayed to an end user of your Web-based 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

hi,

Cookies Accessible through Client-Side Script

In Internet Explorer 6.0, Microsoft introduced a new cookie property called "HttpOnly." While you can set the property programmatically on a per-cookie basis, you also can set it globally in the site configuration.

Vulnerable configuration:

<configuration>
<system.web="false">
Secure configuration:
<configuration>
<system.web="true">

Any cookie marked with this property will be accessible only from server-side code, and not to any client-side scripting code like JavaScript or VBScript. This shielding of cookies from the client helps to protect Web-based applications from Cross-Site Scripting attacks. A hacker initiates a Cross-Site Scripting (also called CSS or XSS) attack by attempting to insert his own script code into the Web page to get around any application security in place. Any page that accepts input from a user and echoes that input back is potentially vulnerable. For example, a login page that prompts for a user name and password and then displays "Welcome back, <username>" on a successful login may be susceptible to an XSS attack.

__________________
J Suresh Kumar
Google Hacks

Cookieless Session State Enabled

In the initial 1.0 release of ASP.NET, you had no choice about how to transmit the session token between requests when your Web application needed to maintain session state: it was always stored in a cookie. Unfortunately, this meant that users who would not accept cookies could not use your application. So, in ASP.NET 1.1, Microsoft added support for cookieless session tokens via use of the "cookieless" setting.

Vulnerable configuration:

<configuration>
<system.web="UseUri">

Secure configuration:
<configuration>
<system.web="UseCookies">
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://myserver/MyApplication/default.aspx to http://myserver/MyApplication/(12345...)/default.aspx. In this case, "123456789ABCDEFG" represents the current user's session token. A different user browsing the site at the same time would receive a completely different session token, resulting in a different URL, such as http://myserver/MyApplication/(ZYXWV...)/default.aspx

Hi,

Authentication and Authorization Application Security Issues

One of the most common and dangerous application security vulnerabilities that exist in ASP.NET Web-based applications come not from the C# or VB.NET code that make up its pages and service methods, but instead from the XML code that makes up its Web.config files. Incorrect configurations can open Web sites to application security holes such as session hijacking, Cross-Site Scripting attacks, and even allow the disclosure of private data to attackers.
An additional problem is that Web.config files were designed to be changed at any time, even after the Web-based applications are in production. A well-intentioned system administrator could inadvertently get around application security measures and 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.
Part one of this article listed five of the most serious configuration vulnerabilities that are applicable to any ASP.NET Web-based applications. This part will focus on authentication and authorization application security issues, and detail another five vulnerabilities commonly found in ASP.NET Web-based applications using Forms authentication. It will also provide some best practices for application security, including locking down your configuration files to ensure that they are not unintentionally modified by well-meaning (but uninformed) programmers or administrators.

hi,

Cookieless Authentication Enabled

Just as in the "Cookieless Session State Enabled" vulnerability discussed in part one, enabling cookieless authentication in your Web-based applications can lead to session hijacking and problems with application security.

Vulnerable configuration:

<configuration>
<system.web>
<authentication mode="Forms">
<forms cookieless="UseUri">

Secure configuration:

<configuration>
<system.web>
<authentication mode="Forms">
<forms cookieless="UseCookies">

When a session or authentication token appears in the request URL rather than in a secure cookie, an attacker with a network monitoring tool can get around application security, easily take over that session, and effectively impersonate a legitimate user. However, session hijacking has far more serious consequences for application security after a user has been authenticated. For example, online shopping sites generally utilize Web-based applications that allow users to browse without having to provide an ID and password. But when users are ready to make a purchase, or when they want to view their order status, they have to login and be authenticated by the system. After logging in, sites provide access to more sensitive data, such as a user's order history, billing address, and credit card number. Attackers hijacking this user's session before authentication can't usually obtain much useful information. But if the attacker hijacks the session after authentication, all that sensitive information could be compromised.
The best way to prevent session hijacking with Web-based applications is to disable cookieless authentication and force the use of cookies for storing authentication tokens. This application security measure is added by changing the cookieless attribute of the forms element to the value UseCookies.

Hi,

Failure to Require SSL for Authentication Cookies

Web-based applications use the Secure Sockets Layer (SSL) protocol to encrypt data passed between the Web server and the client. Using SSL for application security means that attackers using network sniffers will not be able to interpret the exchanged data. Rather than seeing plaintext requests and responses, they will see only an indecipherable jumble of meaningless characters.
You can require the forms authentication cookie from your Web-based applications to use SSL by setting the requireSSL attribute of the forms element to true.

Vulnerable configuration:

<configuration>
<system.web>
<authentication mode="Forms">
<forms requireSSL="false">

Secure configuration:

<configuration>
<system.web>
<authentication mode="Forms">
<forms requireSSL="true">
The previous section discussed the importance of transmitting the authentication token in a cookie, rather than embedding it in the request URL. However, disabling cookieless authentication is just the first step towards securing the authentication token. Unless requests made to the Web server are encrypted, a network sniffer will still be able to read the authentication token from the request cookie. An attacker would still be able to hijack the user's session.
At this point, you might be wondering why it is necessary with application security to disable cookieless authentication, since it is very inconvenient for users who won't accept cookies, and seeing as how the request still has to be sent over SSL. The answer is that the request URL is often persisted regardless of whether or not it was sent via SSL. Most major browsers save the complete URL in the browser history cache. If the history cache were to be compromised, the user's login credentials would be as well. Therefore, to truly secure the authentication token, you must require the authentication token to be stored in a cookie, and use SSL to ensure that the cookie be transmitted securely.

hi,

Sliding Expiration Used

All authenticated ASP.NET sessions have a timeout interval to protect the application security. The default timeout value is 30 minutes. So, 30 minutes after a user first logs into any of these Web-based applications, he will automatically be logged out and forced to re-authenticate his credentials.

Vulnerable configuration:

<configuration>
<system.web="Forms">
<forms slidingExpiration="true">
<configuration>
<system.web="Forms">
<forms slidingExpiration="false">

The slidingExpiration setting is an application security measure used to reduce risk to Web-based applications in case the authentication token is stolen. When set to false, the specified timeout interval becomes a fixed period of time from the initial login, rather than a period of inactivity. Attackers using a stolen authentication token have, at maximum, only the specified length of time to impersonate the user before the session times out. Because typical attackers of these Web-based applications have only the token, and don't really know the user's credentials, they can't log back in as the legitimate user, so the stolen authentication token is now useless and the application security threat is mitigated. When sliding expiration is enabled, as long as an attacker makes at least one request to the system every 15 minutes (or half of the timeout interval), the session will remain open indefinitely. This gives attackers more opportunities to steal information and cause other mischief in Web-based applications.
To avoid this application security issue altogether, you can disable sliding expiration by setting the slidingExpiration attribute of the forms element to false.

hi,

Non-Unique Authentication Cookie Used

Over the last few sections, I hope I have successfully demonstrated the importance of application security and of storing your application's authentication token in a secure cookie value. But a cookie is more than just a value; it is a name-value pair. As strange as it seems, an improperly chosen cookie name can create an application security vulnerability just as dangerous as an improperly chosen storage location.

Vulnerable configuration:

<configuration>
<system.web="Forms">
<forms name=".ASPXAUTH">

Secure configuration:

<configuration>
<system.web="Forms">
<forms name="{abcd1234…}">

The default value for the name of the authentication cookie is .ASPXAUTH. If you have only one Web-based application on your server, then .ASPXAUTH is a perfectly secure choice for the cookie name. In fact, any choice would be secure. But, when your server runs multiple ASP.NET Web-based applications, it becomes critical to assign a unique authentication cookie name to each application. If the names are not unique, then users logging into any of the Web-based applications might inadvertently gain access to all of them. For example, a user logging into the online shopping site to view his order history might find that he is now able to access the administration application on the same site and change the prices of the items in his shopping cart.
The best way to ensure that all Web-based applications on your server have their own set of authorized users is to change the authentication cookie name to a unique value. Globally Unique Identifiers (GUIDs) are excellent choices for application security since they are guaranteed to be unique. Microsoft Visual Studio helpfully includes a tool that will automatically generate a GUID for you. You can find this tool in the Tools menu with the command name "Create GUID". Copy the generated GUID into the name attribute of the forms element in the configuration file.

__________________
H2O

Without us, no one can survive..

hi,

Hardcoded Credentials Used

Vulnerable configuration:

<configuration></configuration>
<system.web="Forms">
<forms>
<credentials></credentials>

</forms>
</authentication>
...
</system.web>


Secure configuration:

<configuration></configuration>
<system.web="Forms">
<forms>

</forms>
</authentication>
...
</system.web>

A fundamental difficulty of creating software is that the environment in which the application will be deployed is usually not the same environment in which it is created. In a production environment, the operating system may be different, the hardware on which the application runs may be more or less powerful, and test databases are replaced with live databases. This is an issue for creating Web-based applications that require authentication because developers and administrators often use test credentials to test the application security

Where do the test credentials come from?

__________________
H2O

Without us, no one can survive..

Hi,

For convenience, to avoid forcing developers from spending time on creating a credential store used solely for test purposes (and which would subsequently be discarded when the application went to production), Microsoft added a section to the Web.config file that you can use to quickly add test users to Web-based applications. For each test user, the developer adds an element to the configuration file with the desired user ID and password as shown below:

<authentication mode="Forms">
<forms>
<credentials>
<user name="bob" password="bob"/>
<user name="jane" password="Elvis"/>
</credentials>
</forms>
</authentication>

While undeniably convenient for development purposes, this was never intended for use in a production environment. Storing login credentials in plaintext in a configuration file is simply not secure. Anyone with read access to the Web.config file could access the authenticated Web application. It is possible to store the SHA-1 or MD5 hash of the password value, rather than storing the password in plaintext. This is somewhat better, but it is still not a secure solution. Using this method, the user name is still not encrypted. First, providing a known user name to a potential attacker makes it easier to perform a brute force attack against the system. Second, there are many reverse-lookup databases of SHA-1 and MD5 hash values available on the Internet. If the password is simple, such as a word found in a dictionary, then it is almost guaranteed to be found in one of these hash dictionaries.
The most secure way to store login credentials is to not store them in the configuration file. Remove the credentials element from your Web.config files in production applications.