Cobrowse Security Architecture

Glance Cobrowse sessions allow one or more customer service agents to view the web browsing activity of visitors to a website. Agents see exactly what a visitor sees in their browser, with the exception of the contents of designated masked fields.

Security Architecture

The Glance Cobrowse service relies on a script loader tag embedded into each page of a customer website. This tag references a JavaScript file hosted by Glance on their own secure content distribution network. This section refers to the visitor side JavaScript file as Cobrowse.js.

When a customer clicks a button to start a cobrowse session, the Glance cobrowse loader script handles the click by:

• Reading the glance-cobrowse script or meta tag to determine parameters such as “group” and “staging vs. production”
• Adding, based on those parameters, a <script> element which references the full cobrowse script

This results in the browser requesting the full cobrowse script from the CDN (or the customer website in the case of self-hosting).

Cobrowse.js passes the customer group ID, and receives a unique session ID, a CServer assignment, and customer settings including masked fields.

The session ID is comprised of three components:

• Customer group ID
• Session key
• A randomly generated number to disambiguate that session from other sessions

Cobrowse.js stores the session ID and randomly generated number, along with the set of masked fields in a browser session cookie, and proceeds to start uploading session data to the designated CServer. The CServer, in turn, posts a message to the Glance web server to record the fact that the session has started in the database.

Both group ID and session key are required to join a session.

Once logged in, the group ID can be determined based on the agent’s Glance group membership.

Session keys can be specified on the agent side. For example, you can specify session keys in the following ways:

• A randomly assigned string.
• A piece of information associated with the visitor, such as a user id or a tracking cookie ID.

The agent can enter the session key manually, or it can be extracted automatically for the agent from data in a CRM record.

Once a session key has been specified, the agent opens a browser window to the URL:

https://www.glance.net/cobrowse/AgentView.aspx?SessionKey=ssnkey

If not logged in, the agent is prompted to log in and is then redirected back to this agent view. AgentView.aspx looks up the session in the database by agent group ID and session key and redirects the agent to the appropriate CServer. The CServer delivers the HTML representation of the Document Object Model to the agent’s browser, which then distills the HTML as if it was a website.

The CServer sends only HTML markup for the browsing session to the agent browser.

Resources referenced by the session HTML, such as images or style sheets, are downloaded by the agent directly from the customer website or its content delivery network. This lets the agent enjoy the best possible cobrowsing performance.

Security Considerations

The Cobrowse service transmits potentially sensitive visitor browsing information, and has therefore been designed with security as the highest priority.

The Cobrowse architecture addresses these security considerations.

Secure Agent View

When an agent attempts to join a session, a Glance web server looks up the session based on the agent’s Glance group ID and the supplied session key. If a matching session is found, the web server returns the session ID signed using a secret “server key.” The server key is a 256-bit number that is known only to the CServer and web server; a new server key is generated every 60 seconds. When an agent is redirected to the CServer to view the session, the CServer verifies the signature and only allows the agent to join if the signature is valid.

Once the agent has joined the session, a secure (flagged for HTTPS only) session cookie is used to maintain the agent session. The agent session cookie contains the session ID signed using a secret key known only to the CServer. The CServer secret key is generated at runtime and does not persist anywhere.

If the account is configured with the agent’s protocol following the visitor’s, then two agent session cookies are created, one HTTPS only and the other for HTTP. The HTTPS-only cookie is required to view any secure pages. An attacker who might have obtained the HTTP cookie will not be able to use it to view secure pages.

Websocket connections from the agent also pass the agent session cookie value when the connection is first established. The CServer only accepts websocket connections to a given session if the request includes a valid agent session cookie value.

No browsing session data is ever served by the CServer without a valid agent session cookie attached to the request. This guarantees that only agents who have a registered Glance account with a particular company are able to view sessions started by visitors to that company’s website.

Content Security Policy (CSP) Headers

The Cobrowse Agent Viewer uses Content Security Policy (CSP) headers to ensure that a malicious Visitor cannot compromise the Agent. The CSP ensures, among other things, that no JavaScript is embedded in the viewer page itself, nor is any JavaScript pulled in from untrusted sources.

Customer web pages may also, at the customer’s option, use CSP headers for their security.

Glance Cobrowse requires a policy which:

• Includes JavaScript, CSS, and images from https://*.glancecdn.net, unless self-hosting.
• Allows cross domain requests to https://*.glance.net and https://*.glancecdn.net.
• Allows secure https and websocket connections to Glance’s session servers at *.glance.net.

If your Content Security Policy relies on default-src to specify trusted protocols and hosts, the following URLs can be added to your default-src directive:

https://*.glancecdn.net
wss://*.glance.net
https://*.glance.net
blob:
'wasm-unsafe-eval'

With this directive your CSP header might look like this:

Content-Security-Policy: default-src 'wasm-unsafe-eval' blob: https://*.glancecdn.net  wss://*.glance.net https://*.glance.net

If you use more specific directives in your Content Security Policy, use these for Glance:

connect-src wss://*.glance.net  https://*.glance.net https://*.glancecdn.net;
style-src https://*.glance.net https://*.glancecdn.net;
script-src 'wasm-unsafe-eval' https://*.glance.net https://*.glancecdn.net;
img-src https://*.glance.net https://*.glancecdn.net;
font-src https://*.glance.net https://*.glancecdn.net;
frame-src https://*.glance.net;
worker-src blob:;

