Maintaining the security of ASP applications

Security | Procedures do not despise 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. For more information, see Security.

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.

For more information about configuring NTFS permissions, see Access control.

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).

For more information about configuring WEB server permissions, see Access control.

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. For more information about encryption, see security.

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. For more information, see About authentication.

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. For more information, see encryption.

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. For more information, see ASP built-in objects.

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.

Create a transactional script

Commercial applications often need to have the ability to run scripts and components within a transaction. A transaction is a server operation that, even if it involves many steps (for example, ordering, viewing inventory, paying bills, and so on), can only return the success or failure of the operation as a whole. A user can create an ASP script that runs inside a transaction, and the entire transaction terminates if any part of the script fails.

is the ASP transaction handled in Microsoft? Transaction Server (MTS) based. Microsoft? Transaction Server (MTS) is a transaction processing system for developing, configuring, and managing High-performance, scalable, and robust enterprise Internet and Intranet server applications. Transaction Server provides an application design model for developing distributed, component-based applications. It also provides a running environment for configuring and managing these applications.

The ability to create transactional scripts is built into the Internet Information Server and Personal Web server. If you have installed Microsoft Transaction Server, you can package the components so that the components run within the transaction. For more information about component packaging, see Creating an MTS package.

About transactions

A transaction is an overall success or failure operation. Transaction processing is used to reliably update the database. Make sure that all changes are performed correctly when you make many related changes to the database or when you update multiple databases simultaneously. If any of these changes fail, you need to restore the original state of the database table.

Without MTS, you would need to write scripts and components to manually track changes to the request to recover the data if some of the changes fail. With MTS, you simply declare your scripts and components as "need transactions" and let MTS process the consistency of transactions. Transactions apply only to database access, and MTS cannot recover from changes to file systems or other non-transactional resources. The database accessed by the application must be supported by MTS. Currently, MTS supports SQL Server and any servers that support the XA protocol (developed by the X/open Association). MTS will continue to expand its support for other databases.

Transactions cannot span multiple ASP pages. If a transaction requires objects from more than one component, you must combine the operations that use these objects into an ASP page. For example, suppose a component is used to update payroll databases, and a component is used to update employee records in the human resources database. To record the new payroll information for an employee, you need to write a script that calls both components in a transactional environment, one for updating payroll databases,