Login | Register   
LinkedIn
Google+
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 5

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
9. Non-Unique Authentication Cookie Used
Over the last few sections I hope I have successfully demonstrated the importance 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 a security vulnerability just as dangerous as an improperly chosen storage location.

Vulnerable: Secure:

<configuration>
<system.Web>
<authentication mode="Forms">
<forms name="ASPXAUTH">

<configuration>
<system.Web>
<authentication mode="Forms">
<forms name="{abcd1234…}">


The default value for the name of the authentication cookie is .ASPXAUTH. If you have only one Web 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 more than one ASP.NET application, 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 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 each Web application on your server has its own set of authorized users is to change the authentication cookie name to a unique value. Globally Unique Identifiers (GUIDs) are excellent choices 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.

10. Hardcoded Credentials Used
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 applications that require authentication because developers and administrators often use test credentials to test the system. The question is: Where do the test credentials come from?

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 the application.

Vulnerable: Secure:


<configuration>
<system.Web>
<authentication mode="Forms">
<forms>
<credentials>
...
</credentials>
</forms>

<configuration>
<system.Web>
<authentication mode="Forms">
<forms>
</forms>


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.

You're Not Out of the Woods Yet
Now that you've finished reading the top-ten list, and you've checked your configuration settings, your applications are secure forever, right? Not just yet. Web.config files operate in a hierarchical inheritance manner. Every Web.config file inherits values from any Web.config file in a parent directory. That Web.config file in turn inherits values from any Web.config file in its parent directory, and so on. All Web.config files on the system inherit from the global configuration file called Machine.config located in the .NET framework directory. The effect of this is that the runtime behavior of your application can be altered simply by modifying a configuration file in a higher directory.

This can sometimes have unexpected consequences. A system administrator might make a change in a configuration file in response to a problem with a completely separate application, but that change might create a security vulnerability in your application. For example, a user might report that he is not able to access the application without enabling cookies in his browser. The administrator, trying to be helpful, modifies the global configuration file to allow cookieless authentication for all applications.

To keep your application-specific settings from being unexpectedly modified, the solution is to never rely on default setting values. For example, debugging is disabled by default in configuration files. If you're examining the configuration file for your application and you notice that the debug attribute is blank, you might assume that debugging is disabled. But it may or may not be disabled—the applied value depends on the value in parent configuration settings on the system. The safest choice is to always explicitly set security-related values in your application's configuration.

Ultimately, securing a Web application requires the efforts and diligence of many different groups, from quality assurance to security operations. However, the developer who codes the application itself has an inherent responsibility to instill security into the application from the beginning of the development process. By making security-conscious decisions from the beginning, developers can create applications that users can trust with their confidential information and that are capable of withstanding attacks launched by hackers. As I've tried to show here, sometimes that process can be as simple as making the right decisions when configuring your application.



Bryan Sullivan is a development manager at SPI Dynamics, a Web application security products company. Bryan manages the DevInspect and QAInspect Web security products, which help programmers maintain application security throughout the development and testing process.
Comment and Contribute

 

 

 

 

 


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

 

 

Sitemap