Maintaining the security of ASP applications

Security | procedures

Never underestimate the importance of properly configuring security settings. If you do not configure your security settings correctly, you will not only cause your ASP application to be unnecessarily tampered with, but will also prevent legitimate users from accessing your. asp files.

WEB servers provide a variety of ways to protect your ASP applications from unauthorized access and tampering. After you have read the security information in this topic, please take a moment to double-check your Windows NT and WEB Server security documentation.

NTFS Permissions
You can protect ASP application files by applying NTFS access permissions for separate files and directories. NTFS permissions are the basis for Web server security, which defines the different levels of access to files and directories by one or a group of users. When a user with a Windows NT active account attempts to access a file with permission restrictions, the computer checks the Access Control table (ACL) for the file. This table defines the permissions that are given to different users and groups of users. If the user's account has permission to open the file, the computer allows the user to access the file. For example, the owner of a Web application on a Web server needs to have "change" permission to view, change, and delete an application's. asp file. However, public users who access the application should be granted only read-only permission to restrict it to a Web page that can only be viewed and cannot change the application.

Maintain the safety of global.asa
To fully protect your ASP application, be sure to set NTFS file permissions on the application's Global.asa file for the appropriate users or groups of users. If Global.asa contains a command to return information to the browser and you do not protect the Global.asa file, the information is returned to the browser, even if other files of the application are protected.

Note Be sure to apply uniform NTFS permissions to your application's files. For example, a user might not be able to view or run the application if you inadvertently unduly limit the NTFS permissions of the file that an application needs to contain. To prevent this type of problem, you should plan carefully before assigning NTFS permissions to your application.

Web Server Permissions
You can restrict how your ASP pages are viewed, run, and manipulated by all users by configuring the permissions of your WEB server. Unlike NTFS permissions, which control the way a particular user accesses application files and directories, Web server permissions apply to all users and do not differentiate between types of user accounts.

For users who want to run your ASP application, the following guidelines must be followed when setting Web server permissions:



Allow read or script permissions for virtual directories that contain. asp files.

Allow read and script permissions on the virtual directory of the. asp files and other files containing scripts, such as. htm files.

Allow read and Execute permissions on virtual directories that contain. asp files and other files that require execute permission to run (such as. exe and. dll files, and so on).


Script Mapping File
The application's script mapping ensures that the WEB server does not accidentally download the source code for the. asp file. For example, even if you set the Read permission for a directory that contains an. asp file, your WEB server will not return the source code for that file to the user, provided that the. asp file is part of a script-mapped application.

Cookie Security
ASP uses the SessionID cookie to track information for specific WEB browsers during an application visit or session. This means that an HTTP request with a corresponding cookie is considered to be from the same Web browser. WEB servers can use SessionID cookies to configure ASP applications with user-specific session information. For example, if your application is an online music store that allows users to select and purchase CDs, you can use SessionID to track users ' choices when roaming the entire application.

Can SessionID be guessed by hackers?
To prevent computer hackers from guessing SessionID cookies and gaining access to session variables for legitimate users, the WEB server assigns a randomly generated number to each SessionID. Whenever a user's Web browser returns a SessionID cookie, the server takes out the SessionID and the assigned number, and then checks to see if it is consistent with the build number stored on the server. If two numbers are consistent, the user is allowed access to session variables. The effectiveness of this technique lies in the length of the assigned number (64 bits), which makes it possible for a computer hacker to guess SessionID to steal a user's active session by almost 0.

Encrypt important SessionID Cookies
A computer hacker who intercepts a user's SessionID cookie can use this cookie to impersonate the user. If an ASP application contains private information, a credit card or bank account number, a computer hacker with a stolen cookie can start an active session in the application and get the information. You can prevent SessionID cookies from being intercepted by encrypting the communication link between your WEB server and the user's browser.

Using authentication mechanisms to protect restricted ASP content
You can require that each user attempting to access a restricted ASP content must have a valid user name and password for a Windows NT account. Whenever a user attempts to access a restricted content, the WEB server authenticates, confirming the user's identity to check whether the user has a valid Windows NT account.

The WEB server supports the following authentication methods:


Basic authentication prompts the user for a user name and password.

Windows NT Request/Response authentication obtains user identity information from the user's Web browser in encrypted form.

However, the WEB server authenticates the user only when it prohibits anonymous access or the permissions of the Windows NT file system to restrict anonymity.

Securing meta-databases
ASP scripts that access the metabase require administrator privileges on the computer on which the WEB server is running. When you run these scripts from a remote computer, you must have an authenticated connection, such as using Windows NT request/Response authentication. You should create a server or directory for the administrative level. asp file and set its directory security authentication mode to Windows NT request/Response authentication. Currently, Windows NT request/Response authentication is supported only by Microsoft Internet Explorer version 2.0 or later.

Using SSL to maintain application security
The Secure Sockets Layer (SSL) 3.0 protocol, as a WEB server security feature, provides a secure, virtual, transparent way to establish an encrypted communication connection with the user. SSL guarantees the authentication of Web content and reliably confirms the identity of the user who accesses the restricted Web site.

With SSL, you can require a user attempting to access a restricted ASP application to establish an encrypted connection with your server, in case the important information exchanged between the user and the application is intercepted.

Maintaining security for Include files
If you include a file in an SSL-enabled directory from an. asp file that is located in a virtual root that is not protected, SSL will not be applied to the included file. Therefore, to ensure that SSL is applied, ensure that the included and included files are in the SSL-enabled directory.

Customer Qualification Certification
A very secure way to control access to your ASP application is to require the user to log on using the customer qualification. Customer eligibility is a digital ID that contains the identity information of a user, and its role is the same as a traditional identity certificate such as a passport or driving licence. The user usually obtains the customer qualification from the entrusted third party organization, the third party organization confirms the user's identity information before issuing the qualification certificate. (Typically, such organizations require names, addresses, telephone numbers, and the names of their organizations; the level of detail of such information varies depending on the level of identity given.) ）

Whenever a user attempts to log on to an application that requires authentication, the user's Web browser automatically sends the user credentials to the server. If the Secure Sockets Layer (SSL) Eligibility mapping feature of the WEB server is configured correctly, the server can confirm its identity before a licensed user accesses an ASP application.

ASP scripts for processing qualification certificates
As an ASP application developer, you can write a script to check for eligibility and read eligibility fields. For example, you can access the User name field and the company Name section from the qualification certificate. Active Server Pages holds eligibility information in the ClientCertificate collection of the Request object.

You must configure your WEB server to accept or require a customer qualification before you can process customer eligibility through ASP; otherwise, the ClientCertificate collection will be empty.