Monday, April 23, 2018

DOM XSS in Google VRView library

While testing the VRView web application we discovered a DOM Based Cross-Site Scripting Vulnerability in the handling of errors through an inappropriate use of the "innerHTML" property. The use of this property must be combined with the encoding of the data before it is used for data assignment, and in this case it wasn't used safely.

Since the vulnerability also affects two of the most used Wordpress vrview plugins, an attacker could take control of the remote system that uses these plugins through a code analysis, or through automated tools.

Depending on the type of vulnerability and the role of the vulnerable component within the system, it can lead to trivial effects on the complete ownership of the server and the compromise of any data contained in it. The aspect to always keep in mind is that for the execution of the external components the principle of the minimum privilege is almost never applied.

About VRView

Vrview is a library developed by Google for embedding immersive media into traditional websites.

As described on the main website:

VR view allows you to embed 360 degree VR media into websites on desktop and mobile, and native apps on Android and iOS. This technology is designed to enable developers of traditional apps to enhance the apps with immersive content. For example, VR view makes it easy for a travel app to provide viewers with an underwater scuba diving tour as they plan a vacation or for a home builder to take prospective buyers on a virtual walk-through before the home is built.

The Vulnerability

The vulnerability lies in the management of library errors, in fact, if it is specified through URL parameters: url or image, a nonexistent resource, the library returns an error including in the error message the resource specified in the request without executing the output encoding .

As can be seen from the code below, the user input data passed through the GET request parameters is passed to the "innerHTML" property without performing the parameter encoding output. In this way, an attacker can specify an XSS payload instead of the requested resource, the library will interpret the resource as non-existent and respond with an error indicating the XSS payload entered by the attacker, thus generating an arbitrary code execution Javascript.

The following shows the vulnerable code in the VRView library:


/* [...] */
function onSceneError(message) {
    showError('Loader: ' + message);

function onRenderError(message) {
    showError('Render: ' + message);

/* [...] */

function showError(message, opt_title) {
   // Hide loading indicator.

   var error = document.querySelector('#error');
   error.querySelector('.message').innerHTML = message;

   var title = (opt_title !== undefined ? opt_title : 'Error');
   error.querySelector('.title').innerHTML = title;

/* [...] */

Proof of Concept

The links below shows the vulnerability in real world example, the vulnerability includes other sub/domains that have not been mentioned such as "".



Please note that the links above contains a patched version of the library.

Vulnerable Wordpress Plugins

Following are the two vulnerable Wordpress plugins found during the vulnerability analysis.

1) WP-VR-view -

WP-VR-view is a plugin that allows you to display Photo Sphere images and 360 video on wordpress pages, posts, etc.
Website visitors will be able to navigate through your panoramas.
Smartphone users can use Google cardboard to look through in Virtual reality way.

Proof of Concept:<img%20src=x%20onerror=alert(document.domain)>

2) VRView -

VRView makes it easy to embedd Googles VRView into your WordPress installation.
Embed 360° Videos and VR Videos as Well as panorama photos into your WordPress-Installation.

Proof of Concept:<img%20src=x%20onerror=alert(document.domain)>

Please refer to section A9 of the OWASP Top 10 to check if the application makes use of external components, libraries, frameworks and dependencies from modules that are affected by known vulnerabilities:

A9 - Using Components with Known Vulnerabilities

Disclosure Timeline

  • 19-01-2017 – Report to Google Security Team;
  • 20-01-2017 – Received a first feedback said that the report was triaged;
  • 20-01-2017 – Received a second feedback said that the vulnerability exists;
  • 14-02-2017 – Reply from Google Security Bot - The panel has decided to issue a reward of $3133,7;
  • 16-03-2018 – The vulnerability was fixed (;
  • 23-04-2018 – Public disclosure.


Google VRP panel has decided to reward with a high reward as the vulnerability is included not only in sandboxed domains but also
Vulnerability Found and Reported by Federico Fazzi.


  1. So was it not fixed and exploitable b/w 14-02-2017 and 16-03-2018?

  2. This comment has been removed by the author.