Hi James, The general point about not unduly duplicating functionality is well taken, however, here are the reasons for the choices I made.
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. 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. 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. 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. 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". 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. 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. Brendan On Saturday, May 17, 2014 1:04:09 PM UTC-4, James Reeves wrote: > > Hi Brendan, > > This sort of work is very much appreciated, but since this involves > security, I hope you won't mind if I make a few criticisms. > > When dealing with security, it's extremely important that you don't > re-implement existing functionality without good reason. A large part of > avoiding security flaws is minimising the surface area of code exposed to > attackers. > > In your library, you re-implement a lot of the functionality that already > exists in the standard Ring session middleware. There's no reason for this. > You could implement all the functionality in :auth-session as middleware > that sits on top of the standard Ring middleware. > > You have a :csrf-token option for wrap-auth-session, but you do nothing > with it. Hopefully you won't implement your own anti-CSRF middleware, but > instead use the standard ring-anti-forgery library. > > A lot of the functionality of your code could be boiled down to: > > (defn wrap-secure-sessions [handler] > (fn [request] > (if (and (:session request) (insecure-session? request)) > (-> request request-url redirect (assoc :session nil)) > (handler response)))) > > > Where the "insecure-session?" function makes a decision as to whether the > session is too old, or has been accessed over HTTP rather than HTTPS. > > However, all this is a moot point, as there are better ways of achieving > the same functionality. > > The session store itself should be expiring sessions, rather than the > session middleware, as the middleware can only expire sessions it's > currently being accessed by. If you rely on middleware to expire sessions > as they come in, you'll build up a backlog of sessions from visitors who > will never return to your site. > > For HTTPS sessions, the "Secure" flag should be set on the session > cookies, which means that the browser will never send the cookie over HTTP, > therefore making it unnecessary to delete sessions over insecure > connections. Ideally you want both :secure and :http-only to ensure that > the cookie is only delivered to your server over a secure connection. > > - James > > > On 17 May 2014 17:18, Brendan Younger <brendan...@gmail.com > <javascript:>>wrote: > >> Hi all, >> >> In light of Aaron Bedra's >> talk<https://www.youtube.com/watch?v=CBL59w7fXw4&list=PLZdCLR02grLp__wRg5OTavVj4wefg69hM&index=6>at >> Clojure/West this past March on the (lack of) security in Clojure >> webapps, I've written a small, easy-to-understand middleware for keeping >> your authenticated session secure. >> >> Ring-auth aims to implement all the recommendations from OWASP about >> secure session storage while at the same time not putting undue constraints >> on how you architect your app. Just place authentication information in an >> :auth-session key in your ring responses and you're all set. >> >> Check it out at: https://github.com/brendanyounger/ring-auth >> >> Brendan Younger >> >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com<javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> 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+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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.
