How to configure a secure ASP application

Security | procedures

Security for ASP applications

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

---the use of 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.

[1] [2] [3] [4] Next page