INFO: Security Issues with Objects in ASP and ISAPI Extensions

• Microsoft Internet Information Server versions 2.0, 3.0

SUMMARY

This article covers the security issues you need to be aware of when creating or launching ActiveX objects from either an ISAPI extension or an Active Server Pages (ASP) page.

MORE INFORMATION

Whenever an object is created in the context of Internet Information Server (IIS), the security context it will have depends on the object's threading model. The security context given to the object will then affect all actions performed by that object, including such things as accessing files, accessing databases and creating other objects.

IIS passes on security contexts depending on the authentication scheme that you are using in IIS. For example, if you are using Anonymous authentication, the object runs in the security context of a user account called IUSR_<machinename>, where <machinename> is the name of the machine on which IIS is running. For additional information on authentication schemes and security from IIS, see the following article in the Microsoft Knowledge Base:

   ARTICLE-ID: Q158229
   TITLE     : Security Ramifications for IIS Applications

   ARTICLE-ID: Q150777
   TITLE     : Descriptions and Workings of OLE Threading Models

By default ASP creates single-threaded apartment clients, which means that only single-threaded apartment inproc servers are given the desired security context passed on by IIS. In ASP it is a good idea to create single-threaded apartment objects since they will run faster than free- threaded objects or unmarked objects because they don't go through a proxy to make the calls. Thus for performance and security reasons, ASP components should have their Threading Model registry value set to either "Apartment" or "Both" in the registry.

If you are instead creating your own ISAPI DLL that will be instantiating objects and you want to get the security context passed by IIS, you will need to make sure that you call CoInitializeEx(NULL, COINIT_MULTITHREADED) for free-threaded apartment servers and CoInitializeEx(NULL, APARTMENTTHREADED) for single-threaded apartment servers.

Objects marked as "Both" will get the right security context when instantiated in either single-thread apartments or free-thread apartments. However, these objects must be created with the synchronization considerations of any free-threaded object, which can be considerably more difficult to program and test.

DCOM

Beginning with NT 4.0, the launching and accessing of objects is done through Distributed COM (DCOM). DCOM allows you to configure the ability of a client application to launch and access objects on remote machines and the local machine. This configuration is done through a utility provided with NT called "DCOMCNFG." You will need to make sure that when a client application running under a certain account wants to launch or access an object, it has the proper permissions in DCOM. By default, you will see in DCOMCNFG that certain accounts already have permission to launch and access objects, such as the INTERACTIVE account, so that client applications running as the interactive user can use objects; the SYSTEM account, so the system can use objects; and the IUSR_<servername> account, passed by IIS. If you are using some authentication scheme other than anonymous, you need to make sure that the account that the client is using is listed as having launch and access permissions.

Recommendations

Because of the way IIS assigns and reuses threads, you would typically not get much benefit from creating a free-threaded apartment object as opposed to a single-threaded apartment object. Although free-threaded objects do not need to have their interfaces marshalled between threads of a free- threaded client apartment, this usually means very little under the context of IIS because in most cases the only interface of interest is IDispatch, and the system has a built-in marshaller for this interface. Unless you plan on using your own ISAPI DLL instead of ASP and are creating an object that takes a long time to initialize, or you want to pass data between instances of the objects, you should create single-threaded apartment objects.

It is important to note that Visual Basic 4.0 does not create "Apartment" model objects, but Visual Basic 5.0 does.

Local Servers

When a local server object (an .exe file) is instantiated, by default it is given the SYSTEM security context. However, this can be changed with the DCOMCNFG utility. For additional information on launching OLE local servers from IIS, see the following article on the Microsoft Knowledge Base:

   ARTICLE-ID: Q156223
   TITLE     : How To Launch OLE Servers from ISAPI Extensions

Determining Your Current Security Context

If you are having problems accessing other files, databases, or objects from within your object, you can always check your security context programmatically by adding a call to the Win32 API function: GetUserName(). Or to get the full Domain/UserName call OpenProcessToken()/GetTokenInformation()/LookupAccoundSID().

Another way to debug security context problems is to turn on auditing with the NT User Manager. This will allow you to log selected activities in the event viewer and is an easy way to determine which account tried to access a given file or resource.

Changing Your Security Context

If for some reason you cannot get the security context that you need, you can impersonate the desired security context by creating a method in your automation server that takes as parameters the user name and password of the security account that you need. Once you have the user name and password you can change the current security context with the Win32 API functions: LogonUser() and ImpersonateLoggedOnUser().

Keywords          : iisapi
Version           : WINDOWS NT:2.0,3.0
Platform          : NT WINDOWS