There are complex questions surrounding enterprise web browser management. Mario Finetti suggests some practical answers.

1 Requirements for web browsers
This article will discuss methods to ensure that the browsers used across the enterprise are uniform, up-to-date and secure. Let us look at the two most important requirements for enterprise web browsers: uniformity across the organisation; and security.

1.1 Uniformity across the organisation
Dealing with a single browser configuration greatly reduces the effort of managing enterprise web applications. Once you have tested with the standard client, you are sure all clients will behave in the same way. If a problem arises, the support personnel can easily tell client-side and server-side questions apart. Enterprise web applications are often required to deal with customers, external partners and recently merged companies that do not meet the enterprise's client-configuration policy.

1.2 Security
Web browsers play a critical role in the security of the organisation. First, they are often used to browse the internet and so they deal with a lot of untrusted/harmful input data. Then, web browsers are used to access enterprise data and to perform business transactions. Compromised web browsers put the business at risk, even if the web application itself was designed and developed in a secure way.

Below we go through common practices for enterprise web browser management and analyse typical problems. Some innovative solutions are briefly described.

2 Security patching
An unpatched web browser is an easy target for attacks. In the worst case, an unpatched vulnerability could allow malicious code to be executed and give a malicious entity unlimited privileges on the computer of the victim. This is often done just to deliver unsolicited ads, but unfortunately this is not always the case. The malicious entity that controls the client may impersonate the user on the web applications they connect to. The Trojan called Silentbanker is an example. This malware waits until the user connects to their bank's website and then performs wire transfers using their details (see Symantec report in ‘External links').

As another example, in January 2010, Google announced that some Gmail accounts had been violated by means of client-side malware. Again, this was very much the result of client-based malware acting on the user's account, remotely controlled by a malicious entity.

Applying the security patches for the browser, browser's plug-ins and helper applications is universally recognised as best practice. On the other hand, common sense suggests the need to proceed carefully when distributing a software update to many users. Most enterprises prefer to test security patches before rolling them out. This shifts the responsibility for patch management from the software update mechanisms of the browser or the OS to the IT department. In a typical deployment, for example, Microsoft Windows Update is disabled so clients take patches from the enterprise software distribution infrastructure. I would suggest answering the questions below before replacing the native software update mechanisms with an enterprise software distribution service.

2.1 Can you manage the software distribution process?
Analysing and testing security patches takes time. It is very unlikely that you will deliver security patches as fast as Microsoft Windows Update does. On the other hand, by managing the patch distribution process yourself, you will track the status and the success rate – so you can take action if any client fails to receive the updates. Also, you will be able to postpone and schedule the software updates that require particular planning, such as a browser upgrade. Depending on the characteristics of the enterprise, IT needs to find the best balance between the speed of the patch distribution process and user productivity.

2.2. Can you reach all users?
It is critical that your software distribution infrastructure is configured to reach users both when they are connected to the enterprise network and when they are directly connected to the internet. Avoid leaving mobile workers connected to the web with both Windows Update disabled and the enterprise software distribution service unreachable.

3 Browser update
Jeffrey Zeldman and Ethan Marcotte in their book, Designing with Web Standards (New Riders Press, 2009), reported that a sizeable number of IE6 users did not upgrade because it is the enterprise web browser of their company. On 2 August, the SC Magazine website reported the UK Government position on browser upgrade: “It is not straightforward for HMG departments to upgrade Internet Explorer. Upgrading to IE8 can be a very large operation, taking weeks to test and roll out. To test all web applications used by HMG can take months, at significant cost to the taxpayer. It is more cost-effective to continue to use IE6 and rely on other measures, such as firewalls and malware-scanning software, to further protect public sector internet users.”

As outlined above, the biggest problem is testing the new browser against existing applications. Enterprise web applications are often tested with the enterprise browser only and developed with that in mind. During a project, it may seem wise and cost-effective to simplify the task of the team by reducing the number of browsers to test with. As a consequence, the development team is not encouraged to follow the W3C and ECMA standards (HTML, XHTML, CSS and the standard version of JavaScript). In the worst case, they will rely very much on the peculiar characteristics of the enterprise browser – even if the code will not work with any other browser or device.

Assuming that a certain website will never be accessed by a different browser is a dangerous bet. Even if the web page was initially designed for employees only, there are so many situations in which different browsers may need to access it: users coming from recently merged companies, external partners that need to participate in a process, employees using the browser embedded in a mobile device. It is not cost-effective to review the code after the application has been delivered. The best is to develop with multiple clients in mind.

In their book, Zeldman and Marcotte present guidelines for developing applications to work with any browser currently available, as well as any browser that will be released in the future. Also, they explain how to do it without forking the code or maintaining different versions of the same page for different devices.

The fundamental rules are:

3.1. Use semantic HTML
HTML should only include the information to be provided to the user and nothing related to how this information is presented. CSS should take care of the presentation. This way, your page will always be rendered in a reasonable way – even though not in a perfect way – on every browser and device.

