Bug #44591
Updated by Anonymous about 4 years ago
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: solutions. * h3. 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. * h3. 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. * h3. 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