Re: Replay attacks with cookie session

Preston Lee
2007-03-21T22:08:22Z

I''m neither a Rails nor cryptography expert, but the threat of
session hijacking is a very important issue, and due to compliance
requirements such as SOX, sites must think even more seriously about
what is being stored in sessions and cookies, and take reasonable
measures to protect them.. preferably by default.

I''m saddened that many recent Rails books don''t seem to cover
this
issue. If the problem had more clarity and direction I think that''d
go a long way to easing enterprises into the Rails community.

Preston


On Mar 21, 2007, at 2:26 PM, Jeremy Kemper wrote:

>
> On 3/21/07, S. Robert James <srobertjames@gmail.com> wrote:
>> IMO, we need to rethink moving to cookie sessions by default, then -
>> if a core member hadn''t thought about, what can we expect from
>> beginners? Last thing we need is a reputation for being weak in
>> security.
>
> I think that''s a bit sensational.  The cookie store has gone
through a
> couple of evolutionary steps already and is ready for more, if need
> be.
>
>
>> Before everyone responds: "It will help performance, and good
>> developers don''t store volatile data in the session,
anyway!" I''ll
>> say
>> that we''ve seen lots of companies (who won''t be
named) sacrifice
>> security in order to gain out of the box performance or ease of use -
>> and it comes back to haunt them.  Secure by default, and let the
>> advanced users make it less secure to improve performance - not the
>> other way around.
>
> Let''s see a brainstorm of solutions and other potential
> vulnerabilities.
>
>
>>>> This is normally solved using something called nonce - each
signing
>>>> includes a once only code, and the signer keeps track of all of
the
>>>> codes, and rejects any message with the code repeated.
>>
>>> This sounds like something you could perform at the application
>>> level.
>> I don''t think so - as long as step 2 (in my example) goes to
one
>> Mongrel, and step 4 goes to another, the attack succeeds.  I can try
>> repeatedly with a script until this happens.  The only way to protect
>> is to use a shared backend like the DB or DRB - but then
you''ve lost
>> the point of cookie sessions.
>
> To some degree. I''m sure there''s more to this, though.
I''m not a
> crypto expert.
>
> jeremy
>
> >