1

I wonder, why Tapestry's hmac funcionality is not enough to prevent Cross-Site-Request-Forgery.

Tapestry encodes serialized objects into Base64 encoded strings that are stored on the client; primarily, this is for form submissions, to encode the set of operations needed to process the form when it is submitted.

(quoted jira issue)

The tapestry framework (version 5.3.6 and newer) signs the above data using hmac. When the form is submitted by the client, this data is included in the POST request in a t:formdata parameter and validated by the server. From my point of view, this is enough to protect against crsf. The signed data is created on the server with a key, that only the server knows. How should an attacker create a valid t:formdata Element which is accepted by the server? I'm confused because I found several libraries/implementations on the internet, which add csrf-protection to tapestry. I also read this SO-answer which states, that hmac "might" (or might not?) be sufficient csrf protection.

Concluding: In which cases does the hmac not provide sufficient protection against csrf and why?

Community
  • 1
  • 1
Fabian Braun
  • 3,612
  • 1
  • 27
  • 44

1 Answers1

0

The HMAC only applies to portions of the submitted form data, the part that Tapestry will de-serialized into Java objects. That was, in theory, enough for an attacker to compromise the server JVM (though not, necessarily, to be able to inject code or behavior into the application). With HMAC enabled, the submitted form data is secure, for as long as the HMAC is kept secret on the server.