[cgiapp] CAP::Security::CSRF -- useful?

[Mark Rajcok]

A possible solution:  the postrun callback for ProtectCSRF runmodes could be
enhanced to detect that ValidateRM was used, and there were errors on the
form. Something like this:

    if($self->can('dfv_results')) {  # hmm, using CAP::ValidateRM
        my $r = $self->dfv_results;
        if($r->has_missing or $r->has_invalid) {
            #  the form has errors, assume we need to generate an new CSRF
token:
            # ... code here to generate a new token and add it to the HTML
...

I'm not sure if a new token should be generated, or the existing one should
be (re)used.  At a minimum, the hidden field with the token needs to be
added to the HTML again.

For CA apps that don't use ValidateRM, we could add a new method to
CAP::ProtectCSRF that would set some kind of flag so that the postrun
callback would know to generate a token and add it to the HTML. The app
developer would have to remember to call it though -- it wouldn't happen
behind the scenes like above. Something like this:

sub create_check : Runmode :ProtectCSRF {
    my $self = shift;
    # check the form without using my ValidateRM
    $self->add_csrf_id_to_html();
    # and maybe $self->generate_csrf_token();
    # ... code to re-generate the original form with errors ...
}  <--- the postrun callback/hook would do the real work, if the flag was
set

Comments?
-- Mark

On Thu, Dec 3, 2009 at 1:16 AM, Mark Rajcok <mrajcok at gmail.com> wrote:

> Anyone see a solution to this problem?  (other than abandoning attribute
> handlers and requiring functions like create() above to explicitly call
> _publish_csrf_id() and _add_csrf_id())
>