Project

General

Profile

Bug #44591

Feature #47765: mgr/dashboard: security improvements

CVE-2020-27839: mgr/dashboard: The ceph dashboard is vulnerable to XSS attacks

Added by Sebastian Krah over 1 year ago. Updated 8 months ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
General
Target version:
-
% Done:

0%

Source:
Tags:
Backport:
octopus, nautilus
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

To authenticate the user with the ceph dashboard the user can exchange a username and password for a jwt token. This token will be stored inside the users browser. On every request, the ceph dashboard attaches this token to the 'Authorization' header to get access to the api.
The problem is how we store this token. Currently, we just save it inside the local storage of the browser which makes it vulnerable to XSS attacks. If any of our npm dependencies is compromised, an attacker could steal the token of a user and use it. I also tried to inject malicious code into the translation files, we host on transifex. I did not manage to attack the dashboard with that approach, because the angular i18n compiler rejected all script tags, but that does not mean that it is not possible.
Keeping the npm packages up to date is very important, but doesn't fix the problem either. Not anyone, who is running a ceph cluster, is going to update it on a regular basis (every week or two).

Currently I see three solutions:
  • Critical actions should always ask for user credentials
    What are critical actions? From my point of view, at least all user management actions. Changing the role of a user or en- and disabling an account of another user should not be possible without entering the password of the current user.
  • 2FA
    Using two factor authentication will mitigate attacks. At least the attacker cannot request a token with just the username and password. The XSS problem would still exist.
  • Double submitted cookies
    Storing the jwt token in a httpOnly cookie prevents XSS attacks, but opens the door for csrf attacks. With sending two coockies, one containing the jwt header and payload (httpOnly disabled), and one containing the signature, could be a solution. JavaScript can not read the content of httpOnly cookies, but the content of cookies without httpOnly. So, our frontend could read the header.payload and sends it with every request, inside a meta tag. The backend could then reconstruct the token.

Please see: https://medium.com/lightrail/getting-token-authentication-right-in-a-stateless-single-page-application-57d0c6474e3 for more details


Related issues

Related to Dashboard - Cleanup #48584: mgr/dashboard: remove auth/check and modify redirectURL for SSO New
Related to Dashboard - Cleanup #47341: mgr/dashboard: securing CherryPy Resolved
Copied to Dashboard - Backport #48738: nautilus: CVE-2020-27839: mgr/dashboard: The ceph dashboard is vulnerable to XSS attacks Resolved
Copied to Dashboard - Backport #48739: octopus: CVE-2020-27839: mgr/dashboard: The ceph dashboard is vulnerable to XSS attacks Resolved

History

#1 Updated by Sebastian Krah over 1 year ago

  • Description updated (diff)

#2 Updated by Stephan Müller over 1 year ago

Another approach that could help would be to using a data stream instead of HTTP1.1 polling by using websockets or HTTP2 (https://tracker.ceph.com/issues/45306).

Another thing could be to store the IP of the user in the backend and force a relogin, by expiring the session, if the IP or MAC has changed.

#3 Updated by Ernesto Puerta about 1 year ago

  • Parent task set to #47765

#4 Updated by Ernesto Puerta about 1 year ago

Sebastian: httpOnly prevents XSS while secure and SameSite=Strict together prevent CRSF attacks... I've been reading this OWASP page but I couldn't find an understandable explanation on why they state that SameSite set cookies don't fully prevent CSRF. My bet is that they don't consider the combination of httpOnly + secure + SameSite=strict.

In fact, the author of that Medium blog post has this conversation with a user:

@Kin Ng: why not just use one http only cookie for the jwt and have the front end make another request for the necessary user role info and store in memory?

@author: While that approach would certainly work for general authentication and role info retrieval and security, going to one cookie wouldn’t allow the other benefits mentioned around session timeout and extension that relies on the cookies having different expiry settings

The most relevant thing is that we ensure that we don't have GET methods that trigger unsafe actions/side-effects (I checked that I saw none).

#5 Updated by Ernesto Puerta about 1 year ago

Additionally, now Ceph-Dashboard requires an Accept header that follows an un-standard pattern application/vnd...+json, so this is one (custom header) the 3 strategies OWASP recommends to complement the SameSite setting.

#6 Updated by Ernesto Puerta 12 months ago

  • Status changed from New to Fix Under Review
  • Assignee set to Avan Thakkar
  • Pull request ID set to 38259

#7 Updated by Avan Thakkar 12 months ago

  • Related to Cleanup #48584: mgr/dashboard: remove auth/check and modify redirectURL for SSO added

#8 Updated by Nathan Cutler 12 months ago

  • Backport set to octopus, nautilus

(Optimistic that this will be backported)

#9 Updated by Volker Theile 11 months ago

  • Status changed from Fix Under Review to Pending Backport

#10 Updated by Backport Bot 11 months ago

  • Copied to Backport #48738: nautilus: CVE-2020-27839: mgr/dashboard: The ceph dashboard is vulnerable to XSS attacks added

#11 Updated by Backport Bot 11 months ago

  • Copied to Backport #48739: octopus: CVE-2020-27839: mgr/dashboard: The ceph dashboard is vulnerable to XSS attacks added

#12 Updated by Ken Dreyer 11 months ago

  • Subject changed from mgr/dashboard: The ceph dashboard is vulnerable to XSS attacks to CVE-2020-27839: mgr/dashboard: The ceph dashboard is vulnerable to XSS attacks

We're tracking this as CVE-2020-27839.

#13 Updated by Avan Thakkar 10 months ago

#14 Updated by Avan Thakkar 10 months ago

  • Status changed from Pending Backport to Resolved

#15 Updated by Ernesto Puerta 8 months ago

  • Tracker changed from Fix to Bug
  • Project changed from mgr to Dashboard
  • Category changed from 132 to General
  • Regression set to No
  • Severity set to 3 - minor

Also available in: Atom PDF