Choose your security level for data access
Remote Data Services (RDS) is a collection of COM objects (DataFactory, DataControl, and DataSpace) that lets you add HTTP capabilities to ADO. With RDS, you access data sources to obtain data and to set data values over HTTP. For example, you can request a recordset from an HTML page or invoke a business object over a particular Web server.
After reading my article "Remote Data Services in Action," April 2000, a few readers contacted me about some RDS security problems. On the readers' machines, even the simplest RDS demo using the standard DataFactory server didn't run; the demo returned the uninformative error code 0x80070005. Curiously, I was unable to reproduce the same error, even when I used the same (presumably wrong) piece of code on two different machines. At that point, I was certain that the problem lay in an obscure area of the system Registry or in some other place where the Windows system stores configuration data.
For a while, I wasn't able to figure out a reasonable explanation for what appeared to be a supernatural software event. (The Registry glitch was only a supposition.) Then, I installed Windows 2000 Professional on a new, freshly formatted machine. When I finished replacing all the necessary applications, I connected to a page of my intranet where I used RDS. To my surprise, I got the long-awaited 0x80070005 error message and, with it, enough information to start investigating.
RDS Security Issues
Let's start at the end of the story. The guilty party is an innocent-looking Registry entry called HandlerRequired, which RDS uses to enable or disable additional security checks. RDS is part of Microsoft Data Access Components (MDAC), which is the official Microsoft data-access tool chest for any software running under the Microsoft .NET architecture umbrella.
Beginning with MDAC 2.0 (Win2K ships with MDAC 2.5), Microsoft improved the RDS security infrastructure, adding new features to prevent intruders from using Microsoft IIS-based servers to execute malicious operations across the Internet. The keys to this security mechanism consist of COM objects that implement a special COM interface called IDataFactoryHandler. Such objects are often called RDS handlers.
The handler's role is simple: to mediate access to data sources, thereby keeping them from being directly exposed to the Internet. You can write your own handler (I give instructions in the sidebar "Writing Custom Handlers," page 50) or rely on the default handler that Microsoft provides. The handler constitutes an additional layer of code that filters and secures data access. You can enable or disable this extra layer on any machine, but this setting is global and applies to all RDS applications connecting to the specified IIS server.
The Registry is where you set your security preferences, whether you want all the RDS calls to pass through a handler or to pass without a strict control down to the specified data sources. Let's look closely at why Microsoft implemented handlers and examine how they work.
Handlers and DataFactory
RDS lets ADO client applications connect to remote OLE DB data sources that run in separate processes on the same machine or on separate machines connected through HTTP, HTTP over Secure Sockets Layer (HTTPS), or Distributed COM (DCOM). Client-side applications talk to a remote COM object whose ultimate goal is accessing data through ADO and OLE DB. Note, however, that although RDS specializes in data retrieval through ADO, nothing prevents you from accessing a COM object that does everything but issue a SQL-based query.
RDS defines a standard component called DataFactory, which acts as a query executor. Through this component, client applications can work directly with an OLE DB provider on the remote process or machine and send and receive ADO recordsets. The body of the DataFactory component contains no special logic to take care of read and write permissions and user privileges—in a word, security. DataFactory is a simple query executor that serves any client that knows the right user ID (UID) and password for a given database. This situation can lead to direct data exposure across the Internet and open a way for potential intruders to intercept the UID and password and steal or alter data.
To work around DataFactory's potential security flaw, Microsoft introduced RDS handlers in MDAC 2.0. Basically, an RDS handler is the component that the RDS DataFactory object invokes to access data. Because you can write and deploy handlers as part of the RDS application, you can control what goes on during the data-retrieval process and can handle any facet of security yourself. Figure 1, page 50, shows the extended RDS architecture, which includes handlers.
You must properly register a handler both as a COM object and as an RDS handler. (I show you how to register a handler later.) Also, the handler must implement the IDataFactoryHandler COM interface to ensure that the handler can interact properly with the DataFactory object. A COM interface is a list of predefined function signatures. When the caller and the callee agree on a given interface, the former can safely call any of those functions, being sure that the latter will provide executable code for them.
By putting an RDS handler between the client-side code and the DataFactory query executor, you can better control the data-retrieval process and reinforce the otherwise limited security of the data. Handlers are relevant to you only if you use the standard DataFactory object to access data. They simply fill the security holes inherent in DataFactory's design and implementation. These holes let you go directly to the data without the mediation of any data-access component. Handlers are an extra layer of code that add custom logic on top of DataFactory's functionality.
Handlers and Custom Components
Using the DataFactory object is only one of your options for accessing data through RDS across the Web. Even with the combined use of DataFactory and handlers, you can't reach the peaks of security, flexibility, and performance that a handcrafted data-access component can offer. Using custom components instead of DataFactory provides three main features that can be advantageous (or not), depending on your needs. With custom data-access components, you can run only hard-coded queries; carefully check privileges, roles, and permissions; and get more speed because you don't pass through an additional COM object—the handler.
Writing a custom data-access component, however, requires more skills than does simply calling an existing and well-documented component such as DataFactory. Still, custom objects are generally preferable because they don't use handlers, they keep your code more compact, they can run faster, and they give you the greatest flexibility and security. To write good business objects, you need relevant COM and COM+ skills as well as familiarity with Visual Basic (VB) or Visual C++ (VC++). Handlers don't affect any custom data-access component you might want to use instead.
Safe and Unsafe Operations
The RDS security problem that my readers and I ran into originated from a feature of the setup program that installs MDAC 2.1 and later. Figure 2 shows the error message we got. Handler support is determined by the value stored in the HandlerRequired subkey under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Data Factory\HandlerInfo Registry subkey. When the HandlerRequired Registry subkey is set to 1, RDS is working in safe mode; DataFactory will access and return data only through a handler. You can specify a custom handler or rely on the default, whose programmatic identifier (ProgID) is MSDFMAP.Handler. The Handler item in the data-source connection string shows the ProgID of the chosen handler. Omit the Handler item information to use the standard handler. When HandlerRequired is set to 0 or is missing, RDS works in unsafe mode—that is, DataFactory doesn't rely on handlers to get or modify data, and the UID and password for a given database are the only requirements to run any query that the UID has permission to run.
By default, MDAC 2.0 installs with HandlerRequired set to 0 (unsafe mode) to keep from breaking existing RDS 1.5-compliant applications. Beginning with MDAC 2.1, however, Microsoft changed the security policy so that RDS works in safe mode with any new installation of MDAC unless you install MDAC 2.1 or later on top of an existing MDAC 2.0 or earlier installation. For example, I upgraded one of my machines from Windows NT to Win2K. The machine was already running MDAC 2.0 in unsafe mode because of the previous RDS 1.5 version. Usually, installing Win2K on a freshly formatted machine gives you MDAC 2.5 with handlers enabled on all of its standard settings to reinforce security. But because upgrading MDAC doesn't change the Registry settings for security, my RDS applications stopped working properly when I restored them.
You can solve this problem in two ways. The first option is to disable the handler-based security mechanism. Alternatively, you can modify all your RDS client code in all your RDS-based applications to make the code support handlers. If you decide to solve the problem by disabling handlers, you don't need to edit a single line of your client code, but you risk undesired exposure to intruders. Disabling handlers is as easy as running the script in Listing 1. Note that you need to enter these changes on the server machine only. For the change to take effect, you need to reboot the machine.
The Default Handler
To support RDS handlers in your code, first decide which handler you want to drive your data access. As I stated earlier, an RDS handler is a COM object whose only requirement is that you implement the IDataFactoryHandler interface. You decide what logic to use to ensure safe and controlled access. DataFactory calls the interface's two methods to read and write records. Table 1 describes the two methods and shows how to call them.
Prev. page
[1]
2
3
next page 
