CODEWITHSUNDEEP
csrfcsrf-tokensubtlecrypto
Gregory Magarshak
Gregory Magarshak

Reputation: 2209

Do we need CSRF mitigation anymore?

In the past, we needed to mitigate CSRF attacks, in ways described by this OWASP cheatsheet:

  1. Nonce that's stored in session. But this requires storing the nonce in the session data on the server.
  2. The alternative OWASP recommends is "signed double-submit cookies".
  3. I recommend to simply have the nonce itself be the HMAC of the sessionId, using a secret that's stored on the server. Thus, the server can easily verify the request, without having to store additional information in the session.

But regardless, now since SubtleCrypto is available in all browsers for a while now, the server can simply require signing requests in the browser using Javascript (e.g. using elliptic-curve-based non-extractable private keys, or any other type of asymmetric key). And in that case, we no longer use the session cookie as a bearer token.

My question is - if the server starts requiring signing using Javascript, wouldn't that completely remove the need for CSRF techniques like 1, 2, 3 above? After all, the only way a cross-site request is getting accepted by the server, is if the top-level domain loaded some Javascript, and thus got access to the non-extractable private keys, allowing it to sign requests. It also seems much more secure than relying on sessionId alone as a bearer token, because intercepting that token doesn't allow an attacker to sign any requests.

Upvotes: 0

Views: 37

Answers (0)

Related Questions