Monday, May 13, 2013

Authorized Applications and Google Chrome

 VS.                


Today I'd like to share a thought regarding a scenario where applications that users are allowed to use are controlled via Group Policy and/or a desktop agent and outbound Internet access is inspected by a gateway proxy.  In these types of controlled environments, Internet Explorer is typically the preferred browser by systems administrators due to its ease of manipulation from a centralized management perspective.

That aspect of centralized management can be a pain in the butt from a user perspective.  If the version of Internet Explorer is outdated, runs slow, and/or is generally difficult to use then most users seek an alternative.  The most common browsers people commonly flock to in such a situation are Mozilla Firefox and Google Chrome.

When people attempt to download Firefox, they may get blocked by the proxy if that proxy is using a content filtering solution such as Blue Coat's WebFilter or some other enterprise solution.  These blocking mechanisms are broad, category-based mechanisms like "software downloads" or "web applications".  Interestingly, Mozilla Firefox's download URL is categorized as software downloads, and if that category is blocked then users are prevented from installing Firefox.  All pages for the Google Chrome download on the other hand are categorized as "Search Engines/Portals".  Obviously blocking search engines is counter-productive, so the site is allowed, and thus the download of Google Chrome.

When the Google Chrome installation is first attempted, it will fail because the default install requires elevated privileges.  However, when the installation fails, Google is kind enough to ask if we want to try to install without admin privileges.  After clicking yes, Google Chrome is able to be installed!  Thus, after about 15 minutes of tinkering, we are able to circumvent our organization's centralized browser control.

Fortunately for this organization, we have a proxy.  To prevent users from using Chrome even after they go through this process, simply block the User-Agent HTTP Request Header string using RegEx.  If you're unsure of the User-Agent string, check out whatismyuseragent.com.  The RegEx match to block Chrome can simply be "(.*)Chrome(.*)" since normally Chrome's UA String looks like this:  
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31
The (.*) is a wildcard that will catch everything leading up to "Chrome" and everything after.

Of course, a user could still get around this by changing Chrome's UA string, but that's a story for another day.

No comments :

Post a Comment