On Saturday, May 17, 2014 9:03:01 PM UTC-4, James Reeves wrote: > > On 18 May 2014 00:09, Brendan Younger <[email protected] > <javascript:>>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]. For more options, visit https://groups.google.com/d/optout.
