On Mar 21, 3:28 pm, "Jeremy Kemper" <[EMAIL PROTECTED]> wrote:
> On 3/21/07, S. Robert James <[EMAIL PROTECTED]> wrote:
>
> > I'm concerned about the possibility of replay attacks with cookie
> > sessions. This is a standard security issue.
> Interesting, I hadn't considered that scenario.
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.
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.
>
> > 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.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
