Re: Apache2::AuthCookieDBI, Mason, and protecting against Cross-Site Request Forgery (CSRF)

[tinita]

The principle is always the same: if a http request can be forged by a different website, and the user is authenticated by cookie, you cannot know if the user made the request theirselves. So you have to put an additional parameter into the form (or query string) with which you can check that the user is really authenticated. Something that the attacker website cannot know. So you can simply use the session id and let the backend compare cookie and form parameter; or if you want to avoid putting the session id into the HTML, create an extra token for the user and save it in the database. Additionally you should change the token regularly.
I don't know if any of the frameworks has automated support for this. You need an easy way to put the token parameter into every HTML form, and an easy method to check the token on every form submit, that's all.

[Anonymous Monk]

"I don't know if any of the frameworks has automated support for this. You need an easy way to put the token parameter into every HTML form, and an easy method to check the token on every form submit, that's all."

Yes, and that's exactly what I'm seeking wisdom on. I guess I didn't make that clear? My apologies. But thanks for the advice!

[tinita]

Like I said, it depends on the method you choose, and it's difficult to implement something generic because it depends on that.
In my framework all requests go through a process of user authentification. Simplified, the user token in the database is checked and updated if it is too old. (I actually have two tokens which overlap.) If you are using Apache::AuthTicket you could add the code to a class that inherits from it.
In the template where I have form to be protected I just add the token into a hidden field with
[%= .user.token.hidden escape=0 %] which gives me the html for the hidden field.
Wherever a request is made that requires a valid token I simply write:
$framework->require_token;
which automatically throws an exception if the token parameter is invalid, which is caught by the framework and a short error message is displayed. Since I have two overlapping tokens this should never happen except somebody has an open form and presses submit after a long time (12 hours for example).

So for each request/form that needs to be protected there is only one line to be added per template and perl code.
You can even put the require_token call into the framework code before the actual method is called; do this for every post request. (and in the actual code also check for post; this should be done anyway).
but I'm not sure if this is a good idea. Then you have to add the token to every post form, even if a valid token is not needed. Or you do it the other way round and explicitly define which requests don't need a check. This way it cannot be forgotten when adding new code.