Editor web.config to ensure ASP.net security

asp.net|web| Security

All. NET applications keep their information in an xml-based configuration file. Generally, this. config profile is located in the directory of the application executable file. However, the Web application uses the Web.config file located in the root directory of the application. The web.config contained in the ASP.net application is related to most of its applications. Now let's dissect a Web.config sample file and see what security-related settings you'll find in it.

　　configuration file Settings and extents

First, let's look at the overall structure of the configuration file in listing a. This file must have a root element as an XML document to include all the other elements. It's strange that the root element here is . Under the root element are and sectors. This section identifies the information it includes for the default Web server, including security information. This section places all the global data for your application. As I've said, database connection strings can be well preserved. In my case, I saved the Web site's DSN-free ODBC connection string there.

　　Custom error page

　　 The first is that it allows you to specify some pages to guide your users to these pages when they encounter various errors. In my case, if a 404 error occurs, the user will be directed to the/errorpages/filenotfound.html page. When encountering any other error, the user will be directed to the/errorpages/generalerror.html page.

　　Verify

　　 This section defines the details of the process by which the server authenticates the user. The three different modes supported are Windows, forms, and passport. Now let's take a closer look at each of the patterns:

Windows verifies that users are authenticated through Windows ' system accounts, such as Active Directory. Windows authentication is the safest form of authentication, and for programmers this pattern is simple because the entire process is handled by the operating system. However, each user of the site needs a system account, so this pattern is limited to an intranet application.

Passport verification uses passports to authenticate users, which is the second security authentication method. The best thing to do is to have large, active Internet e-commerce applications that validate user fees for service usage. This pattern is. NET, the authentication method selected by the

Forms validation is the least secure authentication method, because your application must handle the validation process yourself. However, this is the most likely mode to use on your Internet application because it requires minimal management and maintenance.

Check out listing a you can see this site uses forms validation. You can specify a domain name that you want. Here, I'm using the. Aspxauth, its function and name is actually not a real name. I just put this element in to remind me that it does have a name.

You will also see that I have specified the relevant url:/loginform.aspx for the login page. When a user attempts to access a secure page, the user who cannot authenticate is directed to the URL. Anonymous users, if you allow them to access your authorized area, will not be automatically sent to this page.

　　 This section contains settings that explicitly allow ( ) or disallow ( ) access to a user, a group of users, or a class of users. The values that these settings can accept are the question mark (?) for anonymous users, an asterisk (*) for all users, or a list of specific user names separated by commas.

You can specify that the security of your site is defined by one or both of them. In listing A, I indicated that all but anonymous users and four troublemakers were allowed access, and that four people had caused enough trouble to be banned: hackers (Hacker), hackers (cracker), Fasherman and Hillgirl. If I swap the tags for these user attributes , then only anonymous users and these four categories of users have access. Anyone else who doesn't have a legitimate trust book will be shut out.

Although you can maintain your user account by keeping the username in the element, I do not recommend it. If you actually keep the user information in the Web.config file, user authentication will only be done on that particular Web server. In the case of a large Web server farm or load-balanced Web server, validation that occurs on one machine also occurs on all other servers in the same Web server farm.

The only way to prevent users from having to log on to each page is to keep the data in a general-purpose data warehouse, such as a database. Another reason not to keep the user's trust book in the Web.config file is that the server must reboot to reload the new trust book. This problem should be fixed in a future operating system, but this is a problem already with the Windows 2000 Server version running IIS5.

　　Many advantages

You've now seen how to use the elements in an XML file that IIS needs to manage the elements of the ASP.net Web application. This configuration model has many advantages that you have already realized. Because IIS makes changes by monitoring the Web.config file, any changes to the configuration file are immediately reflected: this does not require a server reboot.