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 On 18 May 2014 14:06, Brendan Younger <[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]. For more options, visit https://groups.google.com/d/optout.
