A session is shared between multiple browser tabs so this shouldn't be a problem. If the user opens a new tab/browser in incognito mode, then the browser will ask them to login in again b/c it can't read their session to authenticate their identity, and then when they login they will have two separate sessions going, each with a unique token/timestamp so multiple sessions isn't a problem either.

My bad, I thought the timestamp was being inserted into a form ala Rails' authenticity_token method in a way that would allow it to go stale if a new request was submitted in a new tab.

Although this makes sense, I feel it is not as safe as double submitting cookies, which effectively creates pseudo-random requests, but should still be safe enough in practice.

If you double submit on each request, this will double the number of requests on your server and reduce your server's capacity. And isn't all JavaScript subject to being subverted in XSS attacks, thus potentially rendering it ineffective?

In double cookie submission, you are not issuing two requests to the server, but rather using javascript to append the session id to either the post body or the URI.

Since the browser automatically submits the cookie via HTTP Headers, single submission by itself is not safe. Since a third party cannot read the value of the cookie, they cannot recreate the proper request and will, consequently, fail.

Of course, both our methods will fail under an XSS, but should still prevent CSRF. I still think a cryptographically generated secret stored in the cookie is less guessable than a timestamp.

The timestamp, session_id and user_id are tucked away in an AES encrypted bundle with a SHA-1 signature.