10

I am working on an ASP.NET MVC web application, which fetches its data from an API in the back. So authentication is currently done via ASP.NET Forms Authentication, which means the client sends email and password to the website, the website transfers that data to the API which returns an authentication token, which is stored within an ASP.NET session. After that the auth cookie is set on the client.

That's okay and secure (from my current knowledge), no credentials nor the token is stored on the client side.

As a drawback, every AJAX request has to be routed trough the website. As a result, I have a large number of ASP.NET MVC actions, which don't do anything but forward the request to the API and return the result coming back from there.

That may be a bottle neck in the future, because the website infrastructure has to be scaled in the same way the api infrastructure has to be. Now I am looking for a solution to remove these redundant calls via website and go directly to the API from the client (via AJAX).

That requires API authentication from the client. That wouldn't be a problem, technically, if I store the authentication token in LocalStorage (old browsers are not supported).

But how secure is that approach? What options exist for stealing the token, next to JSONP (which can be prevented by not including external scripts, right?)?

asp_net
  • 233
  • 2
  • 6

1 Answers1

5

Since you'll be making calls to the API server via Ajax (meaning the same page - and the same JavaScript context - will be constant) I'd suggest creating a short lived token in the main server, having the browser request it once, then using it to authenticate with the API server until the page is closed (or the token expires, whichever happens first). Next time the user visits the page, generate a new token.

This way the calls to the main server will be infrequent (and you can't avoid them anyway, since every time the user logs out or clears the cookies he'll have to authenticate with the main site again), and you avoid the hassle of having to secure yet another piece of data.

As for Local Storage attack vectors, I believe in theory they're roughly the same as the ones related to cookies - XSS, physical access to the machine, etc - since it's subject to the Same Origin Policy (at least those created by a SSL protected page are), but contrary to cookies it does not support a restricted visibility by path (i.e. all pages in the domain can access data from any other page). In practice, however, there might be inconsistencies in the way it's implemented, as well as other security holes, so I wouldn't trust it unless I was highly confident it is secure (something I can not really assert with my current knowledge). According to this OWASP guide storing sensitive data in Local Storage is discouraged. SessionStorage is not bulletproof either.

mgibsonbr
  • 2,905
  • 2
  • 20
  • 35
  • Thanks, mgibsonbr. But how would you define the lifetime of the token? It may happen that the page lives for minutes or hours as all content is loaded via Ajax so the user has not to reload the page. And another thing: the visibility of cookies may be restricted by path, but in real life an authentication cookie must work on every single page, so mostly it isn't restricted either. But thanks for the links. – asp_net Apr 04 '13 at 18:45
  • @asp_net the lifetime is less important than the fact it's only stored in-memory, which is what reduces the attack surface. In case a breach happens (ex.: XSS), then the window the attacker will have to exploit it is determined by the token lifetime. Personally, I wouldn't worry too much about it, and set the lifetime to a reasonably high value (say, 1 day) to ensure convenience and performance. My gut feeling tells me most attackers wouldn't try to save the token for later use, but rather exploit it right away (so even a short lifetime is useless). But it may vary from case to case... – mgibsonbr Apr 04 '13 at 22:52