What is browser isolation?
Browser isolation is a technology that keeps browsing activity secure by separating the process of loading webpages from the user devices displaying the webpages. This way, potentially malicious webpage code does not run on a user’s device, preventing malware infections and other cyber attacks from impacting both user devices and internal networks.
Visiting websites and using web applications involves a web browser loading content and code from remote, untrusted sources (e.g. faraway web servers), then executing that code on a user's device. From a security perspective, this makes browsing the web a fairly dangerous activity. Browser isolation instead loads and executes code far away from users, insulating them and the networks they connect to from the risks — just as using robots to perform certain dangerous tasks within a factory can keep the factory workers safer.
There are three main kinds of browser isolation: cloud-hosted (or remote), on-premise, and client-side.
- Remote browser isolation technology loads webpages and executes any associated JavaScript code on a cloud server, far removed from user devices and organizations' internal networks.
- On-premise browser isolation does the same thing, but on a server that an organization manages internally.
- Client-side browser isolation still loads the webpages on a user device, but it uses virtualization or sandboxing to keep website code and content separate from the rest of the device.
In all three methods of browser isolation, the user's browsing session is usually deleted when it ends, so any malicious cookies or downloads associated with the session are eliminated.
Browser isolation can be an important component of a zero trust security model, in which no user, application, or website is trusted by default.
How does remote browser isolation work?
Remote or cloud-hosted browser isolation keeps untrusted browser activity as far away as possible from user devices and corporate networks. It does so by conducting a user’s web browsing activities on a cloud server controlled by a cloud vendor. It then transmits the resulting webpages to the user's device so that the user can interact with the Internet like normal, but without actually loading full webpages on their device. Any user actions, such as mouse clicks or form submissions, are transmitted to the cloud server and carried out there.
There are several ways a remote browser isolation server can send web content to a user's device:
- Stream the browser to the user: The user views a video or an image of their browsing activity; this technique is also known as "pixel pushing." This method introduces latency to user browsing activities, sometimes resulting in a poor user experience.
- Open, inspect, and rewrite each webpage to remove malicious content, then send to the local user browser: With this method, known as DOM rewriting, webpages are loaded in an isolated environment and rewritten to remove potential attacks. Once the content is considered safe, it is sent to the user's device, where the webpage code loads and executes a second time. This approach may not be compatible with all websites.
- Send final output of webpage to user: Once a webpage fully loads and all code is executed by the browser, a vector graphics representation of the final version of the webpage is sent to the user.
How does on-premise browser isolation work?
On-premise browser isolation works similarly to remote browser isolation. But instead of taking place on a remote cloud server, browsing takes place on a server inside the organization's private network. This can cut down on latency compared to some types of remote browser isolation.
The downside of on-premise isolation is that the organization has to provision their own servers dedicated to browser isolation, which can be costly. The isolation also usually has to occur within the organization's firewall, instead of outside it (as it does during the remote browser isolation process). Even though user devices remain secure from malware and other malicious code, the internal network itself remains at risk. Additionally, on-premise browser isolation is difficult to expand to multiple facilities or networks, and especially so for remote workforces.
How does client-side browser isolation work?
Like the other kinds of browser isolation, client-side browser isolation virtualizes browser sessions; unlike remote and on-premise browser isolation, client-side browser isolation does this on the user device itself. It attempts to keep browsing separate from the rest of the device using either virtualization or sandboxing.
Virtualization: Virtualization is the process of dividing a computer into separate virtual machines without physically altering the computer. This is done at a layer of software below the operating system called the "hypervisor." Theoretically, what happens on one virtual machine should not affect adjacent virtual machines, even when they are on the same device. By loading webpages on a separate virtual machine within the user's computer, the rest of the computer remains secure.
Sandboxing: A sandbox is similar to a virtual machine. It is a separate, contained virtual environment where testing can safely take place. Sandboxing is a common malware detection technique: many anti-malware tools open and execute potentially malicious files in a sandbox to see what they do. Some client-side browser isolation products use sandboxes to keep web browsing activity safely contained within the sandbox.
Because client-side browser isolation involves actually loading potentially malicious content on the user device, it still poses a risk to users and networks. Physical separation of harmful code from the device is a core concept of the other types of browser isolation; client-side browser isolation does not have this separation.
What threats does browser isolation defend against?
All webpages and web apps are composed of HTML, CSS, and JavaScript code. While HTML and CSS are markup languages, meaning they only provide formatting instructions, JavaScript is a full programming language. JavaScript is very useful for enabling many of the features seen in modern web applications. However, it can also be used maliciously. Malicious JavaScript is particularly dangerous because most web browsers automatically execute all JavaScript associated with a page.
Several different types of attacks are possible using JavaScript. Some of the most common include:
- Drive-by downloads: Simply loading a webpage initiates the download of a malicious payload. Drive-by downloads usually take advantage of an unpatched vulnerability in a browser.
- Malvertising: Malicious code is injected into legitimate ad networks. When the malicious ads are displayed, the code executes, usually with the result that visitors are redirected to malicious websites. Because legitimate ad networks are the ones unintentionally distributing the malicious code, malvertising can compromise even legitimate, highly trafficked websites.
- Click-jacking: A webpage is designed so that a user is fooled into clicking on something they did not intend to. Click-jacking can be used to generate fake ad revenue, send a user to an unsafe website, or even initiate a malware download.
Some other common in-browser attacks (that may or may not involve JavaScript) include:
- Redirect attacks: A user attempts to load a legitimate URL but is then redirected to a URL controlled by an attacker.
- On-path browser attacks: An attacker exploits browser vulnerabilities to compromise a user's browser, at which point they can alter the web content shown to the user or even impersonate the user.
- Cross-site scripting: Malicious code is injected into a website or web app. This allows attackers to carry out a variety of malicious activities, including stealing session cookies or login tokens and then impersonating legitimate users.
How does browser isolation protect against these attacks?
By isolating browser sessions in a controlled environment, malicious content and code is kept off user devices and away from the organization's network. For example, a drive-by download attack would have no effect on a user within an organization that uses browser isolation. The download would take place on a remote server or in a sandbox and would be destroyed at the end of the browsing session.
How does browser isolation fit into a zero trust security architecture?
Zero trust is an approach to information security in which no user, web traffic, application, or device is trusted by default. A zero trust security model assumes that even though a user has safely loaded a website 99 times, the website might be compromised on the 100th time. Browser isolation is one way to implement this assumption in practice.
Cloudflare incorporates a zero trust approach into its network security product stack. Cloudflare Browser Isolation is a remote browser isolation service designed to provide an optimum user experience. Because Cloudflare Browser Isolation is built on the Cloudflare network, with global locations in 200 cities, web browsing sessions are served as close to users as possible, minimizing latency. Additionally, Cloudflare Browser Isolation sends the final output of each webpage to a user instead of sending an image or stream, further reducing latency.