DOM Injection

JavaScript Attack


Pretending to be a visitor, the attacker starts a co-browsing session and tries to inject their own script code into the DOM (Document Object Model) in the hope that it will be transmitted when the collaboration server replicates the visitor’s web page structure on the agent’s computer. Because the agent is in the company’s intranet, the attacker hopes to gain access to internal computers, or to the agent’s username and password, by displaying a login window on the agent’s computer.

How we Prevent JavaScript Attacks

The collaboration server removes all executable code before it transmits the DOM to the agent. It removes the following elements:

  • Scripts, such as JavaScript.

  • HTML attributes that may contain executable code, such as onChange, onLoad and on- KeyDown.

  • Object, Embed and Applet-tags (this can be configured.)

  • JavaScript Links (the link tag itself remains, but the collaboration server clears any content).

  • CSS elements that may contain scripts, such as Internet Explorer‘s CSS filter.

  • Any CSS code it does not recognize as valid and safe.

Can this JavaScript Attack Succeed in a Cloud Setup?

The collaboration server also blocks this type of attack in the cloud setup (in the same way).


The attacker puts a file with malicious code on a web server and then tries to send the agent a link to that file, hoping the agent will download the file and execute the code. In a co-browsing session, the visitor’s web page is displayed on the agent’s computer by replicating the web page structure (the DOM, or Document Object Model). So the attacker tries to modify a link in the DOM so that it points to the malicious file. How this file is executed depends on the level of sophistication of the attack. For example:

  • If the file contains executable code, the attack requires little sophistication. However, the agent has to agree to download the file and then must manually execute it.

  • If the file contains rich media (such as a PDF file), the attack requires sophistication, because PDF files are secured against known possibilities to insert code. The agent still has to download and open the file, but may be unaware that it contains executable code.

  • If the file is a simple media file (such as an image file), the attack requires a high degree of sophistication, because images usually cannot contain code, and browsers are thoroughly tested against this type of attack. However, images are loaded automatically by the browser, which facilitates the execution of the attack.

In a secure setup, the collaboration server never transmits an image or file from the internet to the agent’s computer. Instead, it only accepts the company web server as a trusted source. The collaboration server will attempt to load all resources that the agent requires from the company web server. If a resource is not available, the collaboration server simply does not display anything. Thus, a malicious link will simply result in a failed request to the collaboration server.

Caution: To prevent this kind of attack, the collaboration server considers the company’s web server as a trusted source. However, if an attacker can place a malicious file on the company’s web server, then the collaboration server will transmit it to the agent during a co- browsing session. In conclusion: If visitors can upload files to your web server, make sure that the collaboration server (and your agents) do not have access to these files.

In a cloud setup, this attack is technically possible, if the agents can freely access the Internet from their computers. However, the attack requires sophistication from the attacker, and does not represent a more serious threat than sending a link in an email message.

Compromising the Agent Session

Abusing the Agent Role

Eavesdropping on the Visitor Session

Guessing the PIN Code

Hijacking the Visitor Session

  • deploycloud
  • deployonprem

results matching ""

    No results matching ""