Bug #4690

[DRAFT] [Workbench] Prevent CSRF and XSS attacks

Added by Peter Amstutz over 4 years ago. Updated over 4 years ago.

Status:
New
Priority:
Normal
Assigned To:
-
Category:
-
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Story points:
1.0

Description

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.

1 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).


Related issues

Related to Arvados - Bug #4692: [API] Prompt user when logging in to a client for the first time.New

History

#1 Updated by Peter Amstutz over 4 years ago

  • Description updated (diff)

#2 Updated by Peter Amstutz over 4 years ago

  • Description updated (diff)

#3 Updated by Peter Amstutz over 4 years ago

  • Description updated (diff)

#4 Updated by Peter Amstutz over 4 years ago

  • Description updated (diff)

#5 Updated by Peter Amstutz over 4 years ago

  • Description updated (diff)

#6 Updated by Peter Amstutz over 4 years ago

  • Description updated (diff)

#7 Updated by Peter Amstutz over 4 years ago

  • Description updated (diff)

#8 Updated by Tom Clegg over 4 years ago

  • Subject changed from [API] Potential CSRF vulnerability to [Workbench] Prevent CSRF and XSS attacks
  • Description updated (diff)

(moved out of story description)

Proposed alternative to providing the API token in a meta element:

Preferably we don't have to share the whole session, but use some other header instead that has the encrypted API token. This still requires a shared secret between services. We also need to generate and verify the encrypted token in such a way that it can't be trivially re-used in a replay attack.

(But [how] can an encryption layer make it impossible for a malicious embedded script to make use of the token, without also making it impossible for Workbench's own scripts to use it? -TC)

#9 Updated by Tom Clegg over 4 years ago

  • Story points set to 1.0

#10 Updated by Tom Clegg over 4 years ago

  • Subject changed from [Workbench] Prevent CSRF and XSS attacks to [DRAFT] [Workbench] Prevent CSRF and XSS attacks

Also available in: Atom PDF