Arvados

A CSRF or XSS attack could enable an attacker to obtain or use secret tokens.

Background¶

Right now, after log in, the token gets stored in the Rails4 session cookie.

XSS: Attacker inserts a <script> tag in content that gets rendered on the same page as the CSRF token and API token.[1] That script can read the tokens from the DOM, use the tokens to make API requests, and send the tokens to a server of the attacker's choice.

• Workbench's session is encrypted using workbench's "secret_token" (note: the session cookie is only encrypted by default in rails 4, in rails 3 the cookie is signed but not encrypted!). This means that based on the session alone, the page's javascript does not normally have access to the api token. However:
• The script does not need to decrypt the session in order to make authenticated Workbench requests.
• The page does currently provide the unencrypted API token in a meta element, as a way to enable the Workbench client code to make API (REST and websocket) and Keep requests. (The crux here seems to be: it should be possible for Workbench's own scripts to make arbitrary API/keepproxy requests, but impossible for a malicious script injected in a Workbench page to do the same thing.)

CSRF: User visits attacker's web site. A script or image tag there causes user's browser to make Workbench requests which are (a) permitted because the user has active session cookies, and (b) not prohibited by the browser's CORS policy.

• Rails provides some CSRF protection using its own token system.
• API server does not use session cookies for most routes (but it does use them during login).
• Other services (keepstore, keepproxy) do not use session cookies at all.

¹ Since we allow textile markup for descriptions, there's a decent chance that malicious users can already inject javascript into workbench project pages (either by design using <notextile> or if notextile is disabled, then by exploiting inevitable bugs in the markup engine).