Browsium

Knowledge Base

Using Browsium Catalyst to control which browser is used for which Security Zone

Applies To

Browsium Catalyst 1.0 or later

Summary

Browsium Catalyst has the ability to define Rule actions based on several categories:

  • URL Pattern Matching
  • Regular Expression
  • Security Zone

This knowledge base article reviews how security zones work and ways to ensure proper use of security zones in Catalyst to direct users to the required target browser.

Details

About security zones

Consumers generally access all content from the Internet, where the default security assumption should be that content is untrusted and barriers should be provided to protect the user’s system. Therefore most modern web browsers default to security settings that are appropriate for Internet. If browsers were only used for the Internet, one group of settings would make sense for everything. But this is often not the case for users on their employer’s private intranet.

The concept of security zones, which is unique to Internet Explorer, is based on the premise that not all content is created equally. More importantly, not all content should be viewed with the same security settings. The business environment is quite different from the consumer use case, where employees have access to internal business systems, not to mention externally hosted partner systems (extranets). Some content (e.g., internal line of business applications) may require more advanced/relaxed security access to the local system in order to function properly. Without Security Zones to enable lower security settings for trusted networks, users would need to open their systems to potentially endless Internet attacks just to make certain business applications work as required.

Security zones for other browsers

Catalyst was designed to enable the deployment of multiple browsers within a business environment by ensuring IT has centralized control over which browser is used for which web application on each PC in the organization. Many organizations want to use Internet Explorer for internal, line of business applications and another browser (such as Google Chrome or Mozilla Firefox) for external, Internet) use. Catalyst makes this very easy, even though only Internet Explorer was designed to be ‘zone aware’.

By connecting Catalyst to the WinInet API, Catalyst is able to deliver Zone-based behaviors to any supported browser. When a user enters a URL, the Catalyst system queries the API to determine which Zone the site falls into, and then takes the specified action to invoke the IT-required target browser and properly display the desired content.

For example, the following rules can be used to control the choice of target browser by Zone.

catalyst-zone-rules

 

Designating the zone in a Catalyst Rule with the Zone Match Method

Catalyst Configuration Manager has a dropdown box for the zone name (in the Value field). You can choose from any available zone, designating all URLs in that zone to open using the chosen Target Browser.

catalyst-zone-rules-editor

 

About Zone Determination

Zone determination follows some simple general guidelines. First, sites are checked against the list of items listed in the Trusted Sites or Restricted Site Zone. If there is a match, the content is displayed using that Zone template. With no match, the decision gets more complicated. The next step is to determine if the site is in the Local Intranet Zone (LIZ). With no match to the other Zones, the site is considered to be in the Internet Zone, unless it meets certain criteria detailed below. (For a complete reference on Security Zones, see the Microsoft MSDN article.)

For most organizations, the LIZ will be the most important for creating Catalyst rule-based actions and it is also has the most complicated Zone mapping behaviors. There are effectively four ways a site can be determined to be in the LIZ:

Directly mapped – Like the Trusted Sites and Restricted Sites lists, a site is defined by an administrator to be displayed using the LIZ template.

  • The “Dot Rule” – If a hostname does not contain a period (dot), the site is determined to be in the LIZ.
  • Proxy bypass list – Another manual mapping/list of defined sites, this list is used to ensure sites will not be contacted using the defined proxy. Since the sites are specified not to use the proxy, they are assume to be internal and thus in the LIZ.
  • Proxy script (WPAD/PAC) – Using the auto-configuration option for proxy determination, this Zone determination checks to see if a given URI returns a value of PROXY or DIRECT. If the value returned by the FindProxyForUrl function is DIRECT, the site is determined to be in the LIZ.

Unexpected Security Zone Determination

These four scenarios cover most LIZ mapping, but there are some common situations that may cause unexpected behavior.

One is related to the ‘Dot Rule’, where an internal site can be resolved by both a hostname and a fully qualified domain name (FQDN). For example, if a user enters http://internal, the site would clearly fall under the Dot Rule and be placed in the LIZ. If the same site were accessed by entering http://internal.mycompany.com, Zone determination would treat the site as an Internet site. If the organization was using a proxy bypass list or Proxy script, then both versions would report as LIZ.

Organizations looking to use Catalyst rules based on Security Zone should check for this scenario to ensure the expected behavior. To resolve this situation, either remove FQDN listings from your DNS, implement a Proxy Script/Bypass solution, or directly map the appropriate sites. Another option would be to configure internal web based systems to redirect FQDN traffic to the hostname so users are properly forced to the right Zone determination.

Posted in: Catalyst Knowledge Base

  • Share:  

Request Demo

FLASH END OF LIFE - We have a solution to allow you to use Adobe Flash securely after it's been deprecated.SCHEDULE A CALL