Embedded co-browsing security features
Unblu is designed with numerous security features to minimize the risks to your organization and its customers. This article describes some potential concerns you may have surrounding embedded co-browsing and how Unblu mitigates these risks.
A common use case for embedded co-browsing is to view a visitor’s screen during a support phone call. In such cases, the agent can provide the visitor with a PIN code by phone. The visitor then enters the PIN code on their computer to establish an embedded co-browsing session.
An attacker might try to join a conversation with an agent by entering the PIN generated for a visitor. If the attacker types the PIN before the visitor does, the attacker can join the conversation with the agent.
There are different ways the attacker might learn the PIN:
By guessing, that is, by repeatedly connecting to the Collaboration Server using different PINs, until the PIN entered by the attacker matches the one the Collaboration Server is expecting.
By intercepting the PIN when it’s transmitted, for example after the visitor has entered it.
The risks that arise from an attacker intercepting the PIN code are low. Since PIN-based conversations are normally initiated while the agent and visitor are conversing by some other means, both will quickly notice that the visitor hasn’t joined the conversation. Furthermore, the session ID of the visitor’s session is independent of the PIN. Even if an attacker learns the PIN, they can’t use it to guess the session ID. The PIN also doesn’t grant access to the visitor’s or the agent’s computer, or to their personal details.
Nonetheless, Unblu provides a number of ways to reduce the risk of an attacker guesssing the PIN code:
By default, the PIN is a six-digit number. You can, however, change the pattern of the generated PIN with the configuration property com.unblu.session.pinPattern, making it harder to guess.
By default, PIN invitations expire after 2 minutes. You can lower the timeout with the configuration property com.unblu.session.pinTimeout. The shorter the timeout, the less time an attacker has to guess the PIN code.
You can limit the number of failed PIN entries permissible before Unblu blocks access to a conversation with the configuration property com.unblu.ratelimit.redeemPinRateLimit.
Once the maximum number of failed PIN entries is reached, Unblu denies further requests to join the conversation in question for the period specified in the configuration property com.unblu.ratelimit.redeemPinRateLimitTTL.
If your organization uses embedded co-browsing to provide support for a web application such as e-banking, you may have concerns about giving another person the possibility to carry out actions as if they were logged in to the application, even if that person is an employee of your organization.
Unblu can’t prevent social engineering attacks, but it does provide means to prevent agents from abusing their role in co-browsing sessions.
The Collaboration Server never transmits passwords.
Agents can’t modify the contents of the visitor’s web page.
You can configure the Collaboration Server to block access to certain data presented through the instrumented web application. For more information, refer to Hiding specific page elements in a co-browsing session (field masking) in Configuring and manipulating collaboration layers.
An attacker may attempt to intercept communication between the visitor and the agent to obtain passwords, session information, cookie settings, or confidential information that could be used in a subsequent attack. Alternatively, the attacker may try to take over the visitor’s session to perform tasks, for example initiating a payment. If the attacker already has access to your network, they may attempt to gain access to an agent’s session.
Unblu takes the following measures to limit the risk of eavesdropping attacks:
Unblu terminates co-browsing sessions if it detects a change in the the visitor’s IP address.
The Collaboration Server never transmits the contents of password fields in embedded co-browsing sessions.
The session IDs for the visitor and the agent are completely independent. If an attacker learns one ID, they can’t use it to guess the other.
All session IDs are created using the Java Security
SecureRandomclass, a widely accepted method to create secure session IDs.
The client application doesn’t require Unblu cookies to be stored in the browser. You can use a secure proxy server that stores Unblu’s cookies internally and doesn’t hand them out to the client. (The proxy itself must still transmit a cookie of its own to be able to identify the user’s device.)
During embedded co-browsing, the Collaboration Server transmits the Document Object Model (DOM) of the page the visitor is on to the agent. This is what allows the agent to see what the visitor sees.
In a DOM injection attack, an attacker pretending to be a visitor attempts to inject malicious code into the DOM so that it’s executed on the agent’s computer. The agent’s computer is located in your organization’s network, and the attacker hopes to gain access to internal systems or the agent’s username and password, for example by displaying a login window on the agent’s computer.
DOM injection is possible in one of two ways: by injecting malicious code directly into the page viewed in the co-browsing session, or by injecting a link on the page that points to malicious code hosted on another server.
The Collaboration Server prevents such attacks by removing all executable code before it transmits the DOM of a co-browsed page to the agent’s browser. It removes the following elements:
HTML event handlers that may contain executable code, for example
<a>elements with the
CSS elements that may contain scripts.
CSS that isn’t recognized as valid and safe.
The HTML elements
If you don’t want the Collaboration Server to remove elements, change the value of the configuration property com.unblu.server.security.tagfilter to
Code is still executed in the visitor’s browser and the processed results are forwarded to the agent, so the website still works as expected.
In a link attack, the malicious code the attacker wants to transfer to the agent isn’t injected into the co-browsed page directly. Instead, it’s in a file hosted on a web server controlled by the attacker, and what’s injected into the DOM of the co-browsed page is a link to the file.
If the file is an executable, the agent must confirm that they wish to download the file and must then execute it themselves. If the malicious code is in a file format which supports rich media content, such as PDF or DOC, the agent must still download and open the file, but may be unaware that it contains executable code.
In a setup using the SecureFlow Manager (optionally with whitelisted internal resources), the Collaboration Server only displays content from the trusted sources you’ve configured. If a resource isn’t available from a trusted source, the Collaboration Server doesn’t display it. The attacker’s link, then, simply results in a failed request.
| If your organization lets visitors upload files, especially data URLs or
canvas images, to a trusted source such as your web server, an attacker might be able to place a malicious file there, and the Collaboration Server would send the file to the agent’s browser. You must therefore take measures to prevent the Collaboration Server and your agents from accessing files uploaded by visitors, to prevent visitors from uploading such files, or to ensure that such files contain no malicious code.