Protect confidential data in ASP. NET 2.0

Protect confidential data in ASP. NET 2.0 released on: 2006-6-13 | updated on: 2006-6-13

Download the code in this article:Extremeaspnet05.exe(118kb)

Content on this page

	Wait. You cannot do this.
	ASP. NET 1.1-better confidentiality
	ASP. NET 2.0 secrets
	Better secret
	Conclusion

It is difficult to store data securely in the configuration system. In my early years, when I was working in the ASP. NET team, this particular feature (securely storing connection strings) seemed to not be implemented. It is surrounded by numerous problems (such as key storage), hindering the road to understanding the decision. Fortunately, this problem is not only finally solved, but also integrated into ASP. NET 2.0 powerful latest API combination, allowing you to manage ASP.. Net configuration file.

However, before in-depth exploration of ASP. NET 2.0, let's take a look at this issue and understand ASP. NET 1.X. As long as you have used ASP. NET, you will undoubtedly understand the benefits of storing sharing settings in the web. config file. For example, you do not need to specify a connection string every time you create a new database connection. Instead, you can store the string in the <etettings/> section of the ASP. NET configuration file. In this way, you can access the connection string through the configurationsettings. deleettings attribute. The following is an example of the <ettings/> section:

<?xml version="1.0" encoding="utf-8" ?><configuration>  <appSettings>    <add key="ConnectionString"          value="server=.;database=demo;uid=db;pwd=*u%a" />  </appSettings></configuration>

In this way, whenever you need to change the connection string, you only need to open the file and execute the change.

Many developers from traditional ASP to ASP. NET have a deep understanding of this function, because most global values are stored in the form of application variables. In fact, for ASP. NET 1.X, It is recommended to store the connection string in <etettings/>. It is worth noting that you can also store other frequently-used data in <etettings/>, including the LDAP path, frequently-used application settings, and other data required by the application. <Etettings/> aims to simplify the compilation of the custom configuration section processing program, which is a more advanced technology for interacting with the ASP. NET Configuration System. The custom configuration section handler allows you to create and process your own XML section in the configuration system.

You may have noticed that the content stored in <deleettings/> is not encrypted, but stored in plain text. The same is true for the <sessionstate/> section. This section supports session data storage outside the process. An alternative storage method is to use SQL Server and store creden。 in plain text in the <sessionstate/> Configuration location.

Wait. You cannot do this.

The disadvantage of storing the connection string in <deleetask/> is that security cannot be guaranteed because the file is not encrypted or compiled. It does not mean that compiling configuration information will help enhance security. DVD manufacturers use key-based encryption methods to protect intellectual property rights, the method is to simply store the decryption key in their compilation code by the DVD player software vendor. A small piece of code written by some hackers can easily find the decryption key. We often see such a post in personal network logs. If someone wants to figure out how something works in Microsoft. NET Framework, someone will suggest: "Try reflector ."

Back to Top

ASP. NET 1.1-better confidentiality

In ASP. NET 1.0, if no additional custom code exists, the connection string cannot be securely stored in the configuration file. The ASP. NET team solved this problem in ASP. NET 1.1 by enabling encryption for several configuration entries. This solution is implemented through Windows Data Protection API (dpapi) to encrypt the following configuration entries:

<Identity/> stores the Windows identity of the ASP. NET auxiliary process for simulation.

<Processmodel/> is used to control windows accounts under which ASP. NET auxiliary processes are executed. Not used in IIS 6.0 (see the following notes ).

<Sessionstate/> includes the stateconnectionstring and sqlconnectionstring attributes. It is used to control ASP. NET's method of verifying servers in non-Process status.

It is important to note that IIS 6.0 (a web server attached to Windows Server 2003) provides its own auxiliary process management subsystem, and ASP. NET is compliant with the system. Therefore, some auxiliary process settings in the configuration system are not used when ASP. NET is hosted by IIS 6.0.