3.2. Follow the standards
Recent browsers generally comply with the W3C and ECMA standards. Unfortunately, this is not the case for aged browsers. The piece of code required for a specific browser should be encapsulated in a library or in a separate function, while the main code should be conformant to the standards, so if a new browser is released, you will not need to change the code.

Developing enterprise applications according to these rules is the best way to ensure that you will not run into problems when upgrading to new browser versions.

4 Browser configuration/hardening
Another way to protect from online threats is to configure the web browser so that the security features work properly and the attack surface is as small as possible. Browser patches sometimes do nothing more than changing the default setting of browser security configuration. This is something that the IT department can do in advance with little effort.

The US National Institute of Standards and Technology (NIST) published useful guidelines on how to configure the security settings for IE and Safari (see ‘External links'). Generally, a trade-off exists between security and usability: strict security settings reduce the features available and this could prevent the web apps from working properly. The security settings suggested by NIST are designed to reduce the attack surface, while keeping most browser features enabled.

SSL/TLS security features deserve special attention. A malicious website spoofing the URL of a trusted enterprise application would be a huge threat. Firstly, it could act as a ‘man-in-the-middle' and impersonate the legitimate user of the application. In addition, it could take advantage of the looser security settings for trusted websites in order to install malicious software on a user's computer and then impersonate them within the enterprise network.

To perform an attack of this kind, the malicious user should first compromise the network. Some networks are still vulnerable to the ‘ARP (address resolution protocol) poisoning' attack. This allows a malicious computer to modify the ARP table of any host in its IP subnet and put itself in the middle between the victim and any other computer it communicates with. The adoption of Layer 2 switches, by itself, does not mitigate this threat. However, recent switches implement mechanisms that effectively mitigate the problem (see Cisco essay in ‘External links'). Where enterprise desktops are concerned, you can design the network in order to mitigate the ARP poisoning threat. Unfortunately, you cannot control the network that mobile workers and external partners use to connect to the enterprise.

A popular type of software called ‘Cain and Abel' (aka ‘Cain') allows you to perform this attack using any PC and a simple GUI. If the network is vulnerable to the ARP attack, very little technical expertise is required to exploit it.

Let us now look at the most important part: the SSL/TLS certificates. When the browser needs to access a URL beginning with ‘https://', it starts an SSL/TLS handshake with the web server. During this phase, the server authenticates with the client by means of a digital certificate. The client checks that the server certificate is valid before completing the SSL/TLS handshake. If the server's certificate is not okay, a security alert is shown, but the user has the option to proceed anyway. In order to analyse the traffic exchanged between the victim and a website protected by HTTPS, Cain forges a digital certificate and presents it to the victim's browser as the server certificate. If the user accepts the forged certificate, a first SSL/TLS connection is established between the victim's browser and the PC running Cain. Another SSL/TLS connection is then established between Cain and the website originally requested. The forged certificate is very similar to the certificate of the legitimate web server: the only difference is that the forged certificate is not signed by a trusted certification authority (CA) – in fact, it is signed by Cain. The user's browser will put up a security warning saying that the server certificate is not okay. It is critical that users take these messages seriously and do not proceed. If users always see security alerts of this kind during their day-to-day activities, it is very likely that they will be deceived. IT staff should make sure that browser settings are okay (ie that all browsers are equipped with required CA certificates) and enterprise web applications always use valid certificates. If the IT department fails to ensure this, users will get used to ignoring security messages on server certificates and will hardly detect a man-in-the-middle attack if it actually occurs.

Another example of how a malicious entity could spoof the URLs of an enterprise website is based on the ‘internationalised domain name (IDN) homograph attack'. Basically, the malicious user registers a DNS domain name including a few Cyrillic characters so it looks like another domain name – that of the victim's website. This is made possible by the fact that many Cyrillic, Greek and Armenian letters look like Latin letters. The DNS handles them as different characters, but browsers show them in a similar or even identical way.

This threat is mitigated by the top-level domain (TLD)'s registration procedures. Recent web browsers provide different kinds of countermeasures against this attack. Again, the IT department needs to find the best balance between security and user needs. The most radical solution is to disable browser support for IDN so that all IDN domains will be displayed with regular ASCII characters.

5 Safe internet browsing: web filtering and virtualisation
The guidelines for safe internet browsing very much depend on the nature of the business of the company. The clients connected to critical process control networks, for example, are not connected to the internet at all.

When allowed, internet browsing can be filtered in order to protect enterprise clients from phishing and malicious websites in general. From a security perspective, web filtering provides these benefits:

  • Filtering prevents users from browsing insecure or compromised websites. Web filtering tools can block websites hosting malicious scripts as well as websites being used for malicious purposes such as phishing
  • After being installed, malware generally connects to the internet in order to deliver the data stolen from the client and to receive instructions or updates from malicious entities. It is not impossible to circumvent web filtering by using an allowed website as a bridge to communicate with the malicious entity. However, web filtering definitely does provides a good level of protection in practice.

