Project

General

Profile

Bug #4690

Updated by Peter Amstutz over 9 years ago

CSRF is Cross-site Request Forgery. request forgery (CSRF).    We want to avoid leaking the API token to a 3rd party. 

 * Right now, after log in, the token gets stored in the session. 
 * A CSRF or XSS attack could enable an attacker to send the session and api token to a 3rd party server under the attacker's control which will happily provide the proper CORS headers to accept the user's credentials. 
 * 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!). 
 * However, for websockets, and presumably for API and keepproxy access, we are currently providing the API token in the clear: 
 <meta name="arv-websocket-url" content="wss://ws.qr1hi.arvadosapi.com/websocket?api_token=xxxxx"> 
 * If we want to send the encrypted Rails 4 session to API server, we may be able to provide a custom session Rack layer that handles Rails 4 sessions for our Rails 3 site: https://stackoverflow.com/questions/1941499/given-the-session-key-and-secret-how-can-we-decrypt-rails-cookies 
 * To send to keepproxy, we can decrypt it in Go: http://big-elephants.com/2014-01/handling-rails-4-sessions-with-go/  
 * This requires the Rails @secret_token@ be shared between Workbench, API and keepproxy 

 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. 

 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>; if notextile is disabled, then by exploiting inevitable bugs in the markup engine). 

Back