Ruby on Rails: The authenticity_token can be reversed and used to forge valid per_form_csrf_tokens for arbitrary routes

When per_form_csrf_tokens is set to true, each form should protected against CSRF with a unique token that is not predictable by an attacker. Theper_form_csrf_token is generated using a HMAC SHA-256 using a key that is exposed in a reversed authenticity_token. The authenticity_token is a Base64 encoding of

one_time_pad | (one_time_pad XOR session[:csrf_token])

Because the one_time_pad is the first half of the authenticity_token, it is not secret and an attacker can reverse the token to learn session[:csrf_token].

From there the attacker can forge a hash for an arbitrary route (e.g. /articles/2):
HMAC ( session[:csrf_token], "/articles/2#patch")

To reproduce:

1. Have two Rails routes that accept only per form csrf tokens
2. Validate that the authenticity_token sent in the POST data returns an HTTP 422 when sent in the other form
3. Forge a per form token with the attached exploit script
   • the authenticity_token parameter is taken from the <meta> tag in the header of any page for the session
   • the route parameter is the action of the target HTML form (e.g /articles/2)
   • the method parameter is the value from _method parameter sent in the POST data (e.g. patch)
4. Take the forged token from the exploit script, URL-encode it, and send it as the authenticity_token in the POST data. For reliability, ensure that:
   • the route parameter matches the endpoint,
   • the _method parameter in the POST data matches what used for method in the exploit script
   • the forged authenticity_token in the POST data is properly URL-encoded

Impact

Exploitation allow an attacker to forge valid per-form CSRF tokens even in hardened situations where the global authenticity_token itself is not allowed.

For the attack to be successful, an attacker would need a valid global authenticity_token. This can be extracted out of a web page without any protections that cookies have (such as HTTP-Only). An attacker could leverage an XSS vulnerability to bypass per-form CSRF on unrelated pages. Because the token can be forged for any form, code execution on a page without forms could still lead to attackers bypassing CSRF protections of forms related to password changes, deletion of data, creation of new users, etc.