What's a proper way to secure REST interface from session stealing?

Question

Let's suppose that attacker was able to inject JavaScript into website. Obviously he can do any HTTP request to backend mimicking user actions, unless there's some confirmation like SMS code which required direct interaction from user (even in this case malicious JavaScript could fool user). So, I guess, this attack vector couldn't be reasonably defended. But if attacker steals session, he can impersonate user and do almost anything. So I'm thinking about defense of this vector. Sure, server could check IP address, etc, but it's not always possible.

First thing: storing session in an HTTP-only cookie. JavaScript can't steal it. So far so good. But there's another weakness: 3-rd party website can craft form tag with action from my server and submit this form with user cookie. One could use CSRF tokens, but again they should be available to JavaScript, they could be stolen if JavaScript is compromised, they must be maintained on the webserver, which hurts scalability, etc. I'm thinking about using PUT method for every REST action (well, it won't be a proper REST obviously, let's call it HTTP API). There's no way to trick user into issuing PUT request from 3-rd party website and HTTP-only cookie will prevent stealing of cookie value.

I'm not seeing this usage, so I guess I'm missing something and there should be simpler way to secure endpoints?

Answer 1

I think you may be misunderstanding CSRF as a threat vector. A CSRF attack is one where the the attacker does not have access to the DOM, and is able to force the user's browser to submit a request which includes the user's authentication token. XSS is where the attacker is able to manipulate the DOM. If the attacker can manipulate the DOM, he can force the user to submit any requests, and it will include both HTTPOnly cookie values and any anti-CSRF tokens. Any CSRF mitigations put in place can be bypassed if an attacker can control the DOM (XSS).

Given this, the best implementation would include both an HTTPOnly authentication token and an anti-CSRF token which is accessible to JavaScript.

Also, anti-CSRF tokens can be implemented which do not need to be maintained server-side using HttpOnly cookies. You include a randomly generated token in an HTTPOnly cookie, and include the same token in a DOM-accessible fashion. When the client returns the request, include the anti-CSRF token as a header (or through a similar method.) Then, on the server, you validate that both the HTTPOnly token and header tokens match. A CSRF attack will submit the HTTPOnly token, but it cannot submit the the matching header token. An XSS attack will still be able to bypass this, but as we said above, anti-CSRF mitigations will not work if the attacker controls the DOM.