Correct implementation of a "User interaction based CSRF defense" approach?

Question

OWASP CSRF Cheat sheet mentions the "User interaction based CSRF defense", which would also entirely mitigate a CSRF attack. I imagine that the reason OWASP considers it as a Defense-in-Depth (DiD) is because of the impact it has on UX.

I'm quite curious about the "One-time Token" implementation but fail to find any resource that goes more into detail here?

Personally, I would imagine that you generate a unique token for each critical action, associated with the user's specific session. The token can be sent to the user using different methods:

• via email
• as part of the API response to the initial request, which should then be submitted as an HTTP header value. Here, the user would then have to perform some interaction (e.g. Clicking a button) that would add the token to the header.

In both cases, attackers will be unable to read the valid token, preventing them from completing their attack. Specifically, with the "as part of the API response to the initial request", during a CSRF attack, an attacker can initiate requests, but not read their responses (thanks to SOP), which would be the key point here.

Answer 1

A sensible implementation would be to generate a unique token and send it by e-mail or SMS, or to use One-Time Passwords, be it HMAC-Based One-time Passwords (HOTP) or Time-based One-time Passwords (TOTP). The security benefit comes from the fact that the secret needed to perform the action is sent over a completely separate channel.

If you simply embed a token in a response and add it as a header (after the user has clicked on an extra(?) button), you do not get those benefits. This is actually nothing more than classical anti-CSRF tokens. When you receive a request with a token, it's impossible to tell whether the user has actually clicked on a button. You just get a token within a header. If an attacker knows the token and can set the header, they can do that without needing the user to click on anything. If the attacker doesn't know the token or cannot set the header, then making the user click something is superfluous. You might as well fill in the token automatically.

I'm not sure if “user interaction” is really the key point of the schemes described by the OWASP. Their title seems a bit misleading. If you send a one-time token per mail, and you receive that one-time token in a request, this does not prove user interaction. For example, if an attacker has access to the e-mail account and can set the token parameter in a request, they can perform a classical automated CSRF attack. There's nothing in the HTTP request that tells you whether any user interaction happened at all, let alone whether the legitimate user has triggered the action. The same is true for SMS, HOTP and TOTP. I think a more fitting description would be: CSRF defense based on out-of-band authentication.