Protected Mode Broker Functions
Windows Internet Explorer 8 in Windows Vista provides broker functions that allow access between applications, processes, and resources secured to other integrity levels.
This topic contains the following sections.
- Understanding the Need for Broker Functions
- Available Broker Functions
- Effectively Using Broker Functions
- Related topics
Internet Explorer 8 in Windows Vista provides broker functions that allow access between applications, processes, and resources secured to other integrity levels. For example, medium integrity applications can access Protected Mode cookies. In addition, Protected Mode Windows Internet Explorer processes, including browser extensions and Browser Helper Objects (BHOs), have limited access to Registry keys and low integrity file locations.
This article explains the need for broker functions, introduces the available broker functions, and provides guidance for using broker functions effectively and securely.
Understanding the Need for Broker Functions
The User Account Control (UAC) feature of Windows Vista assigns integrity levels to securable resources, such as Registry entries, files, and applications. When running in Protected Mode, Internet Explorer opens Web pages at a low integrity level and allows them to access resources secured to the same integrity level. This helps prevent malicious Web sites from accessing resources secured to higher integrity levels, such as protected operating system files and critical Registry settings. When running in Protected Mode, Internet Explorer saves cookies to a low integrity location.
Windows Internet Explorer 7 provides two solutions for this problem. You can create a BHO that writes cookie values to medium integrity locations; however, this increases the possibility for security flaws and can degrade Internet Explorer performance. As an alternative solution, you can add the domain serving the cookies to the Trusted Sites list. While this avoids the problem by opening the site outside of Protected Mode, it also exposes users to the possibilities of malicious attacks staged through the site.
Similar concerns affect browser extensions and BHOs. When run from a Protected Mode Internet Explorer process, browser extensions and BHOs are restricted to low integrity resources. For extensions that interact with other applications, this creates a problem because the other applications typically run at medium integrity. As a result, extension developers typically create custom DLLs that communicate with their applications. As in the previous example, this increases the potential for malicious attacks staged through the DLL and can degrade the overall performance of Internet Explorer 7.
Internet Explorer 8 addresses these risks by providing broker functions that allow limited access to resources secured to other integrity levels.
Available Broker Functions
Internet Explorer 8 allows access between integrity levels using the following methods.
Extension developers can use functions like IERegisterWritableRegistryKey and IERegisterWritableRegistryValue to register keys, values, and data that can be accessed by medium and low integrity applications. The IEUnregisterWritableRegistry function unregisters and deletes previously registered items.
Several functions all developers to manage files in low integrity file locations, including IECreateFile, IEDeleteFile, and IEMoveFileEx. Additional functions include IECreateDirectory, IERemoveDirectory, IEFindFirstFile, and IEGetFileAttributesEx.
In general, Protected Mode broker functions are similar to related functions in the Windows API. The differences between the broker functions and their Windows API counterparts lies in the safe and proper handling of cross-integrity communication. For example, IEGetProtectedModeCookie is analogous to InternetGetCookieEx and IESetProtectedModeCookie is similar to InternetSetCookieEx. Related functions are listed in the See Also section of the reference page for each broker function.
Effectively Using Broker Functions
When designing applications that incorporate data obtained from resources secured to other integrity levels, you should assume that the data is inherently unsafe and may have been placed or altered by a malicious source. Indiscriminate use of data from low integrity sources can expose your application or process to security risks.
The following good practice guidelines should be considered when developing applications that depend on information provided by low integrity process or resource.
Cookies should be encrypted by the server and decrypted by the application.
The range of supported values for each data value should be set in advance, and each specific value should be tested against a set of known values. Exceptions should not be allowed.
Data from untrusted sources should not be inserted directly into a Web page or into an application's internal function calls. Control characters should be escaped or encoded as appropriate.
Functions using data loaded from protected cookies should be carefully designed to avoid buffer overflows, access violations, and other security concerns.
These guidelines are not all-inclusive and may vary depending on the scope of your project. For more information, see Design Guidelines for Secure Web Applications.