We recently fixed a security vulnerability whereby an attacker could upload executable content to our media storage domains.

On 13th November 2022, a security researcher notified us of a cross-site scripting (XSS) vulnerability affecting our media storage domains. This XSS vulnerability made it possible for attackers to upload content to our storage domains that could then be shared as links for use in ‘phishing’ or other attacks.

We fixed the vulnerability on the morning of the 15th November 2022 by blocking script access to the API from the impacted domains ensuring any malicious code failed to gain access to authenticated private data. This remedial action was followed by a another fix on the 16th November that deployed block rules on our Content Distribution Network (CDN) provider to prevent malicious resource links being served to users. In addition, on the 8th of December we deployed a change to the API to only allow non-malicious files to be uploaded to these storage domains.

The mitigation and fix steps described above allowed us time to research the problem and audit our storage systems for any live exploits. After this audit we determined that this vulnerability had not been exploited for any malicious purpose; no data was leaked and no users were exposed to injected code.

We’d like to thank Michal Biesiada (https://github.com/mbiesiad) for bringing this issue to our attention and for following responsible disclosure by reporting it to us in private, as requested on our security page.

On 9 November 2020, a security researcher notified us of a cross-site scripting (XSS) vulnerability on our zoomapper application. This service hosts tile sets that are used to render maps for a small number of other Zooniverse applications, but is not connected to any critical Zooniverse infrastructure. This XSS vulnerability could have allowed users to execute malicious code on the zoomapper application in the browser.

We were able to remediate the vulnerability within hours of the report by disabling the browser GUI for zoomapper (see PR #6). The GUI had been turned on by default for the zoomapper app, but is not necessary to fulfill the app’s intended role.

Additional notes on the incident:

• The vulnerability existed since the app was first deployed on September 15th 2020.
• The vulnerability was located in the underlying Tileserver-GL dependency.
• No Zooniverse user or project data was vulnerable or exposed by this vulnerability.

We’d like to thank Rachit Verma (@b43kd00r) for bringing this issue to our attention and for following responsible disclosure by reporting it to us in private, as requested on our security page.

In the beginning of April 2020, we were notified that subjects from one Zooniverse project were appearing in the subject set of a separate project where they did not belong. In our investigation of the issue, our team determined that this behavior was being caused by a Caesar configuration mistake that used an incorrect Subject Set ID. Project owners using Caesar were able to create Subject Rule Effects that added subjects to collections or subject sets, even without proper subject set editing permissions. We have rectified the issue surrounding Subject Rule Effects and eliminated this vulnerability, and would like to share the details for anyone who is interested.

The issue was raised by project lead James Perry (@JamesPerry), who reported that subjects that didn’t belong to his project were appearing in his subject sets.  Due to a mistyped subject set ID in a Caesar `add_to_subject_set` effect for an unrelated project, that Subject Rule Effect was sending subjects from that project to one of James’s subject sets instead of the correct target.

Our immediate course of action was to fix the project impacted by the vulnerability, and push out a temporary code fix to prevent the vulnerability from being exploited. 

1. To fix the affected project, we updated the incorrect subject set id for the project that was incorrectly sending subjects to the wrong project and removed the unwanted subjects from the set. 
2. On April 3rd we deployed a temporary code fix to disable Subject Rule Effect creation and modification for all but admin users (see PR #1109). This change was communicated to affected teams that were most impacted by the change, and teams that reached out after seeing our notification banner or encountering a Caesar interface error.

On May 15th we pushed out a permanent fix that checked the user has permissions to send data to the target subject set or collection. Specifically, the updated validation code checks that the user has update permissions on the project the subject set or collection is linked to. (see PRs #1115, #1129 and #1131). 

For anyone running their own hosted copy of Caesar, we recommend pulling these changes as soon as you’re able.

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.