5 ms·

The talk he links to (https://www.youtube.com/watch?v=CBL59w7fXw4 https://www.youtube.com/watch?v=CBL59w7fXw4) is really fantastic. Kudos to Aaron Bedra for is

The talk he links to (https://www.youtube.com/watch?v=CBL59w7fXw4 https://www.youtube.com/watch?v=CBL59w7fXw4) is really fantastic. Kudos to Aaron Bedra for issuing a well-considered and practical wake-up call to the Clojure community. I support a Clojure/ClojureScript web app in my day-to-day work. I've also written an OAuth2 workflow for friend (https://github.com/ddellacosta/friend-oauth2 https://github.com/ddellacosta/friend-oauth2 ...pull requests welcome), one library Aaron Bedra spends a lot of time talking about. The story really is exactly how he describes--Clojure web security could be better. I suppose you could argue that, at least, the defaults are generally not bad...but that's because there aren't defaults in many cases. I think the main issue is, ironically, the same thing that makes Clojure development so great: you end up composing a bunch of small libraries together, each of which do one thing well. But as Aaron points out, there are things that aren't taken care of and you can't assume they are done for you, and a lot of security is something that you don't technically need to get a web app working... I wouldn't want to give up the approach of composing a bunch of libraries to build concise, easy-to-reason-about web apps in Clojure--I think it helps with security in and of itself--but the community could really benefit from having more libraries which nail these things down and help developers build web apps more safely, with less work. That said, I don't think it's all bad: you can build high quality, secure web apps in Clojure, it just requires you to really pay attention to security. And we should be doing that anyways, right?

route66 13y ago
Another important thing he points at is to not write you own incarnation of every library you find lacking but provide patches/support/whatever to existing ones. While it might help your CV to have just another template library (which will inevitably be lacking again) on github, the ecosystem profits more from a few well defined and long-term maintained choices.
- stcredzero 13y ago
  "Yet Another Unmaintained Library" is the new useless CS master's thesis.
freshhawk 13y ago
I watched that talk yesterday and it was great, his list of issues and concerns are very justified but I wasn't excited about the proposed solutions: "just pick one templating language", "everyone use a (heavy, highly opinionated) framework", etc. They struck me as both unrealistic considering the clojure community and a little too much "find the silver bullet" for my tastes. That said, I understand why a security focused person would want this and if my role was to be concerned about these things I would probably push in that direction as well. When taking a larger view however, this is a poor tradeoff IMO. "I wouldn't want to give up the approach of composing a bunch of libraries to build concise, easy-to-reason-about web apps in Clojure--I think it helps with security in and of itself--but the community could really benefit from having more libraries which nail these things down and help developers build web apps more safely, with less work." You nailed it, well said. I want a checklist and good libraries, not a framework that promises to handle things for you but quietly leaves a big hole open in that one part where you had to work around the framework to solve your problem (there is always at least one isn't there?). You just can't avoid understanding these common attacks and how to mitigate them, at least at a surface level. You have to at least know where to apply the appropriate techniques, the implementation of that technique is left up to a well documented library written by experts. "That said, I don't think it's all bad: you can build high quality, secure web apps in Clojure, it just requires you to really pay attention to security. And we should be doing that anyways, right?" Not only should you be doing that, but if you aren't designing with security in mind then you are doing it wrong IMHO, "secure by default" framework or not. Either the people configuring the framework or the people writing the layers at the edges need to understand web security. All that said, I understand the push in this direction. If you have a large team of junior devs then you want to limit their power. It's just not an approach that fits very well with Clojure. It's like Rich Hickey's attitude towards unbounded queues: there is no support for them, because you must be aware of this issue and hiding it causes bugs. There, now I've invoked Rich Hickey to justify my anti-framework bias ... so I must be right.
- stcredzero 13y ago
  "just pick one templating language" He has a point. Is one really that much better than another? Also, shouldn't it be possible to come up with a single library to do HTML escaping that has the suitably paranoid defaults, which is then used by all the templating languages? Is one templating language's code for that going to be so much revolutionarily better than another's? "everyone use a (heavy, highly opinionated) framework", etc. My understanding is that he pointed that out as a solution other environments have taken (Rails) but that there was also value in the composable way of doing things in Clojure. His actual position, I understood as, "there must be some way of unifying this for Clojure."
smrtinsert 13y ago
We need to give it special consideration. Web libraries could make an effort to do an internal audit and maybe post a disclaimer. As a community we should highlight libraries with a focus on security as well. I think key is focusing on making this a community consideration early and not falling into the same pit of issues as other popular languages/frameworks which shall remain nameless for the purpose of this comment.

route66 13y ago

Another important thing he points at is to not write you own incarnation of every library you find lacking but provide patches/support/whatever to existing ones. While it might help your CV to have just another template library (which will inevitably be lacking again) on github, the ecosystem profits more from a few well defined and long-term maintained choices.

stcredzero 13y ago
"Yet Another Unmaintained Library" is the new useless CS master's thesis.

freshhawk 13y ago

I watched that talk yesterday and it was great, his list of issues and concerns are very justified but I wasn't excited about the proposed solutions: "just pick one templating language", "everyone use a (heavy, highly opinionated) framework", etc. They struck me as both unrealistic considering the clojure community and a little too much "find the silver bullet" for my tastes. That said, I understand why a security focused person would want this and if my role was to be concerned about these things I would probably push in that direction as well. When taking a larger view however, this is a poor tradeoff IMO. "I wouldn't want to give up the approach of composing a bunch of libraries to build concise, easy-to-reason-about web apps in Clojure--I think it helps with security in and of itself--but the community could really benefit from having more libraries which nail these things down and help developers build web apps more safely, with less work." You nailed it, well said. I want a checklist and good libraries, not a framework that promises to handle things for you but quietly leaves a big hole open in that one part where you had to work around the framework to solve your problem (there is always at least one isn't there?). You just can't avoid understanding these common attacks and how to mitigate them, at least at a surface level. You have to at least know where to apply the appropriate techniques, the implementation of that technique is left up to a well documented library written by experts. "That said, I don't think it's all bad: you can build high quality, secure web apps in Clojure, it just requires you to really pay attention to security. And we should be doing that anyways, right?" Not only should you be doing that, but if you aren't designing with security in mind then you are doing it wrong IMHO, "secure by default" framework or not. Either the people configuring the framework or the people writing the layers at the edges need to understand web security. All that said, I understand the push in this direction. If you have a large team of junior devs then you want to limit their power. It's just not an approach that fits very well with Clojure. It's like Rich Hickey's attitude towards unbounded queues: there is no support for them, because you must be aware of this issue and hiding it causes bugs. There, now I've invoked Rich Hickey to justify my anti-framework bias ... so I must be right.

stcredzero 13y ago
"just pick one templating language" He has a point. Is one really that much better than another? Also, shouldn't it be possible to come up with a single library to do HTML escaping that has the suitably paranoid defaults, which is then used by all the templating languages? Is one templating language's code for that going to be so much revolutionarily better than another's? "everyone use a (heavy, highly opinionated) framework", etc. My understanding is that he pointed that out as a solution other environments have taken (Rails) but that there was also value in the composable way of doing things in Clojure. His actual position, I understood as, "there must be some way of unifying this for Clojure."

smrtinsert 13y ago

We need to give it special consideration. Web libraries could make an effort to do an internal audit and maybe post a disclaimer. As a community we should highlight libraries with a focus on security as well. I think key is focusing on making this a community consideration early and not falling into the same pit of issues as other popular languages/frameworks which shall remain nameless for the purpose of this comment.