Feature #47765: mgr/dashboard: security improvements
CVE-2020-27839: mgr/dashboard: The ceph dashboard is vulnerable to XSS attacks
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).
- 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.
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
Please see: https://medium.com/lightrail/getting-token-authentication-right-in-a-stateless-single-page-application-57d0c6474e3 for more details
#2 Updated by Stephan Müller about 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.
#4 Updated by Ernesto Puerta 5 months ago
httpOnly prevents XSS while
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.
@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 5 months 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