On Mar 22, 2007, at 8:52 AM, Alexey Verkhovsky wrote: > On 3/22/07, Thijs van der Vossen <[EMAIL PROTECTED]> wrote: > As long as you only use the session to maintain the id of the > authenticated user and for flash messages there's absolutely nothing > to worry about. > > Sure, but... > > Not everybody who develops web apps knows about "do not keep > anything interesting in sessions" mantra, or agrees with it. At > least a couple of times I had to explain it to people who were not > clueless by any standard. > > It's actually a rather arcane bit of knowledge, and if you don't > have it, you may discover it the hard way, when it's too late. > > Which makes session storage in cookies a good option, but perhaps > not a good default (?) >
For those just tuning in... :-) This is the crux of the issue... of *course* it's a terrible idea to store sensitive or transient data in the session, but the question is one of API design. Do we want the penalty for ignoring best practices to be compromised security? I happen to think it's not a huge deal if we document properly. Web developers need to understand all of the abstractions that Rails builds on top of HTTP in order to build a secure web app. It's the same issue as people who throw things like <input type="hidden" name="order[total_price]" value="1250.00" /> into their online stores. If you don't understand how the Web works, you won't build secure applications, no matter what framework you work within. When PStore was the default, professional developers understood what that meant and what freedoms and limitations it afforded us. Now that CookieStore is the default session store, we are responsible for understanding what that means. Don't get me wrong; the Rails team has a part to play in this -- documentation. To the extent that we give the impression that the session is a "big hash in the sky", people will put stupid things in it. After writing this and thinking about it, I realize that authentication may be a problem. It makes me slightly uncomfortable to hand the client a token saying, in effect, "I am logged in as Joe User" with no qualifications, signed by the server. And that token never expires on the server side -- you could come back 5 years later and prove your identity. There is no way to selectively expire sessions, e.g. based on time. You can change the secret, but that expires all sessions including current ones. You can send the client a new cookie that invalidates the old one -- but he can always ignore it. He still has the valid authentication cookie from earlier, and it will still work. I would feel a lot better about it if it incorporated a nonce or some other form of time-variant information. I can't come up with an attack other than the replay attack, but that "I am logged in as Joe User" message seems too general to make me feel completely comfortable about authentication via cookie sessions for the time being. Brad --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
