On 3/23/07, Jeremy Evans <[EMAIL PROTECTED]> wrote: > On 3/23/07, Jeremy Kemper <[EMAIL PROTECTED]> wrote: > > Let's talk about practical fixes rather than whether we should write > > it off entirely.
... > > This requires one additional database query on logout to invalidate > > future reuse of that session and no additional per-request queries. > > This assumes you are doing a query per request anyway, and basically > piggy backing on it for the security. If your application is already > doing a query for the current user for every request, sure, there's > almost no additional cost. However, if your application isn't doing a > query per request, you have to add one to get the security, which > makes the cost the same as using the database for session storage. That assumption is stated at the beginning of the example: > > An application-level solution to user_id replay: You reason that touching the database "makes the cost the same as using the database for session storage" which is likely wrong and certainly unsubstantiated. Criticism is great and welcome, everyone, but let's add some creativity and code to the mix, please. > IMO, this is not a problem that the application developer should need > to deal with manually, any more than application developers should > handle database transactions manually. If cookie based session > storage is going to remain the default: We all agree on this. We're working on it. > 1) There should be a configurable timeout set automatically, with a > reasonable default (to partially mitigate the replay issue) > 2) It should be documented that replay attacks are still possible > 3) Advice on creating application specific solutions such as the one > you mentioned should be included in the documentation Good ideas. > Note that timeouts provide only slight additional security, as they > only protect against attackers who get access to a session cookie > after it has already expired. If an attacker gets access to any > session cookie before it expires, they can keep that session open > indefinitely. Not in the scenario above: the legitimate user logging out invalidates the attacker's session, which is the same behavior as a server-side session. jeremy --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
