On 05/18/2014 09:25 AM, James Reeves wrote: > I don't want to seem like I'm "badgering" you. You have a lot of sound > ideas. But I don't think we should be trying to work around insecure > designs; we should be making it easier for people to design things > securely. > > In terms of /specific/ things wrong that I've yet to mention: the > middleware you have won't work for all session stores; only session > stores that create a new session if a key is not found. Ideally > session stores should reject session IDs that don't exist, rather than > construct new ones. > > - James
After reading this thread I would like to make a couple of quick points. I think that ring-auth is a step in the right direction and has the right end goals in mind. To cut past the tension a bit I think that what James is trying to say is "let's try to make this less confusing and work within the constraints of the current system". This really isn't a bad idea. In fact, it is usually the way to succeed as an add-on to a library. I understand all of the original points made by Brendan and agree with almost all of them. That being said, I would encourage a little more work here to try and blend just a bit more. I am happy to take this off list and start a more productive discussion on how with a smaller group if there's interest. - Aaron > > > > On 18 May 2014 14:06, Brendan Younger <[email protected] > <mailto:[email protected]>> wrote: > > > > On Saturday, May 17, 2014 9:03:01 PM UTC-4, James Reeves wrote: > > On 18 May 2014 00:09, Brendan Younger <[email protected]> > wrote: > > For anyone else following along at home, I'll just > re-iterate the benefits of using ring-auth versus trying > to write your routes /just right/ to avoid the myriad > security issues listed at OWASP. > > - If you initiate a session with a user over HTTP and > later on that user logs in over HTTPS but you don't change > the session id in the cookie, then everyone at the coffee > shop has access to the authenticated session. Ring-auth > protects you from this. > > > This is true, but I don't think we should be aiming to protect > people from doing the wrong thing, so much as stop them from > doing it in the first place. > > You seem to be aiming this middleware at people concerned > about security, but not so concerned as to follow best > practice. I'm a little baffled by this use-case. > > > On the contrary, I'm protecting the user from oversights or bugs > in the webapp. Saying that there would be no security issues if > only everyone wrote perfect software is a tautology. > > > > > - If you use a CSRF middleware, but at any time leak the > session id cookie over HTTP, then your CSRF protection is > broken. Ring-auth protects you from this. > > > CSRF protection doesn't matter if your session is compromised. > CSRF is a mechanism for sending a HTTP POST with the user's > session ID. If you already have the session ID, there's very > few reasons why you'd bother with CSRF. > > - If you ever send your CSRF token over HTTP, then the > entire coffee shop can entice the user to "Click here > now!" and send money to their off-shore account. > Ring-auth helps you avoid sending the CSRF token in the > clear. > > > Hm? How? There doesn't appear to be anything in your code that > looks for the CSRF token embedded in the response body. > > > Because the :csrf-token is only present in the :auth-session, you > can be sure that if your code has access to the :csrf-token, then > it's communicating over HTTPS with the user. I could not use > ring-anti-forgery here because there is no provision to place the > token in anything except :session. > > > - If you get a request over HTTP which should have gone > over HTTPS and respond with an error, but don't > immediately delete the session, then everyone at the > coffee shop has seen the authenticated session id > (assuming you forgot to set Secure). Ring-auth protects > you from this. > > > Again, I don't understand the use-case for this. Setting the > secure flag on the session cookie is the clearly the better > option. I'm having trouble seeing how you'd present this in > your project's README. > > > - If a user closes their browser on a public computer but > forgets to sign off, the next user can go back to the > site, and hopefully the browser has cached the cookie > giving them access to the first user's account. Ring-auth > will help prevent this as soon as the "Cache-Control" > header is set. > > > A session idle-timeout isn't necessarily a bad idea, though > again this could be implemented as middleware on top of the > existing session middleware. > > I'm not sure what bearing the Cache-Control header has in this > case. > > > The Cache-Control header instructs proxies and the like to not > cache the Set-Cookie header. See section 4.2.3 > of ftp://www.ietf.org/rfc/rfc2109.txt. > > > - Not to mention the helpful errors that try to help you > develop secure routes with warnings when you're doing > something obviously insecure. > > > This isn't a bad idea. > > > None of these things come out-of-the-box with Ring's > wrap-session, even with {:secure true} set. > > > No, and I agree that there are definitely pieces of middleware > that could help, but I disagree on how ring-auth currently > goes about it. > > Improving Ring's security is a laudable goal, but it's also > something you need to be very careful with. Rather than > building on existing infrastructure, such as the secure cookie > flag or the existing wrap-session middleware, you're building > your own ad-hoc systems. This is not a good way to build > secure software. > > > Yes, you've repeated yourself several times on this subject. > However, at some point you need to engage with the code that is > actually present in ring-auth rather than repeating the abstract > goal of building on existing infrastructure (which ring-auth > mostly does). All it does is replace the logic in wrap-session > mainly because wrap-session doesn't have a way of regenerating > session identifiers. > > You keep repeating that best practices for Ring sessions are to > set the secure flag, have unguessable session identifiers, don't > use the same cookie for secure and insecure sessions, etc. except > that none of these are the default in Ring and have to be thought > through individually by developers. Saying that it's their own > fault if they somehow miss one of the things on the list is not > helpful. > > Ring-auth implements the OWASP suggested measures for securing > sessions all in one place, makes choices about things like > generating the session identifier where there is an obvious right > choice from a security perspective, and tries to catch common bugs > or misconfigurations where possible. It's clear you have > philosophical differences regarding how it's implemented, but > unless you have some specific point about the security of > ring-auth, I would ask you to stop badgering. > > You have a lot of sound ideas, but any library that purports > to improve security needs to be very carefully considered, and > should be held to a far higher standard. > > - James > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to [email protected] > Note that posts from new members are moderated - please be patient > with your first post. > To unsubscribe from this group, send email to > [email protected] > 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 [email protected] > <mailto:[email protected]>. > 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 [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
