This section focuses on the security issues that surround the usage of IIS and the implementation of ISAPI based extensions, of both filters and applications types. The rules are the same whether the extensions are part of the system (i.e. Active Server Pages, the Internet Data Connector) or ones that you and I write (i.e. our samples in the Server Extensions chapter).
IIS is a process running on the Windows NT operating system, and we learnt earlier that every process has a Security Access Token containing the security context under which the threads in the process would run by default. For the IIS, this is a very powerful system user. This particular user has access to almost everything on the local system, but no access whatsoever to networked resources.
Due to the tremendous power that the system user has, we couldn't possibly expect the IIS to use the system user's context when serving web pages or running ISAPI extensions. And, of course, it doesn't. Instead, when servicing a user request to access web pages and other server resources, the working thread(s) are operating under impersonation (via a change of the Security Access Token) in the security context of a local user account. This account could be a 'default' one that can be set during IIS setup, or a user account specified by the requesting browser when submitting the request.
All the security problems that arise during access through IIS revolve around the proper matching of the access rights of the requesting user, the user account under which IIS executes the request, and the rights associated with the resources that are accessed during the processing of the request.
The exact security context that will be used depends on the HTTP requests that the IIS receives and the setting of the Authentication Options in the Internet Service Manager configuration. The WWW service of IIS can be set to one or more of the following authentication options:
Let's look at each of these options.