7

I currently have a simple backbone.js application served from my domain (example.com), which is provided an Oauth token. Specifically, I pass the Oauth token through my page template into the constructor arguments of my javascript class (Backbone model). The backbone.js application (running in browser) then uses the Oauth token to talk directly to a remote server (not the same server from which the page was served).

Is it safe to provide the javascript code the Oauth token like this?

The entire page is served via https, so there is effectively no concern about MITM attacks. The browser also has a cookie with the users sessionid in it, so I don't think that's much different than providing the browser javascript with the Oauth token.

If this is terrible, are there any alternative methods that could be employed? Would storing the Oauth token in a cookie be any better? (same security implications as having a sessionid stored in a cookie).

Improve this question
2
  • 1
    By far the most important piece of information is missing, which makes this 100% unanswerable. WHO IS ISSUING THE OAUTH TOKEN? Is this an oauth-bearer token that you issue? Or is this an oauth token to some 3rd party resource?
    – rook
    Nov 23, 2013 at 4:57
  • @Rook Apologies. The token is being issued by an application that I own/maintain on a server which I control.
    – DJSunny
    Nov 23, 2013 at 19:02

1 Answer 1

Reset to default
8

An OAuth bearer token is a way of maintaining a session state used to hold an authenticated state - and like a password it must be protected. In the case of a backbone.js client an attacker could obtain this value using xss. Storing the oauth token as a cookie allows for the use of the httponly flag which prevents an xss payload from reading this value. even if the oauth token is protected with an httponly cookie, xss can still be used to access the authenticated api with a specially crafted JavaScript payload. A cookie is better than other methods, however xss and csrf are still major concerns.

Improve this answer
11
  • Thanks for your reply. Are xss and csrf (in this case) any worse then they would have been, given that a session already existed with a session cookie? I feel like the methods of attack remain the same, with a slightly larger surface area (e.g. the Bearer token in addition to the Session cookie).
    – DJSunny
    Nov 24, 2013 at 20:27
  • Also, do you think HTTPOnly would be applicable in this situation? If the client side code (Backbone app) is making the request, and HTTPOnly is set, this means the Backbone app doesn't have access to the Bearer token, and can't make a request. The domain the request is being made to from the backbone is different than the domain from which the page / javascript is being served from.
    – DJSunny
    Nov 24, 2013 at 20:31
  • 1
    @csjohn The point of HTTPOnly is that JavaScript cannot access the value, which means an XSS payload is unable to perform this action. backbone.js doesn't need the value, the browser will automatically include the cookies with all requests (which is one reason why CSRF is a problem). HTTPOnly is useful in protecting any authentication token, including an OAuth token. Its still better to force the attacker to use perform actions using a resident XSS payload, then to allow the attacker to hijack this token thereby controlling the session completely.
    – rook
    Nov 25, 2013 at 1:05
  • But if my client-side javascript is being served from SiteA.com, and the request from the javascript (which needs the Bearer token) is to SideB.com, doesn't that mean that the cookie option (and thus HTTPOnly) isn't viable (different domains)?
    – DJSunny
    Nov 25, 2013 at 1:19
  • @csjohn the cookie could be set on another domain in a redirect or by opening an iframe.
    – rook
    Nov 25, 2013 at 4:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .