Hi Cosimo,
Since I use CAP::Config::Simple, $self->config() won't work in my app. Your
comment caused me to go look at what other CSRF modules do.
CAP::ProtectCSRF does this:
my @words = ('A'..'Z', 'a'..'z', 0..9, '/', '.');
my $salt = join "", @words[ map { sprintf( "%d", rand(scalar @words) ) } 1..2 ];
my $csrf_id = sha1_hex($salt . time . $$ . rand(10000));
and a similar Catalyst module, Catalyst::Controller::RequestToken, does
this:
my $digest = _find_digest();
my $seed = join( time, rand(10000), $$, {} );
$digest->add($seed);
my $token = $digest->hexdigest;
I did modify my module to add some more randomness.
Thanks for the suggestion.
-- Mark
On Sun, Nov 29, 2009 at 8:46 AM, Cosimo Streppone <[email protected]>wrote:
> In the token generation, I would try to be less predictable,
> and inject a secret string coming from a config file, something like:
>
> my $token = sha1_base64( join '/',
> $self->config('csrf-seed'),
> $self->session->param('_SESSION_ID'),
> time
> );
>
> So even if you know that a specific app is made with CGI::Application
> and it uses CSRF protection, you have lower chances of
> predicting the exact sha1 hash that will be generated.
>
##### CGI::Application community mailing list ################
## ##
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ##
## ##
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
## ##
################################################################
