On 12/19/07, Jay Levitt <[EMAIL PROTECTED]> wrote: > > On Wed, 19 Dec 2007 11:14:03 -0800, Jeremy Kemper wrote: > > >> 4) Add, at least an option, to hash the IP address of the user into > >> the cookie's hash. This should prevent against replay attacks > >> automatically without the application developer having to write in > >> this check. > > I'm +1 on *anything* that prevents replay attacks (it's one of my big > peeves about CookieSessions in the first place), but I wonder about the > edge cases. > > If I'm coming through a proxy farm like AOL's, will I always come through > the same proxy during the same session? What about mobile users moving to > different cells - do their IPs stay constant? Or DHCP users on networks > with short leases? I recall reading (a few years ago) about cable > companies switching users' IP addresses frequently in a sort of > security-by-obscurity defense against botnet infections. > > In *theory*, there are a lot of legitimate reasons for a user's IP address > to change during a session, which would break this. But I have no idea if > any of those ways really happen with any significant frequency, so I'm > really not implying-by-asking - just asking.
Don't add checks by IP, you will break things. For example, I load balance my internet connection over a cable and DSL line at home, and connections from the same machine on my internal network can appear to come from either the cable IP or the DSL IP. This is on a fairly simple home setup. Large enterprises are sure to have proxy server architectures that don't guarantee that that all connections from the client A to server B go through the same proxy server. I'm not sure if it is possible to make CookieStore sessions invulnerable to replay attacks. Without some server controlled state, replay attacks should always be possible. This is similar to the impossibility of implementing completely secure DRM (it doesn't work because the user always has at least theoretical access to the encryption keys). The best you can do with a CookieStore is mitigate the replay attacks, and the best way to do that is probably an application configurable timeout. The timeout should preferably based on the start of the session and not the last access time, so no session can be used indefinately. The idea of using OpenSSL for the key is a good one (I used it manually to create my keys), but keep in mind that this won't work when OpenSSL isn't installed, so there needs to be a fallback method. --~--~---------~--~----~------------~-------~--~----~ 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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