Websites secured by HTTPS deserve special attention. Web filtering tools need to inspect the HTTPS content, while SSL and TLS protocols were designed to provide ‘end-to-end' security. In other words, SSL/TLS creates an encrypted channel between the web browser and the website that no intermediary can decrypt. To successfully inspect HTTPS traffic, web filtering tools terminate a first SSL/TLS connection between the web browser and the web filtering system. Then a new SSL/TLS connection is established between the web filtering system and the website requested by the user. This way, the web filtering system can see the HTTP traffic in clear text. It is critical that the certificate provided by the web filtering system is signed by a certification authority trusted by all browsers subject to web filtering. Otherwise, users will see a ‘bad certificate' security message. The web filtering tool is also responsible for validating the server certificate presented by external websites.

Another complication with web filtering is that mobile workers access the web using an internet connection that is not controlled by the enterprise. This problem can be addressed by means of client-side tools that provide remote laptops with the same filtered web browsing experience as computers within the enterprise network. Examples include the Websense Remote Filtering plug-in and internet VPN solutions.

As far as security is concerned, virtual browsers represent another possible defence against malicious and compromised websites. The basic idea is to run a web browser within a virtual environment so that if an attacker manages to run malicious code on the environment hosting the browser, the rest of the system will not be affected. Also, the virtual environment can be regenerated from scratch with very little effort, removing any malware installed on it.

Many commercial solutions provide this feature. Systems management appliance company Dell Kace, for example, provides a virtual environment running Firefox and the most common browser plug-ins such as Adobe ( Symantec and VMware provide similar solutions.

Google Chrome adopts a slightly different approach. Instead of providing a virtual environment, Google's sandbox adjusts the security privileges of the process responsible for rendering web pages so that it cannot access the system. Google's statement on virtualisation is particularly interesting: “Emulation and virtual machine solutions do not by themselves provide security.” The initial benefit of a virtualised solution is that malware is generally not aware of virtualisation. Once the virtual environment is compromised, the malware is happy. If the malware is aware of virtualisation, however, it will try to attack the underlying system. The Symantec paper in the external links section analyses and discusses this new kind of threat.

6 Cross-site scripting
New browser versions provide enhanced security features that were not present in previous versions. An example is the ‘cross-site scripting' attack (also known as XSS), as well as protection against phishing.

XSS is one of the most common web application security threats, as reported by the OWASP's Top 10 Most Critical Web Application Security Risks (see ‘External links').

This XSS attack exploits the lack of input data validation in an innocent website that is trusted by the victim. The innocent website could be an enterprise web application and the victim an employee authorised to perform transactions through this application. The malicious user invites the victim to navigate a URL in the trusted website domain. The URL includes a piece of JavaScript code that will be executed in the victim's browser as if it was originated by the trusted website. As a consequence, the malicious script will run with the loose security settings reserved for trusted websites. Also, confidential information exchanged between the victim's browser and the trusted website will be disclosed to the malicious user. The typical target is the session ID that allows the malicious user to impersonate the victim on the trusted website.

Ideally, web applications should mitigate this threat by validating user input. Unfortunately, this is not always the case. Recent web browsers such as Internet Explorer 8 provide client-side countermeasures against XSS. Dedicated plug-ins exist, such as ‘NoScript' for Firefox (

7 Trusted browsers running on untrusted hosts
This section looks at a different approach to protecting web browsers in a business environment. Instead of protecting the system on which the web browser is running, this approach tries to isolate the web browser from a possibly compromised host environment.

Let us take, as an example, Ironkey Trusted Access ( To perform critical transactions, users are required to launch a hardened web browser running on a virtual environment that is somehow isolated and protected from the host environment. Even if the host environment is compromised, malware cannot easily attack the browser. This solution was designed for home banking, but could be applied to enterprise applications as well.

Generally speaking, protecting a computer program from a compromised host is a very difficult problem. The host environment is always one step ahead of the hosted system. This question is being analysed by an academic research project called RE-TRUST (Remote EnTrusting by RUn-time Software). “The RE-TRUST project aims to develop techniques to provide assurance to a server program that a program running on a remote untrusted host is executing untampered. We assume, however, that the untrusted host has a trusted computing device on which we can rely.”

The project website ( provides a clear description of this problem, as well as the state-of-the-art research in this field.

Mario Guido Finetti works as an ICT program manager at Italian multinational oil and gas company Eni (, focusing on application level security, IAM, SOA and configuration management.

External links

Symantec report on Trojan Silentbanker:

Google on the attack against Chinese human rights activists' Gmail accounts:

UK Government on browser upgrade:

National Institute of Standards and Technology (NIST) on web browser configuration:

Cisco on VLAN security:

Christopher Crowley, ‘Preventing incidents with a hardened web browser', SANS Institute:

Peter Ferrie, ‘Attacks on virtual machine emulators', Symantec advanced threat research:

Open Web Application Security Project (OWASP), ‘Top 10 Most Critical Web Application Security Risks':

Remote EnTrusting by RUn-time Software (RE-TRUST) project website: