Preventing CSRF/XSS on mobile/web shared API

Question

I have inherited a code-base that includes a mobile & web app that both access the same API and have been tasked with fixing some of the security holes that exist, unfortunately I am not well-versed in the subject. Now I understand that the vulnerabilities I am looking at apply to web only but I would like to minimize the changes required on the mobile end, and since this service involves both I am looking for situational advice.

Both web & mobile receive an access token stored in a secure cookie which they use to access the API. This works perfectly fine for the mobile side but is open to CSRF on the web. Using the SOP and our CORS policy we are able to disallow other origins from reading data but of course they can still make changes to the server (ie. delete, update).

One solution that had been brought up is to switch to storing the access token in web storage so that we will not be vulnerable to CSRF attacks (because they are domain locked). This would of course open us up to XSS vulnerabilities but to the best of our knowledge the web app is safe in that regard (all user inputs are sanitized and validated, and no user input is directly outputted to the DOM). But, I have been told (unable to find references) that browser plugins can inject code into the DOM and would have free access to those storage values making our security essentially moot.

Another solution would be to use one of the solutions outlined in the CSRF cheat sheet but would require extra state on the server and re-write of how the mobile clients handle their cookies and requests and is not ideal.

So a better solution following above would be to separate the web & mobile APIs to allow the CSRF vulnerability solutions without having the make adjustments to the mobile apps.

So I am curious what you would suggest would be the best solution to this problem, or perhaps I am missing something that could be a simpler solution (for example CSP, I am not sure if that would be able to prevent certain XSS holes?).

Answer 1

I think your best solution would be to move the access token from a cookie to local storage. It's simple and efficient.

So what about the concerns you raise? You are right that this exposes the token to XSS. But if you do have XSS vulnerabilities, it's effectively game over anyway. The HttpOnly flag is an annoyance to an attacker, it's not a solid defence. I would not pick a more complicated design just to be able to keep the token away from JS. Instead, spend the time you save on hunting down actual XSS vulnerabilities!

As for malicious browser plugins, there is no way you can defend against them no matter where you store your tokens. If the client is infected with malware, you have already lost. So from the perspective of an API developer, there is no point in even trying to defend against this scenario. Your users need to keep their machines clean; if they fail at that there is nothing you can do for them.

Splitting the API gives your more maintainance work in the future, and sort of negates the whole benefit with having an API. To me, it smells like an ugly emergency solution that I would stay away from.

Finally, a strict CSP is always a good idea. It's not a silver bullet, but it sure helps a lot.