Contents
Previous Topic: URL Security Zones
Next Topic: Appendix A: Header File Additions Required for ActiveX Controls
| | |
| ||
| ||
URL Security Zones Overview
Monikers, URLs, security zones, and pluggable protocols provide capabilities that allow you to asynchronously bind objects, bind Uniform Resource Locators (URLs), manage URL security zones, and create custom URL protocols. This section covers the functionality exported by the Urlmon.dll dynamic-link library (DLL).
Creating a Customized URL Security Manager
Introduction
If you want to compile programs that use the functionality provided in Urlmon.dll, you must make sure the Urlmon.h header file is in the include directory, and the Urlmon.lib library file is in the library directory, of the C/C++ compiler you use.
This documentation assumes that you have an understanding of Microsoft® Win32® programming. Also, for asynchronous monikers, asynchronous pluggable protocols, and URL monikers you should have an understanding of OLE and COM programming. For the Internet-related interfaces, methods, and functions, an understanding of the format and syntax of URLs is also required. For more information, see RFC 1738, Uniform Resource Locators (URL). You can find this document at http://ds.internic.net/rfc/rfc1738.txt.
About URLs and Name Spaces
A Uniform Resource Locator (URL) follows the syntax described in RFC 1738, which specifies a protocol scheme followed by a scheme-specific portion (<scheme>:<scheme-specific portion>). For example, in the URL http://www.microsoft.com/, "http" is the scheme and "//www.microsoft.com/" is the scheme-specific portion.
The beginning portion of the scheme-specific portion of the URL contains the server name. This portion of the URL is often referred to as the URL name space.
About URL Security Zones
To fully understand URL security zones, you need to understand a few terms:
- URL action is an action that a browser can take that might pose a security risk to the local computer. These include actions such as running a Java applet (URLACTION_JAVA_PERMISSIONS in this case) or an ActiveX™ control (URLACTION_ACTIVEX_RUN in this case).
- URL policy is a policy that determines what permission or trust level is set for a particular URL action. These include setting the safety level for Java to high (URLPOLICY_JAVA_HIGH in this case).
- URL security zone is a group of URL name spaces that are assigned an equal level of permission (or trust). Each URL action for the zone has an appropriate URL policy assigned to it that reflects the level of trust given to the URL name spaces in that zone.
Previously, Microsoft Internet Explorer utilized the same security policy for all URL name spaces. Each URL action in a particular security level was handled by a predetermined URL policy, which could not be changed. In Internet Explorer 4.0, URL name spaces are divided into URL security zones, which have different levels of trust assigned to them. Users can easily customize the default URL security zones by changing the URL policy settings for each URL action with the user interface provided by Internet Explorer.
Default URL Security Zones
The default URL security zones used by Internet Explorer 4.0 are:
- The Intranet
- Trusted Web sites
- Internet
- Untrusted sites
The Intranet zone is used for content located on a company's intranet. Since the servers and information would be within a company's firewall, a user or company could assign a higher trust level to the content on their intranet.
The following table contains the default settings for the intranet zone.
The Trusted Web sites zone is used for content located on Web sites that are considered more reputable and/or trustworthy than other sites on the Internet. Users can use this zone to assign a higher trust level to these sites to minimize the number of authentication requests. The URLs of these trusted Web sites would need to be mapped into this zone.
The following table contains the default settings for the Trusted Web sites zone.
The Internet zone is used for the Web sites on the Internet that do not belong to another zone. The default settings would cause the user to be prompted whenever potentially unsafe content was about to be downloaded. Web sites that are not mapped into other zones automatically fall into this zone.
The following table contains the default settings for the Internet zone.
The Untrusted sites zone is used for Web sites that contain content that could cause, or have caused, problems when downloaded. This zone could be used to cause the user to be prompted every time potentially unsafe content was about to be downloaded or prevent that content from being downloaded. The URLs of these untrusted Web sites would need to be mapped into this zone.
The following table contains the default settings for the Untrusted sites zone.
There is also an implicit zone used for content that exists on the local computer. The content found on the local computer, except for content cached by Microsoft Internet Explorer on the local system, is treated with a high level of trust. Content that has been cached by Internet Explorer is accessed through the URL of origin and is assigned to the appropriate zone.
The following table contains the default settings for the local computer zone.
Asynchronous pluggable protocols can specify how their URLs should be assigned to a security zone. The IInternetProtocolInfo::ParseUrl method using the PARSE_SECURITY_URL value should return a URL that the security manager can use to make decisions.
URL Actions and Policies
Each URL security zone has a set of URL actions with a URL policy assigned to it. The URL actions cover all operations that have security implications. A URL policy is assigned to each URL action to determine how that URL action will be handled. For example, URLACTION_JAVA_PERMISSIONS would be checked for operations related to Java applets. To force all Java applets to run out of a sandbox (that is, prevent it from doing anything that would be a security risk to the local computer), the URL policy would be set to URLPOLICY_JAVA_HIGH.
Some URL actions are an aggregate of two or more URL actions. The user interface for the default URL security zone manager would allow the user to set the aggregate value only (such as URLACTION_HTML_SUBMIT_FORMS). The browser would call the specific value (such as URLACTION_HTML_SUBMIT_FORMS_FROM) because it is reacting to that particular action. If the aggregate URL action has a URL policy set, that policy is used for the aggregate URL action and the specific URL actions it aggregated. All security zone managers must be designed to handle calls to the specific URL actions and know where to find the appropriate URL policy.
Handling URL Security Zones
There are two scenarios where you would use the URL security zone interfaces:
- Applications that are hosting either the WebBrowser control or IE4/MSHTML and want to implement their own security manager to handle security zones.
- Controls that are hosted by IE4/MSHTML and want to get information about a security setting.
In a few cases, an application might want to manage the default URL security zone settings by using the IInternetZoneManager interface. The changes would not be static, because the user could override any changes by setting the URL security zone options in Internet Explorer 4.0. In most cases, applications that need to control the URL security zone settings should create an application that hosts the WebBrowser control or IE4/MSHTML and implement their own security manager.
Interfaces related to URL security zones
Applications Hosting the WebBrowser Control or IE4/MSHTML
The WebBrowser control or IE4/MSHTML hosts could create a security manager (by implementing the IInternetSecurityManager interface) that handles the URL actions and policies that are important to the host. Other URL actions and policies would be passed to the default security manager so it can handle them appropriately. The IInternetSecurityMgrSite interface would be used to handle Windows®-related information from the component so that the customized security manager can handle any user interface it needed.
To create a customized security manager, the component must implement the IInternetSecurityManager interface. Any methods or URL actions that the customized security manager wants the default security manager to act on should return INET_E_DEFAULT_ACTION.
The component must also implement a ClientSite object when embedding either the WebBrowser control or IE4/MSHTML.
The following steps occur for a URL action:
- IE4/MSHTML uses CoCreateInstance to create an instance of the Internet Security Manager.
- The Internet Security Manager calls the QueryInterface method on IE4/MSHTML to get its IServiceProvider interface. IE4/MSHTML then calls the QueryInterface method on the IOleClientSite interface to get the IServiceProvider interface.
- IServiceProvider::QueryService is called to get an IInternetSecurityManager interface. The component then passes a pointer to its implementation of IInternetSecurityManager to the Internet Security Manager.
- Calls from IE4/MSHTML to the IInternetSecurityManager methods are passed to the custom security manager from the default Internet Security Manager.
- If the method called returns INET_E_DEFAULT_ACTION, the default implementation of IInternetSecurityManager is used to resolve the call. Otherwise the result from the custom security manager is returned.
- The Internet Security Manager returns the result back to IE4/MSHTML.
Note The URL security zone API offers support only for a single, customized security manager to delegate URL actions back to the default security manager. If more than one customized security manager is implemented, the additional security managers must explicitly find and invoke the security manager above it to allow multiple delegations to operate correctly.
Components Hosted by IE4/MSHTML
Components hosted by the WebBrowser control or IE4/MSHTML might need to query the security manager for the URL policies being implemented in the URL security zone they are in. These components include script engines (JScript and VBScript), controls, Java applets, code download, and so on. For example, the code download component of Internet Explorer 4.0 needs to ask the security manager if it can download unsigned ActiveX Controls. The component calls the IInternetHostSecurityManager::ProcessUrlAction method to check what the policy is on Java applets to help make its decision.
To query for URL policies, these components use the IInternetHostSecurityManager interface. The component must also have the address of a site interface implemented by the WebBrowser control or IE4/MSHTML. The exact site interface would depend on the type of component being hosted. For example, a script engine should have the IActiveScriptSite interface implemented, while controls would implement an IOleClientSite interface. To get the address of this interface:
- The component calls the QueryInterface method on the site interface to get the IServiceProvider interface. The component then calls IServiceProvider::QueryService to get the IInternetHostSecurityManager interface.
- The component calls the IInternetHostSecurityManager methods. The host security manager creates an instance of the Internet Security Manager. The host security manager then adds the URL and calls the associated method on the IInternetSecurityManager interface.
If a custom security manager was implemented by a host application, the default Internet Security Manager would pass the call up to the custom security manager's IInternetSecurityManager interface.
- The IInternetSecurityManager method would return its results to IInternetHostSecurityManager, which would then pass the results to the component.
Creating a Customized URL Security Manager
A customized URL security manager can be created for applications that host either the WebBrowser control or IE4/MSHTML by implementing the IInternetSecurityManager interface. Most of the IInternetSecurityManager methods, except IInternetSecurityManager::ProcessUrlAction, would only need to return INET_E_DEFAULT_ACTION to defer the call to the default security manager.
The following example shows an implementation of the IInternetSecurityManager::ProcessUrlAction method for a customized security manager that wants to require that data be encrypted.
HRESULT MySecurityManager::ProcessUrlAction( LPWSTR pwszUrl, DWORD dwAction, BYTE *pPolicy, DWORD cbPolicy, DWORD dwReserved ) { DWORD dwPolicy = URLPOLICY_ENCRYPT_REQUIRED; if (dwAction == URLACTION_ENCRYPT_DATA) { if (cbPolicy >= sizeof (DWORD)) { *(DWORD *)pPolicy = dwPolicy; return S_OK; } else return S_FALSE; } else return INET_E_DEFAULT_ACTION; }Note The Internet Explorer 4.0 default security manager cannot be replaced by a customized security manager.
Accessing the Default Managers
To access the default Internet Security Manager and Internet Zone Manager objects, the client application should use the CoCreateInstance function to create an instance of these objects.
The following sample creates an instance of both the Internet Security Manager and the Internet Zone Manager.
HRESULT hr; IInternetSecurityManager *pSecurityMgr; IInternetZoneManager *pZoneMgr; hr = CoCreateInstance(CLSID_InternetSecurityManager, NULL, CLSCTX_INPROC_SERVER, IID_IInternetSecurityManager, (void**)&pSecurityMgr); hr = CoCreateInstance(CLSID_InternetZoneManager, NULL, CLSCTX_INPROC_SERVER, IID_IInternetZoneManager, (void**)&pZoneMgr);
Top of Page
© 1997 Microsoft Corporation. All rights reserved. Terms of Use.