6

I intend to build a front end site entirely in javascript (NodeJS) and i would like to do ajax calls to a REST WS which is on another domain on client side.

I intend to use oauth2 and SSL to secure my REST back end, perform the access token asking on front end server side, but as i want to be able to do ajax calls, i have to use the obtained access token on client side.

My question is : what is the dangers to use a short-lived access token on client side in order to perform cross domain ajax calls ? Isn't it as secure as using cookies ? I know that passing by a proxy should be more secure but is it really worth ?

Thanks a lot.

rico
  • 361
  • 3
  • 8

2 Answers2

4

With any API over HTTP you have to worry about Cross-Site Request Forgery attacks. JSON+REST CSRF is possible. This isn't taking JSONP or CORS into consideration because the request isn't being performed with an XHR.

Enabling CORS causes huge problems trying to protect your API. CORS in effect revokes your rights to protect your website with the Same Origin Policy, it is very similar to having an XSS vulnerability on your website.

A really good method of preventing CSRF is including a random token with each request. Unfortunately this isn't very RESTful, but it is secure. In some cases an attacker maybe able to obtain this CSRF token by abusing JSON(http://jeremiahgrossman.blogspot.com/2007/01/gmail-xsrf-json-call-back-hackery.html), and there are ways of preventing this. If you are serving this token with a CORS enabled REST api, then there is no way to prevent an attacker from obtaining this token, and there for you cannot prevent CSRF.

Community
  • 1
Mikey
  • 355
  • 1
  • 6
3

If I understand your question, your proposed approach is fine, as long as all connections are over HTTPS. There is nothing wrong with including a short-lived access token in the request to demonstrate that the request is part of an authenticated session. It is basically isomorphic to use of a session cookie to prove that a request is part of an established session.

There are some cautions you should beware of. You should only attach the access token to requests you have constructed entirely on your own; otherwise, CSRF attacks become possible. If you are using a web client, then including the access token in the URL parameters is less than ideal: URL parameters are often logged on the server side, and may be disclosed in the Referer header. It is better to send the access token in a hidden form parameter included in the POST data. (Cookies avoid these problems, because they are not sent in the URL parameter, though they introduce their own risks, especially CSRF.)

D.W.
  • 98,420
  • 30
  • 267
  • 572
  • Thanks for the good response. But what do you mean by "you should only attack the access token to requests you have constructed entirely on your own" ? What i intend to do is for example use jQuery ajax method and send an authorization header with the access token value. Is this approach fine ? – rico Apr 11 '12 at 11:48
  • Sorry, @rico, that was horribly unclear! My fault. (I meant "attach", not "attack".) Here's the risk. Suppose you receive an arbitrary URL from some untrusted source, attach the access token, and send it to the server. You've just created a [confused deputy](https://en.wikipedia.org/wiki/Confused_Deputy) vulnerability; the untrusted source can trick you into authorizing actions on the server. There may also be risks if part of the URL is built from an untrusted source and other parts are taken from trusted sources. So: be careful about only attaching the token to requests you approve of. – D.W. Apr 12 '12 at 02:21