ADO 2.8 Security Design Issues and Changes

The following sections cover changes made to ActiveX Data Objects (ADO) design for MDAC 2.8, as well as ADO implementation details that might help you to understand the reason for the changes. You are also given steps to further improve security by using MDAC 2.8 as part of your application deployment plans.

For the MDAC 2.8 release, the MDAC team conducted a full security review of the MDAC 2.7 code base. In doing so, there have been some necessary changes to ADO, which depart from previously implemented design behavior. In all cases, the risk of breaking some backwards compatibility was weighed carefully against improving and securing how ADO works and performs in all known scenarios.

Important   While it is quite likely that MDAC 2.8 will be able to globally replace MDAC 2.7 without incident for many customers, it is recommended that you test your application with MDAC 2.8, in a non-production machine, to ensure you are aware of any compatibility issues before you decide whether to have MDAC 2.8 deployed or updated to customers who use your application.

This information is designed to make you aware of the issues and changes that you need in order to best secure your applications, and how it is possible to use MDAC 2.8 to best assist you in doing so.

Changes for Internet Explorer file access scenarios

The following changes effect how MDAC 2.8 works when used in scripted Web pages in Internet Explorer.

Revised and improved security warning message box now used to alert users

For MDAC 2.7 and earlier, the following warning message appear when a scripted Web page attempted to run ADO code from an untrusted provider:

This page accesses data on another domain. Do you want to allow this? To 
avoid this message in Internet Explorer, you can add a secure Web site to 
your Trusted Sites zone on the Security tab of the Internet Options dialog 
box.

For MDAC 2.8, the preceding message no longer appears. Instead, the following message appears in this context:

This Website uses a data provider that may be unsafe. If you trust the 
Website, click OK, otherwise click Cancel.

The preceding message allows the user to make informed decision, while knowing the consequences for either choice:

  • If user trusts the site, clicking OK will allow all disk-safe code (all ADO methods and properties with the exceptions of the disk-accessible APIs described below) to run and execute in the browser window.
  • If user does not trust the site, clicking Cancel blocks the ADO code for data access from running and executing in its entirety.

Disk-accessible code limited now to trusted sites

Additional design changes were made in MDAC 2.8 that specifically restrict the ability of a limited set of APIs, which might expose the potential to read from or write to files on the local computer. Here are the API methods that have been further restricted for safety when running Internet Explorer:

For these limited sets of potentially disk-accessible functions, the following behavior now occurs for MDAC 2.8, if any code that uses these methods is run in Internet Explorer:

  • If the site that provided the code was added previously to the Trusted Sites zone list, the code executes in the browser and access is granted to local files.

  • If the site does not appear in the Trusted Sites zone list, the code is blocked and access to local files is denied.

    Note   The user is no longer alerted or advised to add sites to the Trusted Sites zone list. Therefore the management of the Trusted Sites list is in the hands of those who are deploying or supporting Web site–based applications that require access to the local file system.

Access blocked to the ActiveCommand property on Recordset objects

When running in Internet Explorer, MDAC 2.8 now blocks access to the ActiveCommand property for an active Recordset object and returns an error. The error occurs regardless of whether or not the page comes from a Web site registered in the Trusted Sites list.

Changes in handling for OLE DB providers and integrated security

While reviewing MDAC 2.7 and earlier versions for potential security issues and concerns, the following scenario was discovered:

In some instances, OLE DB providers who support the "Integrated Security" DBPROP_AUTH_INTEGRATED property could potentially permit scripted Web pages to reuse the ADO Connection object to connect unintentionally to other servers using the current login credentials of the users. To prevent this from occurring, MDAC 2.8 and later now changes design of ADO to more appropriately handle OLE DB providers depending on how they have chosen to provide, or not provide, for integrated security.

For Web pages that are loaded from sites listed in the Trusted Sites zone list, the following table provides a breakdown of how MDAC 2.8 manages ADO connections in each case.

IE settings for user authentication, logon Provider supports "Integrated Security" and UID and PWD are specified (SQLOLEDB) Provider does not support "Integrated Security" (JOLT, MSDASQL, MSPersist) Provider supports "Integrated Security" and it is set to SSPI (no UID/PWD are specified)
Automatic logon with current username and password Allow connection Allow connection Allow connection
Prompt for user name and password Allow connection Fail connection Fail connection
Automatic logon only in Intranet zone Allow connection Prompt user with security warning Prompt user with security warning
Anonymous logon Allow connection Fail connection Fail connection

In the case where a security warning now appears, the message box informs users:

This Website is using your identity to access a data source. If you trust this Website, click OK, otherwise click Cancel.

The preceding message allows the user to make a more informed decision and proceed accordingly.

Note   For untrusted sites (that is, sites not listed in the Trusted Sites zone list), if the provider is also untrusted (as discussed earlier in this section), the user might see two security warnings in a row, a warning about the unsafe provider and a second warning about the attempt to use their identity. If the user clicks OK to the first warning, then Internet Explorer settings and response behavior code described in the preceding table are executed.

Controlling whether password text is returned in ADO connection strings

When you attempt get the value of the ConnectionString property on an ADO Connection object, the following occurs:

  1. If the connection is open, an initialization call is then made to the underlying OLE DB provider to get the connection string.
  2. Depending on the setting in the OLE DB provider of the DBPROP_AUTH_PERSIST_SENSITIVE_AUTHINFO property, passwords are included along with other connection string information that is returned.

For example, if the ADO Connection dynamic property "Persist Security Info" is set to true, password information is included in the connection string returned. Otherwise, if the underlying provider has set the property to false (for example with the SQLOLEDB provider), password information is omitted in the returned connection string.

If you are using third-party (that is, non-Microsoft) OLE DB providers with your ADO application code, you might check how DBPROP_AUTH_PERSIST_SENSITIVE_AUTHINFO property is implemented to determine whether inclusion of password information with ADO connection strings are permitted.

Checking for non-file devices when loading and saving recordsets or streams

For MDAC 2.7 and earlier, file input/output operations such as Open and Save that were used to read and write file-based data could in some cases allow a URL or file name to be used that specified a non-disk based file type. For example, LPT1, COM2, PRN.TXT, AUX could be used as an alias for input/output between printers and auxiliary devices on the system using certain

For MDAC 2.8, this functionality has been updated. For opening and saving Recordset and Stream objects, ADO now performs a file type check to ensure that the input or output device specified in a URL or file name is an actual file.

Note   File type checking as described in this section only applies for current Microsoft® Windows® releases such as Windows 2000 or Windows XP. It does not apply to situations where MDAC 2.8 is running under earlier Windows releases, such as Windows 95 or Windows 98.