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.
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.
NOTE: The Agent must also be authenticated using an account in the session's group.
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, or might be
- some piece of information associated with the visitor, such as a user id or a tracking cookie ID. The agent might enter the session key manually, or it might be extracted automatically for the agent from data in a CRM record.
NOTE: Session keys may be numbers or strings of letters and numbers up to 63 characters in length. They may be specified randomly or any other way that makes sense.
Once a session key has been specified, the agent opens a browser window to the URL:
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.
Content Security Policy
The Cobrowse service transmits potentially sensitive visitor browsing information, and has therefore been designed with security as the highest priority.
NOTE: Glance never records or stores the content of any session.
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
Customer web pages may also, at the customer's option, use CSP headers for their security.
The connect-src CSP header for Cobrowse allows wildcard connections.
One recommended CSP header configuration for Cobrowse allows wildcard connections to any server in the
glance.net domain via https or secure websockets. Glance operates dozens of session servers for cobrowsing, and selects the best session server to use at the beginning of each session.
Glance Cobrowse requires a policy which:
https://s3.amazonaws.com/glancecdn/, unless self-hosting.
Allows cross domain requests to
Allows secure https and websocket connections to Glance’s session servers at *.glance.net.
If the Content Security Policy relies on default-src to specify trusted protocols and hosts, the following can be added to default-src:
If the Content Security Policy includes more specific directives:
For example, the server for one session might be
s1599.glance.net, and for the next session it might be
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:
Obtain and use a valid Glance https certificate to use on a malicious fake session server.
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.
Exfiltrate sensitive data or loading malicious content and contriving to use it.
Additional information on modifying CSP headers to allow visitors to run Glance sessions is available here.
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:
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 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.
<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.
Each Cobrowse server is a standalone hardened Unix 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.
NOTE: There is no specific protection against one agent viewing a session that might have been intended for another agent. Any agent in the group who knows the session key can join the session.
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.
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.
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.