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 response, 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.

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.

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 response, 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 (but much less concise) description would be: CSRF defense based on out-of-band secrets.

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 response, 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.