ASP. NET 1.1 provides a tool named aspnet_setreg.exe to encrypt data in the configuration file and store the decryption key in the Windows registry key. The obtained registry key has an access control list (ACL), which is configured to restrict the Windows account that has the right to access this key. "Knowledge Base" ArticleQ329290This technique is described in detail in "how to use ASP. NET utility to encrypt creden and session State connection strings.

However, this solution also has some disadvantages. It destroys the xcopy deployment favored by the ASP. NET team. This function allows you to deploy ASP. NET applications without having to access the server. Using the technology mentioned above, developers or system administrators must have access to the local computer before they can run the command line tool to encrypt the configuration data and store the key in the registry.

Back to Top

ASP. NET 2.0 secrets

Next we can start to discuss all the work the team has done to solve this problem in ASP. NET 2.0. Another command line tool for managing and configuring data encryption is aspnet_regiis.exe. Aspnet_regiis.exe exists in earlier versions of ASP. NET and is mainly used to manually register ASP. NET with IIS. For example, you can use it to add aspnet_isapi.dll to IIS and configure the script directory used by ASP. NET applications. You can go to/Windows/Microsoft. NET/framework/Version Number/Directory.

The process of using aspnet_regiis.exe to encrypt the configuration section is as confusing as it generates! See the execution results of aspnet_regiis.exe/help in Figure 1.

Figure 1 encrypt configuration data

As you can see, unless you are very familiar with security terms, you will soon be dazzled by a large number of options and various settings. Unfortunately, despite its powerful functionality, various tools are messy. Fortunately, the Microsoft pattern and implementation solution team has written an important and in-depth article titled"How to: encrypt configuration sections in ASP. NET 2.0 using dpapi", Which guides you through aspnet_regiis.exe.

Now we will not study how to use aspnet_regiis.exe. First, let's look at an ASP. NET Sample Page, which uses the new configuration API to encrypt the configuration section. This page, that is, connectionencryption. aspx (fromMsdnMagazineWebsite), contains a gridview, which is filled with the list of all configuration sections. 2.

Figure 2 use the new configuration API

Before studying how connectionencryption. aspx works, let's take a look at the results of this page. However, a warning is given: this tool requires that ASP. Net-hosted processes have write permissions on the Web. config file of the current application. By default, ASP. NET Applications Running in IIS do not have the necessary permissions. However, applications hosted in ASP. NET development web server run with the permission set of logged-on users. All usage of the tool you see here is displayed in ASP. NET development web server. We recommend that you perform the change when you fully understand the impact of modifying the IIS permission settings.

The following is an example of the new <connectionstrings> section used to store connection strings in Web. config. The <connectionstrings> section is almost the same as the <etettings> section. Currently, we recommend that you store connection string data in the former section, because a new API can specifically process connection strings distributed in ASP. NET:

<connectionStrings>  <add name="Northwind" providerName="System.Data.SqlClient"      connectionString="Server=localhost;Integrated           Security=True;Database=Northwind" /></connectionStrings>

Note that in this case, Windows verification is still used to connect to the database.

Click the encrypt (encrypted) link in connectionencryption. aspx to change the value of the connection string in Web. configFigure3. After encryption, The connectionencryption. ASPX page reports the status of the entry as encrypted (the link is changed to "decrypt" (decrypted), as you can see in Figure 4 ).

Figure 4 New Page

Now that the page has taken effect, let's take a look at the code. See row 18th in connectionencryption. aspx. cs. In page_load, when the new ASP. NET 2.0 webconfigurationmanager class retrieves the configuration class instance in the local path, it is filled with the gridview:

Configuration config =    WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);

Fill in the array list with the data retrieved from the configuration variable and bind it to the gridview. Most other methods in the source (see the downloaded code) are used for business logic rules related to the actual data binding operation, such as determining the range and status of the Section (encryption or unencryption ). When you click the encrypt (encrypted) or decrypt (decrypted) Link, a magic event occurs in the gridviewdomainrowcommand event. When the value of gridviewcommandevent. commandname is "encrypt" (encrypted), run the following code:

section.SectionInformation.ProtectSection(    "DataProtectionConfigurationProvider");config.Save();

