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

[Anonymous Monk]

I've been tasked with updating a website that was developed in 2003-2004 before Cross-Site Request Forgery (CSRF or XSRF) was really well known to be an issue. The system is currently built on mod_perl2 and HTML::Mason (Mason 1, not 2), and it uses Apache2::AuthCookieDBI for user authentication. I'm sure it was state-of-the-art back in 2003-2004, but the basic building blocks haven't been updated since then. A recent security audit revealed that most of this site's CGIs are vulnerable to CSRF, and I need to fix it.

Switching to a completely different framework/middleware like CGI::Application, Dancer, Catalyst, or Plack would take too much effort, I think. And everyone is happy with how the site works currently, so avoiding any user-visible changes would be preferable.

So what's the best way to incorporate CSRF protection into a site that uses mod_perl, Mason, and Apache2::AuthCookieDBI (or Apache::AuthCookie in general)? Has anyone done anything like this?

MasonX::Request::WithApacheSession looks promising, but Apache::Session doesn't appear to be updated as frequently as CGI::Session or as well regarded, I think. There's also Apache::SessionManager, but it hasn't been updated since 2004. A lot of these modules seem to overlap conceptually with Apache::AuthCookie. It appears I'd be almost generating two session IDs if I go with one of these approaches in addition to using Apache::AuthCookieDBI. Can I reuse the AuthCookieDBI ticket as the session ID with any of these modules?

Or should I just roll my own class to generate a random, one-time-use-only, expirable token, stick it in just the forms that have consequences as a hidden parameter, and store the token in the server-side database? I don't want to reinvent the wheel, but there is similar code already in this project for handling password resets which I could potentially generalize and refactor, so I'm very tempted to go this route. The problem with that is that it's not a comprehensive solution, so it would require identification and modification of the vulnerable forms that modify the database and there's always the possibility I could miss a form. Even if I don't, some future web developer might add a new form without thinking it through.

Thanks for any advice!

[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.

[Anonymous Monk]

Well, AFAIK, cookies don't protect against CSRF

[Anonymous Monk]

Yes, I know. That's why the site is vulnerable.