Glance operates dozens of session servers for Cobrowsing, and selects the best session server to use at the beginning of each session. For example, the server for one session might be s1599.glance.net, and for the next session it might be s2252.glance.net. The wildcard connect-src CSP header supports the dynamic selection of server at session start time. Therefore, it is required in customer web pages using CSP. The connect-src header only allows JavaScript to connect to specified origin servers via AJAX and related APIs.

The risk of using the wildcard CSP connect-src header is acceptable: it is difficult for a would-be attacker to exploit it. To do so would require an attacker to simultaneously:

1. Obtain and use a valid Glance https certificate to use on a malicious fake session server.
2. Run a DNS attack to place the malicious server at an address such as attacker.glance.net so the wildcard header allows connections to it.
3. Compromise some JavaScript (either Cobrowse.js or something else) on the customer web page to connect to the malicious server.
4. Exfiltrate sensitive data or loading malicious content and contriving to use it.

Secure Data Transmission

Using HTTPS (specifically: TLS 1.2 or better) or secure websockets for all communication ensures that all data is transmitted securely to servers whose identity has been verified. This includes:

• Downloading the Cobrowse JavaScript from the Glance web server to the visitor browser.
• Communicating between cobrowse.js and the Glance web server.
• Websocket/AJAX communicating between cobrowse.js and the CServer.
• Communicating between the CServer and the Glance web server.
• Downloading session data and the agent JavaScript to the agent’s browser.
• Websocket communicating between AgentView.js and the CServer.
• Downloading visitor session resources from the customer website to the agent browser.

JavaScript Integrity

Visitor JavaScript is downloaded using HTTPS from Amazon AWS, redirected from glancecdn.net. All modern browsers validate that servers delivering HTTPS have valid TLS certificates, so using HTTPS ensures that the script itself comes from a legitimate Glance web server.

It is the Glance customer’s responsibility to ensure that the Cobrowse JavaScript loader tag is embedded with HTTPS into their web property, even for non-secure pages. To encourage this, the Glance web server is not recommended to serve the visitor side JavaScript over HTTP, so that any attempt to access the JavaScript via HTTP will be detected during testing.

Masked Fields

Any HTML input field can be masked from the Agent and Glance service.

Masked fields can be identified two ways:

• Glance always masks any input field having a glance_masked class or attribute. Example:

<input type="text" class="glance_masked" value="hello"/> <input type="text" glance_masked="true" value="hello"/>

• A customer can configure their service to mask fields on-the-fly, without modifying their website. The fields are identified using standard CSS selectors. For example,

<input type="text" id="greeting" value="hello"/> can be masked with the ID CSS selector:

#greeting // [id='greeting']

These masked field definitions cannot be compromised, as they are stored in Glance’s secure database and retrieved by the visitor’s browser over a secure connection to a Glance web server.

The contents of masked fields never leave the visitor’s browser, so there is no possibility of this data being intercepted in transit or accessed from the CServer - even by an agent possessing a legitimate session cookie. Effectively, Glance technology never touches the contents of a masked field.

Secured CServer

Each Cobrowse server is a standalone hardened Linux or FreeBSD server with all superfluous services disabled. The server runs its own native firewall configured to allow incoming traffic only on secure port 443. No session data persists in any file or database on the CServer. Additionally, there are no per-agent restrictions within a group. However, roles can imply per-agent restrictions in a group.

Short Session Key

The session key allows an agent to identify a particular visitor’s session. The key is usually short being only four to six digits, so it’s easy for the visitor to read and say over the phone.

The session key is not a part of the security model, since the visitor’s browser stores the key in an insecure cookie. It can be vulnerable when uploaded unencrypted to a web server when the visitor navigates to an insecure page on the customer website.

Agent HTTP for Websites Distributed over a Content Delivery Network

If the agent session strictly uses HTTPS to access visitor session data, the agent browser will request all resources, such as images and stylesheets using HTTPS. Some website implementations, particularly those using a content delivery network, cannot deliver all resources over HTTPS.

To work around this, Cobrowse can be configured to allow the agent protocol to follow the visitor protocol, so that when the visitor navigates to an HTTP page, so does the agent, and vice versa. Two separate session cookies are maintained on the agent side, a secure cookie for viewing HTTPS pages, and a non-secure cookie for viewing HTTP pages. While the non-secure cookie provides a minimum level of security, the agent’s view of a non-secured page is not protected from traffic sniffing.

Session Security

Once a session is started with a particular group ID, any agent with a Cobrowse subscription within that group will be able to view the session. Therefore it is important to ensure that sessions can only run in groups that are explicitly allowed by the website authors.

Any time a session is started or continued (via the API, a window message, Presence, or continued after navigating or after crossing a domain boundary or when a page gets focus) there is a check to ensure that the group ID either matches data-groupid or is in the data-additionalgroupid list.

Cobrowse Settings

All Cobrowse settings are specific to the group in which the session runs, including:

• Masked elements
• Trusted domains for cross domain Cobrowse
• Trusted domains for invoking Cobrowse from a “chat” window

Presence with Multiple Groups

Presence always uses the group specified in data-groupID. So an agent wanting to join a session via Presence needs to be a member of both the first group in the list and the group in which the session is started.