Tag Archives: security

Fixed Cross-Site Scripting Vulnerability on Project Page’s External Links

We recently fixed a security vulnerability that existed in the external/social links (e.g. to Twitter) of projects. Prior to this fix, it was possible for project owners to do two things: 1. create external links that ran malicious JavaScript code if they were clicked (e.g. allowing attackers to capture a user’s login session), and 2. create a link to a malicious website disguised as a “legitimate” link to a known Social website (e.g. a Twitter link that actually directed users to the spoof website “twiitteerrer.com”). Our patches fix both issues, and a follow up investigation revealed that there is no indication this vulnerability was exploited by anyone.

The security issue was discovered on 11 Dec 2018 during an internal security check. The first patch in the series (addressing the major JavaScript injection vulnerability) was deployed within 6 hours, and the final patch (addressing the relatively less harmful issue of spoof-able social links) deployed 2 days later.

The fixes for this vulnerability are contained in pull requests #5141, #5142, and #5148 of the Panoptes Front End project on GitHub. Anyone running their own hosted copy of this should pull these changes as soon as possible.

Additional notes on our investigation are as follows:

  • The vulnerability was introduced on 14 May 2015, in pull request 324.
  • Custom links for projects and organisations allowed project builders to cause a user’s browser to execute arbitrary javascript by entering URLs like javascript: alert('oh no'); if the user clicked on that link, the javascript would run.
  • Malicious javascript executed this way could do whatever it wanted on the site, i.e. it could have stolen logged-in users’ API tokens, logged users out and captured their passwords when re-logging in.
  • Theoretically, passwords may have been have been exposed if malicious Javascript captured them on login, though this would only impact users that click malicious links. Emails may have been exposed, notably if an admin user account was breached.
  • However, we audited the database but could find no evidence (other than our own tests) of this having been done by project owners.
  • Our current solution is to sanitise all external/social links – both when taking input from users and when rendering them on webpages – and only allowing standard website URLs to pass.

As a side effect of our fixes, project owners are now unable to add non-standard website URLs to their project’s external links – for example, https://example.com continues to work fine, but mailto:hello@example.com no longer does.

We apologise for any concern this issue may have caused.

Fixed cross-site scripting vulnerability on project home pages

We recently fixed a security vulnerability in the way project titles are handled on project home pages. Prior to this it was possible to create a project which included Javascript in its name, and thus inject code into the page. After investigating this incident, we have determined that this vulnerability has not been exploited for any malicious purpose; no data was leaked and no users were exposed to injected code.

This vulnerability was reported to us on June 20, 2018, by Lacroute Serge. We began testing fixes around three hours later, which were deployed about 15 hours after the original report, on June 21, 2018.

The fixes for this vulnerability are contained in pull requests #4710 and #4711 for the Panoptes Front End project on GitHub. Anyone running their own hosted copy of this should pull these changes as soon as possible.

We have investigated the cause and assessed the impact of this vulnerability. A summary of what we found follows:

  • No data was leaked as a result of this vulnerability. The vulnerability was not exploited for any malicious purpose and there was no unauthorised access to any of our systems.
  • The vulnerability was introduced on September 12, 2017, in a change which was part of our work to allow projects to be translated into multiple languages.
  • We found three projects that contained exploits for this vulnerability (not including projects created by our own team for testing purposes): two were created before the vulnerability was introduced, so the exploit wouldn’t have worked at the time they were created (it might have worked if the projects were visited between September 12, 2017, and June 21, 2018, but no-one did so); the remaining project was created by the security researcher who reported the vulnerability.
  • Our audit included previous titles for projects (all changes to projects are versioned, so we were able to audit any project titles which have since been changed).
  • All three projects contained only benign code to display a JavaScript alert box. None of them attempted to perform any malicious actions.
  • No users other than the project owner and members of our development team visited any of these projects, so no other users activated any of the exploits.

We’d like to thank Lacroute Serge for reporting this vulnerability to us via the method detailed on our security page, following responsible disclosure by reporting it to us in private to give us the opportunity to fix it.

The Heartbleed Bug and the Zooniverse

On Monday Internet security researches discovered a critical vulnerability in a piece of of software called OpenSSL. The so-called Heartbleed vulnerability affected numerous sites on the Internet that rely on OpenSSL to provide encrypted connections over HTTPS. This bug has been present in the library since March of 2012 and allows malicious users to gain direct access to the memory of a server terminating an HTTPS connection.

We want to let our users know that we were among almost 66% of sites on the Internet vulnerable to this bug, and your data (including your Zooniverse password) might have been compromised due to this exploit. As of now, all our infrastructure has been updated to secure against the Heartbleed vulnerability, and our SSL certificates have been changed.

Unfortunately given the nature of the vulnerability we cannot know what, if anything, may have been obtained, but as a precaution we are recommending that our users change their passwords on the Zooniverse just in case.