Bagikan melalui

Controlling the Identity of ISAPI Extensions

  • Artikel

ISAPI extensions and filters contain code that is going to be exposed directly to the Internet. Do not assume that any information received from the client is correctly formatted, validated or trusted. ISAPI DLLs should include validation functions to guard against both naive and hostile clients. Naive clients might do something unexpected such as try to run an ISAPI DLL as a script. Hostile clients actively try to break applications or spoof their identity by taking a 302 response from one server and making a new request to another server using the header data from the first server. Validate ISAPI responses as strictly as client requests.

Authentication

Before IIS processes a request, authentication of the client is performed in order to set the security context (or identity) of the process that executes the request.

Complex extensions rely on worker threads to accomplish their processing. By default, worker threads have the same security identity as the process in which they are running unless the Win32 RevertToSelf function is called.

Process and thread identities of ISAPI applications are described in the table in IIS Application Identities. One detail omitted from the table is that the ISAPI extension GetExtensionVersion function is called under the Local System security context while other ISAPI functions are called using the security token associated with the request.

If an ISAPI extension accesses secured resources such as the IIS metabase, it needs to pass the security context of the logged-on user to a thread by obtaining an impersonation token from the process.

To obtain an impersonation token in an ISAPI extension

  1. Call the ServerSupportFunction function and specify HSE_REQ_GET_IMPERSONATION_TOKEN as the value for the dwHSERequest parameter. This function returns a handle to the impersonation token that is valid for the lifetime of the EXTENSION_CONTROL_BLOCK structure. The the process of obtaining a security token for these functions is slightly different for asynchronous and synchronous extensions.

    If the call to the ServerSupportFunction is for a synchronous operation, then the EXTENSION_CONTROL_BLOCK is valid until the HttpExtensionProc function completes.

    If the call to the ServerSupportFunction is for an asynchronous operation, then the EXTENSION_CONTROL_BLOCK is valid until your extension calls ServerSupportFunction and specifies a value of HSE_REQ_DONE_WITH_SESSION for the dwHSERequest parameter.

  2. Call the ImpersonateLoggedOnUser function on the current I/O thread or call the SetThreadToken function for a specific thread so that the thread runs as the authenticated user. Both functions require the handle to the impersonation token obtained from the call to the ServerSupportFunction function in step 1.

  3. To return the thread to the security context of the process in which it is running, call the Win32 API RevertToSelf function after the thread has finished using the current security context.

For more information about asynchronous processing, see Asynchronous I/O Processing.

Authorization

Security for ISAPI extensions is derived from the Microsoft Windows security model. Before successfully serving any request, IIS verifies the impersonation token of the authenticated user against the ACL of the resource being requested. Additionally, if the request is for an ISAPI extension such as ASP, the worker process applies the authenticated user's token as an impersonation token to the thread that calls into the ISAPI extension. When the ISAPI extension begins processing the request, the impersonation token (instead of the process identity) is applied to the actions it takes.

When selecting application isolation (or in the case of IIS 6.0 in worker process isolation mode, when selecting application pool identity), choose one with the lowest set of privileges that are required by your application. If the identity of a process has high privileges like LocalSystem does, the application is given permissions beyond the scope of the authenticated user, and that is a security risk.