Server version: An attacker forging a dedicated attack can, depending on whether the victim would watch the forged spreadsheets, read/perform operations with the credentials of the victim. If administrators used the "websudo" correctly, it prevented from performing administrative operations.
Cloud version: An attacker would only be able to perform operations in the Spreadsheets app, but not in Confluence. In Confluence, they would be able to read any data that is visible by a user, save it in a spreadsheet and retrieve it.
Has it been used?
Cloud version: We've inspected the audit trails, which are all set to 30 days, and there is no trace of this attack being used. Audit trails are immutable, once written. We've also inspected the current instances and no customer is currently affected by a XSS attack.
Server version: We don't have access to customers' data.
Description of the vector
On May 27th around 3pm, we've noticed that we didn't properly escape some HTML strings in our app. In theory, a user was able to forge a spreadsheet, which another user could view, which could contain a JS script.
Atlassian's architecture is to display addon data in iframes, which limits the impact:
Our addon runs with the READ permissions of Confluence, so any data visible to a user opening the spreadsheet could have been seen by an attacker,
The REST API of our addon allows modifying the data, so the attacker could have modified other people's data. However, anyone can modify anyone's data, since the spreadsheets can be edited by anyone on a Confluence instance, so I don't believe there has been a change here.
The impact is greater for the server version. If any person viewed a spreadsheet prepared by an attacker, any operation allowed to that user could have been performed.
Timeline
Discovered on May 27th 2019 around 3pm,
Fixed at 5.37pm on the Cloud version.
Fixed around 8pm for Server versions (v3.1.3), but customers are yet to install them.
Verifications for all existing customers finished on May 28th at 10am (No customer seems affected by an XSS).
XSS injection vulnerability on both the Cloud and Server version of Play SQL Spreadsheets.
Below is a description of the info we've sent to Atlassian under https://ecosystem.atlassian.net/servicedesk/customer/portal/14/DEVHELP-2846
Description of the impact
Server version: An attacker forging a dedicated attack can, depending on whether the victim would watch the forged spreadsheets, read/perform operations with the credentials of the victim. If administrators used the "websudo" correctly, it prevented from performing administrative operations.
Cloud version: An attacker would only be able to perform operations in the Spreadsheets app, but not in Confluence. In Confluence, they would be able to read any data that is visible by a user, save it in a spreadsheet and retrieve it.
Has it been used?
Cloud version: We've inspected the audit trails, which are all set to 30 days, and there is no trace of this attack being used. Audit trails are immutable, once written. We've also inspected the current instances and no customer is currently affected by a XSS attack.
Server version: We don't have access to customers' data.
Description of the vector
On May 27th around 3pm, we've noticed that we didn't properly escape some HTML strings in our app. In theory, a user was able to forge a spreadsheet, which another user could view, which could contain a JS script.
Atlassian's architecture is to display addon data in iframes, which limits the impact:
Our addon runs with the READ permissions of Confluence, so any data visible to a user opening the spreadsheet could have been seen by an attacker,
The REST API of our addon allows modifying the data, so the attacker could have modified other people's data. However, anyone can modify anyone's data, since the spreadsheets can be edited by anyone on a Confluence instance, so I don't believe there has been a change here.
The impact is greater for the server version. If any person viewed a spreadsheet prepared by an attacker, any operation allowed to that user could have been performed.
Timeline
Discovered on May 27th 2019 around 3pm,
Fixed at 5.37pm on the Cloud version.
Fixed around 8pm for Server versions (v3.1.3), but customers are yet to install them.
Verifications for all existing customers finished on May 28th at 10am (No customer seems affected by an XSS).