Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
To protect against CSRF, couldn't my page javascript just dynamically insert the session id from the cookie into the body of each HTTP request right before it's sent?
The server would then just validate that (value received from cookie) == (value from request body)...
No because you should never allow scripts to be able to access your cookies. Refer to HTTPOnly on the OWASP website.
To prevent people from being able to steal session id's, should XSS be present, you should always set this cookie flag. Your mechanism would not work anymore as it would not be able to access the cookie.
Quoted from OWASP's CSRF Prevention page:
Double Submit Cookies
Double submitting cookies is defined as sending the session ID cookie in two different ways for every form request. First as a traditional header value, and again as a hidden form value. When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. This is typically referred to as the session ID. The site should require every form submission to include this pseudorandom value as a hidden form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can send any value he wants with the form, the attacker will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the session ID value.
While this approach is effective in mitigating the risk of cross-site request forgery, including authenticated session identifiers in HTTP parameters may increase the overall risk of session hijacking. Architects and developers must ensure that no network appliances or custom application code or modules explicitly log or otherwise disclose HTTP POST parameters. An attacker that is able to obtain access to repositories or channels that leak HTTP POST parameters will be able to replay the tokens and perform session hijacking attacks. Note, however, that transparently logging all HTTP POST parameters is a rare occurrence across network systems and web applications as doing so will expose significant sensitive data aside from session identifiers including passwords, credit card numbers, and or social security numbers. Inclusion of the session identifier within HTML can also be leveraged by cross-site scripting attacks to bypass HTTPOnly protections. Most modern browsers prevent client-side script from accessing HTTPOnly cookies. However, this protection is lost if HTTPOnly session identifiers are placed within HTML as client-side script can easily traverse and extract the identifier from the DOM. Developers are still encouraged to implement the synchronizer token pattern as described in this article.
No real reason not to just use the built-in CSRF prevention mechanism, almost all serious frameworks have this now.
You could, but it seems a bit unwieldy to me. Any CSRF-prevention mechanism works like this:
The tried-and-tested method is to use <input type=hidden> in the HTML fields that contains some anti-CSRF token. Your method works as well1, but using JS to intercept and inject POST requests sounds icky and unnecessary when the whole client-side logic can be contained in the HTML.
1 As TildalWave noted, puting sensitive data in non-httponly cookies and making the accessible to client side JS could be a problem if you have XSS vulnerabilities. Stick with the tried and tested method then.
httponly in cookie headers is to signal the client (browser) not to enable client side scripts access to these cookies (usually session cookies), so they're not exposed to XSS. By adding this session ID value to a form field, you're needlessly enabling access to it. It's just safer to assume you can't trust the client, and since there's no need to do it this way, I'd suggest not to.
May 14, 2013 at 10:47
As mentioned by a number people - double submit is an ok CSRF protection, provided that you use a separate nonce. Using session id is very wrong in this context, starting with the fact that sessionid has to be HTTPOnly for XSS protection.
An argument of "what if there is XSS on this page/website" is not valid - when you have XSS, CSRF is the least of your worries. The browser becomes fully remotely controllable via an injected script and CSRF is not required to force the browser to do actions on behalf of the user.
*Edit: what I propose below is apparently known as the double-submit cookie scheme. And, contrary to the original question, it is a separate nonce altogether as well (or even a simple hash of the session id)...
Looks like the simple solution (i.e., CSRF protection but with all-cacheable web resources) is to just add a separate cookie containing the anti-CSRF token but accessible to page javascript. And add this to all requests from the page (e.g., just before they're sent).
In other words, when the client logs in, I'll actually set two cookies (one HttpOnly sessionid and one nonp-HttpOnly anti-CSRF token, accessed by page scripts). So, the server will store (along with a client sessionid) their anti-CSRF token value and validate that it's the same value as the one originally set via the second cookie. If validation fails, you have a potential CSRF.
This approach is also mentioned in some other places on the web...
