1. Introduction
When creating ASP.NET 2.0 applications, developers usually store sensitive configuration information in the Web.config file. The most typical example is the database connection string, but other sensitive information included in the Web.config file includes SMTP server connection information and user credential data, etc. Although ASP.NET can be configured by default to deny all HTTP requests for file resources with a .config extension; however, if a hacker is able to access your web server's file system, sensitive Information can still be stolen. For example, perhaps you accidentally allowed anonymous FTP access to your website, thereby allowing a hacker to simply download your Web.config file via the FTP protocol.
Fortunately, ASP.NET 2.0 helps alleviate this problem by allowing you to encrypt selected portions of the Web.config file, such as the <connectionStrings> section, or some custom config section used by your application. Configuration sections can easily be pre-encrypted using encoding or aspnet_regiis.exe (a command line program). Once encrypted, Web.config settings are protected from prying eyes. Furthermore, when programmatically retrieving encrypted configuration settings from your ASP.NET page, ASP.NET automatically decrypts the encrypted portion it reads. In short, once the configuration information is encrypted, you do not need to write any other code or take any further actions in your application to use the encrypted data.
In this article, we will discuss how to programmatically encrypt and decrypt this configuration settings section, and examine the use of the command line program aspnet_regiis.exe. We will then evaluate the encryption options provided by ASP.NET 2.0. Additionally, we briefly discuss how to encrypt configuration information in ASP.NET version 1.x.
2. Premise
Before we start discussing how to encrypt ASP.NET 2.0 configuration information, please remember the following points:
1. All forms of encryption contain some kind of secret, and this secret is used when encrypting and decrypting data. Symmetric encryption algorithms use the same key when encrypting and decrypting a message, while asymmetric encryption algorithms use different keys for encryption and decryption. No matter which technology is used, the most important thing is how secure the decryption key is.
2. The configuration encryption technology provided by ASP.NET 2.0 is designed to prevent hackers from being able to retrieve your configuration files in some way. The idea is that if there is your Web.config file on the hacker's computer, then he cannot crack the encrypted part. However, when an ASP.NET page on the web server requests information from an encrypted configuration file, the data must be decrypted before it can be used (and this happens without you writing any code). Therefore, if a hacker is able to upload an ASP.NET web page to your system that queries the configuration file and displays its results, then he can view the encrypted settings as plain text. (For details, please refer to the sample ASP.NET page provided in this article, which shows how to encrypt and decrypt various parts of the Web.config file; as you can see, an ASP.NET page can access (and display) the encrypted data (ordinary text form)
3. Encrypting and decrypting configuration information requires a certain performance cost. Therefore, it is common to encrypt only the portions of the configuration that contain sensitive information. For example, there may be no need to encrypt the <compilation> or <authorization> configuration sections.
3. What kind of information can be encrypted?
Before we analyze how to encrypt ASP.NET 2.0 configuration information, let us first take a look at what configuration information can be encrypted. Using libraries provided by the .NET Framework 2.0, developers can encrypt most configuration sections in a Web.config or machine.config file. These configuration parts are XML elements that are child nodes of the <configuration> or <system.web> element. For example, the following sample Web.config file contains three configuration settings, explicitly defined as:
<connectionStrings>, <compilation>, and <authentication>.
＜?xml version="1.0"?＞
＜configuration xmlns=" http://schemas.microsoft.com/.NetConfiguration/v2.0 "＞
＜connectionStrings＞
＜add name="MembershipConnectionString" connectionString="connectionString"/＞
＜/connectionStrings＞
<system.web>
＜compilation debug="true"/＞
＜authentication mode="Forms" /＞
</system.web>
Each of these sections can optionally be encrypted, either programmatically or via aspnet_regiis.exe (a command line tool). When encrypted, the encrypted text is stored directly in the configuration file. For example, if we were to encrypt the <connectionStrings> section above, the resulting Web.config file might look like this: (Note: Due to space limitations, we have omitted a large chunk of <CipherValue>)
<?xml version="1.0 "?＞
＜configuration xmlns=" http://schemas.microsoft.com/.NetConfiguration/v2.0 "＞
＜connectionStrings configProtectionProvider="DataProtectionConfigurationProvider"＞
＜EncryptedData＞
＜CipherData＞
＜CipherValue＞AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAAed...GicAlQ==＜/CipherValue＞
＜/CipherData＞
＜/EncryptedData＞
＜/connectionStrings＞
<system.web>
＜compilation debug="true"/＞
＜authentication mode="Forms" /＞
＜/system.web＞
Additionally, there are some configuration parts that you cannot encrypt using this technique:
· ＜processModel＞
· ＜runtime＞
· ＜mscorlib＞
·＜startup＞
· ＜system.runtime.remoting＞
· ＜configProtectedData＞
· ＜satelliteassemblies＞
· ＜cryptographySettings＞
· ＜cryptoNameMapping＞
· <cryptoClasses>
In order to encrypt these configuration parts, you must encrypt these values and store it in the registry. There is an aspnet_setreg.exe command line tool that can help you with this process; we will discuss this tool later in this article.
[Tip] The difference between Web.Config and Machine.Config:
The Web.config file specifies the configuration settings for a specific web application and is located in the root directory of the application; while the machine.config file specifies all configuration settings located on the web server. Configuration settings for the site on and located in the $WINDOWSDIR$Microsoft.NetFrameworkVersionCONFIG directory.
4. Encryption options
Developers can use the ASP.NET 2.0 provider model to protect configuration section information, which allows any implementation to be seamlessly plugged into the API. The .NET Framework 2.0 provides two built-in providers for protecting configuration section information:
· Windows Data Protection API (DPAPI) provider (DataProtectionConfigurationProvider): This provider uses Windows' built-in cryptography technology to encrypt and decrypt configuration sections. By default, this provider uses the native key. You can also use user keys, but this requires a bit of customization.
· RSA protected configuration provider (RSAProtectedConfigurationProvider): Uses RSA public key encryption to encrypt and decrypt configuration sections. Using this provider, you need to create a key container that stores the public and private keys used to encrypt and decrypt configuration information. You can use RSA in a multi-server farm by creating exportable key containers.
Of course, you can also create your own protection settings provider if needed.
In this article, we only discuss using machine-level keys using the DPAPI provider. This is by far the simplest method as it does not require the creation of any keys or key containers. The downside, of course, is that an encrypted configuration file can only be used on the web server that implemented encryption in the first place; furthermore, using a machine key will allow the encrypted text to be decrypted by any site on the web server.
5. Encrypt the configuration section programmatically.
The System.Configuration.SectionInformation class abstracts the description of a configuration section. To encrypt a configuration section, simply use the ProtectSection(provider) method of the SectionInformation class, passing the name of the provider you want to use to perform encryption. To access a specific configuration section in your application's Web.config file, you can use the WebConfigurationManager class (in the System.Web.Configuration namespace) to reference your Web.config file, and then use its GetSection The (sectionName) method returns a ConfigurationSection instance. Finally, you can obtain a SectionInformation object via the SectionInformation property of the ConfigurationSection instance.
Below, we illustrate the problem through a simple code example:
privatevoid ProtectSection(string sectionName, string provider)
{
Configuration config = WebConfigurationManager.
OpenWebConfiguration(Request.ApplicationPath);
ConfigurationSection section = config.GetSection(sectionName);
if (section != null &&!section.SectionInformation.IsProtected)
{
section.SectionInformation.ProtectSection(provider);
config.Save();
}
}
private void UnProtectSection(string sectionName) {
Configuration config =WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);
ConfigurationSection section = config.GetSection n(sectionName);
if (section != null && section.SectionInformation.IsProtected)
{
section.SectionInformation.UnprotectSection();
config.Save();
}
You can call this ProtectSection(sectionName, provider) method from an ASP.NET page, its corresponding parameters are a section name (such as connectionStrings) and a provider (such as DataProtectionConfigurationProvider), and it opens the Web.config file, referencing In this section, the ProtectSection(provider) method of the SectionInformation object is called, and finally the configuration changes are saved.
On the other hand, the UnProtectSection(provider) method implements decryption of a specific configuration section. Here, only the section to be decrypted needs to be passed in - we don't need to bother the provider since that information is already stored in the tag accompanying the encrypted section (that is, the <connectionStrings> section in the example above, which is encrypted Later, it includes the provider: <connectionStringsconfigProtectionProvider="DataProtectionConfigurationProvider">).
Remember that once this data is encrypted, when reading it from an ASP.NET page (that is, reading the connection string information from a SqlDataSource control or programmatically via ConfigurationManager.ConnectionStrings[connStringName].ConnectionString) , ASP.NET will automatically decrypt the connection string and return a plain text value. In other words, you don't need to change your code at all after implementing encryption. Pretty cool, right?
In the sample ASP.NET 2.0 website downloaded from this article, you will find a sample page that displays the Web.config file of the site, which has a multi-line TextBox and corresponding Web control buttons for encryption configuration. various parts of the file. This example also uses the ProtectSection() and UnProtectSection() methods discussed above.
6. Use the command line tool aspnet_regiis.exe
You can also use the aspnet_regiis.exe command line tool to encrypt and decrypt the configuration part of the Web.config file. You can find this in the "%WINDOWSDIR%Microsoft.NetFrameworkversion" directory. tool. In order to encrypt a section in the Web.config file, you can use the DPAPI machine key in this command line tool as follows:
A common form of encrypting a Web.config file for a specific website:
aspnet_regiis.exe -pef section physical_directory - prov provider
or:
aspnet_regiis.exe -pe section -app virtual_directory -prov
A specific instance of provider encrypting the Web.config file of a specific website:
aspnet_regiis.exe -pef "connectionStrings" "C:InetpubwwwrootMySite" -prov " DataProtectionConfigurationProvider"
or:
aspnet_regiis.exe -pe "connectionStrings" -app "/MySite" -prov "DataProtectionConfigurationProvider"
A common form of decrypting a specific website's Web.config file:
aspnet_regiis.exe -pdf section physical_directory
or:
aspnet_regiis.exe -pd Section -app virtual_directory
Specific example of decrypting the Web.config file of a specific website:
aspnet_regiis.exe -pdf "connectionStrings" "C:InetpubwwwrootMySite"
or:
You can also specify that aspnet_regiis.exe executes machine.config File encryption/decryption.
[Tip] Encrypting configuration settings in ASP.NET version 1.x.
To protect configuration settings in ASP.NET version 1.x, developers need to encrypt and store sensitive settings in the web server's registry and use a A "strong" key storage method. Rather than storing encrypted content (as in ASP.NET 2.0), the configuration file simply contains a reference to the registry key where the encrypted value is stored. For example:
<identity impersonate="true"
userName="registry:HKLMSOFTWAREMY_SECURE_APPidentityASPNET_SETREG,userName"
password="registry:HKLMSOFTWAREMY_SECURE_APPidentityASPNET_SETREG,password" />
Microsoft provides developers with the aspnet_setreg.exe command line tool to encrypt sensitive configuration information and move it to a "strong" registry entrance. Unfortunately, this tool only works against specific configuration settings; in contrast, ASP.NET 2.0 allows any configuration section to be encrypted.
For more information about using aspnet_setreg.exe in an ASP.NET 1.x application, see KB#32990 on MSDN. Unfortunately, this command-line program can only encrypt predefined sections in configuration settings and does not allow you to encrypt database connection strings and other sensitive information that you add yourself.
7. Conclusion
In this article, we learned how to use the different encryption options provided by ASP.NET 2.0 to protect configuration section information. We also discussed how to use programming techniques and aspnet_regiis.exe to encrypt the configuration section in Web.config respectively. Protecting your sensitive configuration settings helps ensure that your site is more difficult to hack - by making it more difficult to discover sensitive configuration settings. Today, ASP.NET 2.0 already provides relatively easy encryption and decryption technology, and there is no reason for developers not to use this method to protect your sensitive configuration settings.