On 18 May 2014 00:09, Brendan Younger <brendan.youn...@gmail.com> 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. > - 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. > - 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. > - 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. 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 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.