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. Architectural design prohibits the download of anything nor allows users to upload 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. Security policies endorsed by CTO.
Glance Networks stores the Session details from any given session. We do not store any of the data from the session itself, but rather the details about the session at a high-level.
We store the following:
- start time
- stop time
- number of guests that join the session
- the first guest’s approximate location based on the public IP address
- the Glance URL (Agent Glance Address),
- the Session Type (whether a Cobrowse or Screenshare session).
Internal Glance Monitoring
Glance has the Super-User capability to monitor a session if a request comes from our customer that the session be joined. 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.
We do have the capability to have a many to one experience for our end-customers. This means that an agent may invite another authorized agent to join a cobrowse session. Doing this means that the agent may escalate the conversation from one agent to two agents and have a soft handoff with 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.
Cobrowse Settings with Multiple Groups
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
Each group has its own button customization. If using the default user interface, the Cobrowse scripts will load custom button styles according to which group the session is running in.
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.