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.