When the value of gridviewcommandevent. commandname is "decrypt" (decryption), run the following code:

section.SectionInformation.UnprotectSection();config.Save();

In this way, the actual work of data encryption and decryption is transferred to the provider. A built-in provider is dataprotectionconfigurationprovider. It uses the built-in dpapi to store secure data, which is the same as that used by ASP. NET command line tools.

You should note that the provider can be specified during data encryption, but you do not need to specify the provider during decryption (if protectsection provides a null or empty string, the default provider specified in the configprotecteddata section of the configuration file will be used ). This is because the API writes another entry to the configuration file, which is used to specify the encryption protection provider used:

   <connectionStrings configProtectionProvider=           "DataProtectionConfigurationProvider">       <EncryptedData>...</EncryptedData>   </connectionStrings>

This configuration entry is used not only by the API to determine how to decrypt each section, but also in ASP. net needs to read the value (such as the connection string) into the memory, but must be decrypted first, for ASP. net is used internally.

One of the advantages of ASP. NET 2.0's new encryption feature is that you can not only encrypt many built-in configuration sections, but also write custom encryption providers! The provider is an amazing new extension model in ASP. NET 2.0, which enables developers to implement their own core functions, such as membership and personalization. In addition, in view of the implementation method of "Configuration Encryption", the custom configuration section can also be easily encrypted. Therefore, data protection is not like ASP.. NET 1.1 is limited to a few configuration sections.

Back to Top

Better secret

The column on encrypted confidential data is not a complete column if no warning is given. First, avoid confidentiality if possible. If you are using SQL Server and do not want to store sensitive connection string information in the configuration system, use the integration verification that comes with SQL Server. Windows verification is used to connect the application server to the database. With this technology, the connection to SQL Server is verified and authorized directly through windows. When Windows is used for verification, SQL Server requests a token from the verification server (whether local or remote), which contains the user's security identifier (SID) and other information, then compare the information with the list maintained by SQL Server to determine whether access is permitted or denied. No Password or user name is stored in the configuration file.

Another thing to remember is that simply securely storing the data in the configuration file does not mean you can escape all kinds of attacks. Any attacker who is competent (Security!) may cause great harm to you as long as he has sufficient permissions to access the Web. config file on your server. Attackers who obtain system access permissions and can process web. config can perform other operations to manipulate the database without knowing what the connection string is. Therefore, safe storage of your connection string or other application data is only one of the defense lines. Another effective defense measure is to use stored procedures and set more strict control over accounts that have access to your database. For example, if the SQL injection vulnerability exists, encrypted connection strings are useless (for more information about SQL injection attacks, seeMsdn.microsoft.com/msdnmag/issues/04/09/sqlinjection).

I have built and run many high-traffic websites (suchHttp://www.asp.net/), So the probability of my attacks is not lower than that of ordinary people. A common feature is that attacks often have nothing to do with initial vulnerabilities. Attackers will not attack through the initial vulnerability, but will try to protect the backdoor created by the initial vulnerability.

Back to Top

Conclusion

Although ASP. any version of net can protect ASP. NET application, but this is in ASP. NET 1.1 is easier to implement, but in ASP. NET 2.0 is even easier. With ASP. NET 2.0, Configuration Encryption is no longer a final solution. It has been built into the new configuration API. Use ASP. NET 2.0, you can not only use the aspnet_regiis.exe tool to encrypt the configuration section, but also write your own custom code (and custom providers, if needed) to encrypt and decrypt the configuration data.

For more information about Storing confidential data in ASP. NET 1.1, seeSecurity considerations for hosting ASP. NET version 1.1"(English ).

Please pass your questions and commentsXtrmasp@microsoft.comSend to rob.

Rob HowardHe is the founder of telligent systems and is committed to developing high-performance Web applications, knowledge management and collaboration systems. Rob once worked at Microsoft, where he helped design infrastructure functions for ASP. NET 1.0, 1.1, and 2.0. You can send an email to the rhoward@telligentsystems.com to contact Rob.

This article is taken from msdn magazine, which was released in May 2006.

Go to the original English page

Back to Top