On 17 May 2014 20:04, Brendan Younger <brendan.youn...@gmail.com> wrote:
> > Having the ability to keep one insecure session (for anonymous users) and > one secure, authenticated session is very helpful. With the standard > ring.middleware.session, you are restricted to setting the HttpOnly and > Secure flags on the cookie all the time or never. This is why I added a > second :auth-session key. > You could just choose different wrap-session options depending on whether the user is authenticated or not. Middleware options don't need to be fixed at compile-time. > The :csrf-token is there on purpose since setting it on an insecure > session, as ring-anti-forgery does, doesn't prevent CSRF attacks since the > session identifier can still be fixed. In ring-auth, it's up to the > application to provide and check the :csrf-token on requests and responses, > which is not that hard to do. > I'm not sure I follow. Even over HTTP, it shouldn't be possible for an attacker to read anything in the session itself. Only the server can read session information. > Sessions can still be expired via the session store, but not all stores > make it easy to auto-expire them. Keeping invalidation code in the > middleware just provides some more defense in-depth. > If the session store doesn't have expiry mechanisms, then the session store is broken. > There are other niceties in ring-auth which are easy to elide when > focusing on your application logic. > > For instance, the session identifier for the :auth-session is always a > random UUID rather than allowing the session store to decide what it is. > This guards against session stores that might simply auto-increment the > session identifier and thus be easily guessable. > If the session key is easily guessable, then the session store is completely broken and needs to be immediately replaced. The problem is that you're adding code that only has benefit if another part of the system is broken in some major way. If the session store is not broken, all your code is doing is adding complexity for no benefit. Rather than use wrap-auth-session, it seems like a better idea just to check that the session store you're using is in working order. Every time the contents of :auth-session are altered, a new session > identifier is created. This guards against privilege escalation whereby > moving from "regular user" -> "admin" would allow a third party with access > to the "regular user" session identifier to now act as an "admin". > Middleware that clears the session if on changing privileges might be useful, but I'd suggest this be separate middleware. > Finally, the logging was placed there for specific reasons. If you see a > lot "Unknown auth-id" messages, it's likely that someone is trying to guess > the session identifiers. Likewise, seeing "Refusing to set auth session on > insecure request" means that your code is allowing HTTP on a route that > should probably be HTTPS-only and you should look into your routing logic. > I think it's helpful to have predictable mistakes called out like this. > Middleware that passively looks for signs of attack could be useful. Again, this seems more useful as separate middleware. > I do, of course, owe a great debt to yourself and other who have provided > so much of the plumbing in Ring and the associated libraries. However, > right now it's too hard to implement all the OWASP best practices for > session storage and CSRF protection and be sure that you didn't miss > something or misconfigure one of the middleware libraries. Ring-auth is > meant to eliminate the worry of inadequate configuration. > It's a laudable goal, but I really don't think your current middleware design achieves that. I'm usually not this critical, but when it comes to security it's important to get things right. Ring best practice for sessions is as follows: - Sessions over HTTPS should be flagged as Secure - If you really must have sessions over HTTP and HTTPS, they should be in different cookies - The session store should use unpredictable identifiers for keys - The session store should handle expiry of old sessions I'd welcome middleware that lints the session, i.e. makes sure your cookies are right. I'd also welcome more session stores that follow proper security. Middleware that passively looks for signs of brute force attacks and delivers warnings would be useful. But I don't think the ring-auth middleware takes the right approach. It's *maybe* better than nothing, but it doesn't follow best practice, and isn't something I could recommend using in its current state. There are some good ideas in there, but it's mixed in with functionality that has better existing solutions. - James -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
