Bug #4690
Updated by Tom Clegg over 9 years ago
A CSRF or XSS attack could enable an attacker is Cross-site Request Forgery. We want to obtain or use secret tokens. avoid leaking the API token to a 3rd party. h3. 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 session. * A CSRF token and API token.[1] That script can read the tokens from the DOM, use the tokens or XSS attack could enable an attacker to make API requests, and send the tokens session and api token to a 3rd party server of under the attacker's choice. control which will happily provide the proper CORS headers to accept the user's credentials. * Workbench's _session_ For the session, this probably isn't a problem because the session cookie 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_ However, for websockets right now, and presumably for future API and keepproxy access, we are currently provide providing the unencrypted API token in a @meta@ element, as a way the clear: <meta name="arv-websocket-url" content="wss://ws.qr1hi.arvadosapi.com/websocket?api_token=xxxxx"> * If we want to enable send the Workbench client code encrypted Rails 4 session to make API (REST and websocket) and Keep requests. (The crux here seems server, we may be able to be: it should be possible provide a custom session Rack layer that handles Rails 4 sessions for Workbench's _own_ scripts our Rails 3 site: https://stackoverflow.com/questions/1941499/given-the-session-key-and-secret-how-can-we-decrypt-rails-cookies * To send to make arbitrary API/keepproxy requests, but impossible for a malicious script injected keepproxy, we can decrypt it in a Workbench page to do Go: http://big-elephants.com/2014-01/handling-rails-4-sessions-with-go/ * This requires the same thing.) Rails @secret_token@ be shared between Workbench, API and keepproxy CSRF: User visits attacker's web site. A script or image tag there causes user's browser Preferably we don't have to make Workbench requests which are (a) permitted because share the user whole session, but use some other header instead that has active session cookies, the encrypted API token. This still requires a shared secret between services. We also need to generate and (b) not prohibited by verify the browser's CORS policy. * Rails provides some CSRF protection using its own encrypted token system. * API server does not use session cookies for most routes (but in such a way that it does use them during login). * Other services (keepstore, keepproxy) do not use session cookies at all. can't be trivially re-used in a replay attack. fn1. 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).