ASP Lecture Series (Twenty) Maintaining the Security of ASP Applications
Author：Eve Cole
Update Time：2009-05-30 19:58:35
Never underestimate the importance of properly configuring security settings. Improperly configuring security settings not only exposes your ASP applications to unnecessary tampering, but also prevents legitimate users from accessing your .asp files.
Web servers provide various methods 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 carefully review your Windows NT and Web server security documentation.
NTFS Permissions You can protect ASP application files by applying NTFS access permissions to individual files and directories. NTFS permissions are the foundation of Web server security, defining different levels of access to files and directories for a user or a group of users. When a user with a valid Windows NT account attempts to access a file with restricted permissions, the computer checks the file's access control list (ACL). This table defines the permissions granted to different users and user groups. 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 Change permissions to view, change, and delete the application's .asp files. However, public users accessing the application should be granted only Read-Only permissions, limiting them to viewing but not changing the application's Web pages.
Maintaining Global.asa Security To fully protect your ASP application, be sure to set NTFS file permissions on the application's Global.asa file for the appropriate user or group. If Global.asa contains commands that return information to the browser and you do not protect the Global.asa file, the information will be returned to the browser even if other files in the application are protected.
NOTE Be sure to apply uniform NTFS permissions to the application's files. For example, if you accidentally over-restrict NTFS permissions for a file that an application needs to contain, users may not be able to view or run the application. To prevent such problems, plan carefully before assigning NTFS permissions to your applications.
Web Server Permissions You can restrict how all users can view, run, and manipulate your ASP pages by configuring permissions on your Web server. Unlike NTFS permissions, which provide a way to control specific users' access to application files and directories, Web server permissions apply to all users and do not differentiate between user account types.
For the users who will run your ASP applications, you must follow these guidelines when setting Web server permissions:
Allow Read or Script permissions on the virtual directory containing the .asp file.
Allow "read" and "script" permissions on the virtual directories where .asp files and other files containing scripts (such as .htm files, etc.) are located.
Allow Read and Execute permissions on virtual directories that contain .asp files and other files that require Execute permissions to run (such as .exe and .dll files, etc.).
Script Mapping Files The application's script mapping ensures that the Web server does not accidentally download the source code of the .asp file. For example, even if you set Read permissions for the directory that contains an .asp file, your Web server will not return the source code for the file as long as the .asp file belongs to a script mapping application. to users.
Cookie security
ASP uses the SessionID cookie to track specific Web browser information during an application visit or session. This means that HTTP requests with corresponding cookies are considered to come 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 the user's selections as they roam throughout the application.
Can SessionID be guessed by hackers?
To prevent computer hackers from guessing the SessionID cookie and gaining access to a legitimate user's session variables, the Web server assigns a randomly generated number to each SessionID. Whenever the user's Web browser returns a SessionID cookie, the server retrieves the SessionID and the assigned number, and then checks to see if it matches the generated number stored on the server. If the two numbers match, the user will be allowed to access the session variable. The effectiveness of this technique lies in the length of the number assigned (64 bits), which makes the possibility of a computer hacker guessing the SessionID and stealing the user's active session almost zero.
Encrypt important SessionID Cookie
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, credit card or bank account numbers, a computer hacker with a stolen cookie can start an active session in the application and obtain this information. You can prevent the SessionID cookie from being intercepted by encrypting the communication link between your Web server and the user's browser.
Protecting Restricted ASP Content Using Authentication Mechanisms You can require that each user who attempts to access restricted ASP content must have a valid Windows NT account user name and password. Whenever a user attempts to access restricted content, the Web server performs authentication, or verification of 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 username and password.
Windows NT request/response authentication encryptedly obtains user identity information from the user's Web browser.
However, the Web server only authenticates the user if anonymous access is prohibited or restricted by Windows NT file system permissions.
Securing the Metabase ASP scripts that access the metabase require administrator rights on the computer where the Web server is running. When running these scripts from a remote computer, you must connect through an authenticated connection, such as using Windows NT request/response authentication. You should create a server or directory for the administrative .asp file and set its directory security authentication method to Windows NT request/response authentication. Currently, Windows NT request/response authentication is only supported by Microsoft Internet Explorer version 2.0 or later.
Maintain application security using SSL
As a Web server security feature, the Secure Sockets Layer (SSL) 3.0 protocol provides a secure virtual and transparent way to establish encrypted communication connections with users. SSL ensures the authentication of Web content and can reliably confirm the identity of users accessing restricted Web sites.
With SSL, you can require users trying to access restricted ASP applications to establish an encrypted connection with your server; this prevents important information exchanged between users and applications from being intercepted.
Maintaining Security for Included Files If you include files located in an SSL-enabled directory from an .asp file located in an unprotected virtual root directory, SSL will not be applied to the included files. Therefore, to ensure that SSL is applied, make sure that both the including and included files are in an SSL-enabled directory.
Client Authentication A very secure way to control access to your ASP application is to require users to log in with client authentication. A customer credential is a digital ID card that contains the user’s identity information and functions in the same way as a traditional form of identification such as a passport or driver’s license. Users usually obtain customer qualifications from an entrusted third-party organization, which confirms the user's identity information before issuing qualification certificates. (Typically, such organizations ask for a name, address, phone number, and organization name; the level of detail in this information varies depending on the level of status given.)
Whenever a user attempts to log in to an application that requires eligibility verification, the user's Web browser automatically sends the user's credentials to the server. If the Web server's Secure Sockets Layer (SSL) qualification mapping feature is configured correctly, the server can verify a user's identity before granting access to an ASP application.
ASP scripts for handling qualification certification As an ASP application developer, you can write scripts to check whether a qualification exists and read the qualification fields. For example, you can access the username field and company name field from the qualification. Active Server Pages stores qualification information in the ClientCertificate collection of the Request object.
The Web server must be configured to accept or require client qualifications before it can be processed through ASP; otherwise, the ClientCertificate collection will be empty.
