- 1 Overview
- 2 Security Architecture
- 3 Content Security Policy
- 4 Security Considerations
- 5 Secure Agent View
- 6 Secure Data Transmission
- 8 Masked Fields
- 9 Short session key
- 10 Agent HTTP for Websites distributed over a Content Delivery Network
- 11 Security Practices
- 12 Session Security
- 13 Cobrowse Settings
Glance Cobrowse allows one or more customer service agent(s) to View, the web browsing activity of visitors to a website. Agents see exactly what a visitor sees in his or her browser, with the exception of the contents of designated masked fields. Examples of such fields may be a credit card number or password.
When a cobrowse session starts, a customer will click a button or link that references the “cobrowsescript” ID, which sends a “startSession” call through to the GlanceCDN. After authorization, the GlanceCDN sends the Cobrowse.js down to the website that initiated the session.
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 webserver 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 a number of ways. For example you can specify session keys 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.
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 collects and transmits potentially sensitive visitor browsing information, and has therefore been designed with security as the highest priority. The following security considerations are addressed by the cobrowse architecture:
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 webserver; a new server key is generated every 60 seconds. When the 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 such that the Agent’s protocol follows the Visitor’s, then two agent session cookies are created, oneHTTPS only and the other for HTTP. The https-only cookie is required to view any secure pages. An attacker who might have obtained theHTTP 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.
Secure Data Transmission
Using HTTPS (specifically: TLS 1.1 or better) or secure websockets for all communication ensures that all data is transmitted securely, to servers whose identity has been verified. This includes:
- Communication between cobrowse.js and the Glance web-server
- Communication between cobrowse.js and the CServer
- Communication between the CServer and the Glance web-server
- Communication between AgentView.js and the CServer
- Downloading visitor session resources from the customer website to the agent browser
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. E.g.:
<input type="text" class="glance_masked" value="hello"/>
<input type="text" glance_masked=”true” value="hello"/>
2. A customer can configure their service to mask fields “on-the-fly”, without modifying their web site. The fields are identified using standard CSS selectors. E.g.:
<input type="text" id="greeting" value="hello"/>
can be masked with the ID CSS selector
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 visitor’s browser, so that 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 will never even touch 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.
Short session key
The session key’s sole purpose is to allow an agent to effortlessly and uniquely identify the visitor’s session. Oftentimes, the session key is very short (just four to six digits), so it’s easy for the visitor to read and say over the phone.
The session key itself is not part of the security model. Since the visitor’s browser stores the session key in an insecure cookie, it is 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, Glance Cobrowse can be optionally 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.
Cross site scripting security
The Glance web application is built to resist attack. We use dedicated web servers and database servers, with all unnecessary features removed to reduce the attack surface. We have development policies and tools in place to create code that resists injection, cross-site scripting, and request-forgery attacks.
We use cryptographically random (hard-to-guess) session keys with automatic expiration to resist credential-replay attacks. We store only hashed passwords, hashed according to current security best practice. Each customer organization may select their own password-complexity standards.Our architectural design prohibits the downloading or uploading of any data to the session servers.
We use a host-based intrusion detection system to identify suspicious behavior. Server updates and patches are applied in accordance with the severity of the issues they address: weekly, monthly. Because attack vectors are always evolving, we test our application for vulnerabilities at least twice a year with the latest version of tools such as BurpSuite and ZAPScan, and repair vulnerabilities they uncover.
Glance Networks stores the Session details from any given session. We only store session metadata and do not store any data from the session itself.
We store the following session metadata:
- the Glance URL (Agent Glance address),
- the Session Type (whether a Cobrowse or Screenshare session).” – remove comma and period?
Internal Glance Monitoring
If requested by a customer via written correspondence, an authorized Glance Super-user can join an active session for the purpose of testing or monitoring activities. We would require the unique Session ID and the Glance User Address to locate and join that session. We do not actively monitor any sessions and make it a practice to not join any session unless otherwise required to by our clients.
Glance cobrowsing has the capability to escalate sessions from one-to-one to many-to-one. This enables an agent to invite another authorized agent to join the in-process cobrowse session. This capability ensures a soft hand-off for the end-customer.
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, or presence, or continued after navigate 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.