You should not underestimate the importance of properly configured security settings. Besides exposing your ASP applications to unwanted tampering, poorly configured security settings can also keep intended users from accessing your .asp files.
Your Web server offers you a variety of methods for securing your ASP based applications from unauthorized access and tampering. After you finish reading the security information outlined in this topic, take time to carefully review your Windows NT and Web server security documentation.
You can secure your ASP application files by applying NTFS access permissions to individual files and directories. NTFS permissions, the foundation of your Web server's security system, define the various levels of file and directory access assigned to a user or group of users. When a user with a valid Windows NT account attempts to access a restricted file, your computer checks the file's Access Control List (ACL), which defines the permissions assigned various user accounts and groups. If the user's account has sufficient permissions to open the file, the computer grants access. For example, the owner of a Web application stored on your Web server will require Change permissions to view, alter, and delete the application's .asp files. However, public users accessing the same application, should only be assigned Read permissions, which enable those users to view, not alter, the application's Web pages.
To fully secure an ASP application, be sure to set NTFS file permissions for the appropriate user or group on your application’s Global.asa file. If your Global.asa includes commands that return information to the browser and you do not secure Global.asa, that information will be returned to the browser, even if the application’s other files are secured.
Note Be sure to apply NTFS permissions to an application's files in a consistent way . For example, if you inadvertently apply overly restrictive NTFS permissions to an include file required by your application, users may not be able to view or run the application. To prevent such problems, develop a careful plan for assigning NTFS permissions to your applications.
You can configure your Web server's permissions to restrict how all users view, run, and manipulate your ASP pages. Unlike NTFS permissions, which provide granular control over the way specific users access your application files and directories, Web server permissions apply to all users, and do not discriminate between different types of user accounts.
For users to run your ASP applications, you must use the following rules when setting Web server permissions:
Application script-mapping ensures that your Web server will not accidentally download the source code for an .asp file. For example, even if you set Read permissions for a directory containing a particular .asp file, your Web server will not return that file's code to the user, as long as the .asp file belongs to a script-mapped application.
ASP uses SessionID cookies to track information for specific Web browsers over the course of an application visit, or session. This means that an HTTP request with a matching cookie is assumed to have come from the same Web browser. Your Web server can use SessionID cookies to configure ASP applications with user-specific session information. For example, if your application is an online music store that enables users to select and purchase compact discs, then a SessionID might be used to track each a user's selections as the user wanders throughout the application.
To prevent computer vandals from guessing the SessionID cookie and gaining access to a legitimate user's session variables, your Web server assigns a randomly generated number to each SessionID. Whenever the user's Web browser returns a SessionID cookie, the server extracts the SessionID and the assigned number. The server then checks this number against a generated number, stored exclusively on the server. If the numbers match, the user obtains access to session variables. The effectiveness of this technique lies in the length of the assigned number (64-bits), which makes it highly unlikely that a computer vandal could hijack a user's active session by guessing the SessionID.
A computer vandal, able to intercept a user's sessionID cookie, could use the cookie to impersonate that user. If an ASP application contains private information, a credit card or bank account number, then a vandal with a stolen cookie could start an active session on the application and access this information. You can prevent interception of SessionID cookies by encrypting the communication link between your Web server and the user's browser.
You can require that every user attempting to access your restricted ASP content have a valid Windows NT account user name and password. Each time a user attempts access restricted content, your Web server authenticates, or confirms, the user's identity to ensure that the user has a valid Windows NT account.
Your Web server supports several authentication methods including:
However, your Web server will authenticate users only if you disable anonymous access or when the Windows NT File System permissions restrict anonymous access.
ASP scripts that access the metabase require administrator privileges on the machine on which your Web server is running. When you execute these scripts from a remote machine, you must connect through an authenticated connection, such as a connection using the Windows NT Challenge/Response authentication method. You should create a server or directory for your administrative .asp files and set the directory security authentication method to Windows NT Challenge/Response for the server or directory. Currently, only Microsoft Internet Explorer, version 2.0 or later, supports Windows NT Challenge/Response authentication.
The Secure Sockets Layer (SSL) 3.0 protocol, implemented as a Web server security feature, provides a secure virtually impervious way of establishing an encrypted communication link with users. SSL guarantees the authenticity of Web content and reliably verifies the identity of users accessing restricted Web sites.
With SSL, you can require users attempting to access your ASP application to establish an encrypted communication link with your server; preventing the interception of sensitive information exchanged between the user and the application.
If you include a file that resides in an SSL-enabled directory from an .asp file that resides in an unsecured virtual root, SSL is not applied to the included file. Thus, to ensure that SSL is applied, be sure that both the including and the included files reside in SSL-enabled directories.
A highly secure way regulate access to your ASP applications is to require users to log on with a client certificate. A digital identification containing information about the identity of the user, client certificates perform the same function as conventional forms of identification, such as a passport or driver's license. Users usually obtain client certificates from a trusted, third-party organization that verifies identification information before issuing a certificate. (Typically, these organizations will require a name, address, phone number, and organization name, however, the extent of this information can vary depending the level of identification assurance required from the certificate.)
Whenever a user attempts to log on to an application requiring a certificate, the user's Web browser automatically forwards the certificate to the server. If your Web server's Secure Sockets Layer (SSL) certificate mapping features are properly configured, your server can authenticate the user before permitting access to an ASP application.
As an ASP application developer, you can write scripts to confirm the presence of a certificate and read certificate fields. For example, you can access the user name or company name fields from the certificate. Active Server Pages stores certificate information in the ClientCertificate collection of the Request object.
Before you can process client certificates with ASP, however, your Web server must be configured to either accept or require a client certificate; otherwise the ClientCertificate collection will be empty.