[Catalyst] Re: CSRF (plus session security)

Bill Moseley moseley at hank.org
Wed Oct 1 19:37:02 BST 2008


On Wed, Oct 01, 2008 at 12:20:04PM +0200, Aristotle Pagaltzis wrote:
> * Moritz Onken <onken at houseofdesign.de> [2008-10-01 09:25]:
> > The best way is to include a random string which has to be
> > stored somewhere for comparison on the server side.
> 
> Doesn’t have to be stored. Send a random string as well as a HMAC
> digest of a server secret plus the same string. To check a token,
> check if the random string plus server secret hash to the same
> digest as the one provided by the client. Since the server secret
> is not known or knowable to third parties, if the digest checks
> out, then this token must have been minted by the server. Very
> simple; near-zero CPU overhead; no server-side storage required.

Ya, but it's valid for multiple posts.  That might be ok, but in
general, I only want one post for every one form generation (and no
post without a form being generated).

So, my forms all have a unique token that can only be used once.  If
used a second time I redisplay the form pre-filled with their post and
ask them to submit again if that's what they really intended.  That
has the benefit of catching if the form is no longer valid (due to
changes in the database from the first post).

Of course, that doesn't prevent using two browser windows, etc. but it
helps.


Let me ask a related question:

Where on the risk spectrum is CSRF compared to, say, session
hijacking?

I have an application that went from having some pages SSL encrypted
to all pages encrypted for logged in users.

I would like to only use secure cookies, but I place things in the
session that I need for both SSL and non-SSL pages (an example is a
language selection that is stored in the session).[1]

Makes me think I need $c->session and also $c->secure_session as
separate sessions and separate cookies.


-- 
Bill Moseley
moseley at hank.org
Sent from my iMutt




More information about the Catalyst mailing list