Where should I generate CSRF form tokens and CAPTCHAs in an MVC application?

Question

Given:

I have created Hash and Captcha classes. Hash creates form tokens. Captcha uses a Graphics class to create an image. A custom session service wrapper class is used to handle the $_SESSION superglobal data structure.

Scenario:

I use a dependency injection container. Therefore, I want to know where to define the instantiation of Captcha and Hash for publicly accessible HTML forms.

Hypothesis 1: You should inject Hash and Captcha into a child of Model because accessing $_SESSION is required to store (upon HTTP request) and to validate (upon HTTP reponse) CSRF tokens and CAPTCHA answers. A view should never access session data structures.

Hypothesis 2: You should inject Hash and Captcha into a child of View because generating CSRF tokens and CAPTCHAs is actually part of a View's presentation logic, even though validation of them occurs in the Model. Accessing session data structures, directly or indirectly, from a View is permitted.

Hypothesis number one seems like the answer, but I want to be sure.

Abstract Example:

$session = new Session(); // A custom wrapper class
$hash = new Hash();
$graphics = new Graphics();
$captcha = new Captcha($graphics);


$model = new ContactModel($session, $hash, $captcha);

or

$view = new ContactView($session, $hash, $captcha);

Answer 1

_{Note #1: I think you should read through this post. I will emphasize a core part of this answer: "The model is not a class or any single object"}

_{Note #2: IMO this problem is something inherent to web MVC implementations. The first part is how I would go about this problem; the following describes conceptually why this problem exists.}

My answer is: neither.

The MVC architecture is divided into 2 layers: the model layer and the presentation layer. A service object (these reside within the model layer) should instantiate/save pertinent captcha information to the client state. Since this is likely a web application, the presentation layer -- specifically a view object -- will need to request this client state from the model layer. Whether this happens through a service object or a presentation-specific data access object specially-tailored for client state responses is dependent on your implementation & best fit. It is here, within the view, where I would save the client state to the session via another data access object or a (Cookie/Session)Response abstraction*. In this way, the view doesn't "access" the session data structure, but rather utilizes a component (the presentation-layer DAO or (Cookie/Session)Response abstraction*) to do this work. Though we don't think of cookies/sessions as presentation ("they aren't visual"), the presentation layer is responsible for responses, which cookies/sessions are nothing short of.

It is difficult for me to speculate how this would go in your framework specifically, since there seems to be a conflation of the model layer. Your ContactModel would certainly want the hash/captcha to save the client state. Your view would need neither of these, but an additional mechanism to "respond" the client state to the HTTP request in the form of a cookie/session.

_{* Symfony is generally helpful for this. I use both the presentation-layer DAO and a Symfony HttpFoundation object, which may be overboard.}

Conceptually: sessions as state vs. response

The fundamental problem you're tackling here is specific to web MVC implementations. Presentation layer in web MVC processes a "request" (delegated to the controller) and presents a "response" (decided upon by the view). In HTTP, cookies and sessions are sent with requests and altered in responses. This is embedded in the HTTP request/response nature.

If we put the session/cookie saving in the model layer, we are making our model layer dependent on HTTP and allowing it to "respond" to requests. Even if we abstract the superglobals and "inject" abstractions (like Symfony cookie/session objects), there is inherent dependence on cookies/sessions which are request/response implementations. You can do this all in the model layer, but I prefer not to. In other words, though the model is responsible for keeping track of states, the cookie/session state is actually a response to a request.

"But this is leaky logic since you are saving state in the presentation layer"

I think you can look at all methods as being somewhat "leaky" and this is just the most cohesive way. Sure we are "saving" state in presentation layer if you look at cookie/session as state. If you look at them as response, which they truly are in the eyes of MVC, then this is not leaky at all. I would argue that sending a response (saving the session/cookie state) in the model layer is worse.

Answer 2

Answer: You should generate CSRF tokens and CAPTCHA values in the "Model".

Reason: The purpose of these values is to serve as a constraint on your business logic, not simply to display values or controls in the "View". If the "View" generated form tokens and CAPTCHA challenge values, it would have to communicate them back to the "Model" (one way or another). This goes against the flow.

While hypothesis number two is feasible, it gives duties to the View that it does not complete in full. Specifically, a View would never be responsible for validating form tokens or CAPTCHA answers.

A View could, in a dummy like fashion, insert form tokens and CAPTCHA challenges into an HTML form template (for example). This is true, however now the "View" would be responsible for saving the answers to persistent storage of some kind, while the "Model" would only retrieve and validate them.

Thus, session storage would be acting like a backside channel between the "View" and the "Model", and therefore coupling them (even if using some kind of session service wrapper). The "View" should not be passing data do the "Model", but that is effectively what is happening if the "View" is allowed generate form tokens and CAPTCHA answer values.

That is my answer. I welcome your comments and criticisms.