Compiling Clojure security knowledge

[Vincent Ambo]

Hej everyone!

After a short but interesting discussion on #clojure I'd like to pose some security related questions to a larger audience.  

This is mostly about user-facing web applications.

First some short background: In the main web framework I use, Yesod, there is a clear and concise list (scroll down to "Type-safe security") of security issues already handled by the stack. This includes SQL injections, escaping of user input against XSS, CSRF form attacks and such. These aspects are also often mentioned in related tutorials and discussed in the community.

Some googling about another well-known web framework, Rails, brought up this page with lots of info about securing Rails applications.

Now the main question: Where is this info for Clojure's web stack and, assuming there is no collection of info, what do you specifically know about security in Clojure?

I'm looking to collect information on such matters as

* How and where do we prevent SQL injections? In a stack of Hiccup < Compojure < Ring < Korma < JDBC < Postgres-driver - which (if any) of these components ensures safety against injections? Is there documentation?

* How and where do we prevent XSS attacks? Do we have templating engines that escape things unless told otherwise, or - if not - do these features exist in the form of a helper function? If yes, where? (And so on...)

* Where are these things being discussed in the Clojure community? Googling things like "Clojure web security" brings up almost nothing.

Ideally everybody who knows answers to these points or to points not mentioned by me (go for example through the two sites I linked!) should post what they know with the ultimate goal to create something like the Rails site about our web stack in general, so that future generations don't have to go through the same information hunt.  

I'm willing to structure the info and write it together if we can collect it, so go!

(Note that I have also posted this on Reddit)

[Bruce Durling]

Vincent,

On Sun, Sep 1, 2013 at 8:06 PM, Vincent Ambo <taz...@gmail.com> wrote:

* Where are these things being discussed in the Clojure community? Googling things like "Clojure web security" brings up almost nothing.

Some discussions on this have started on the clojure-sec google group here:

https://groups.google.com/forum/#!forum/clojure-sec

Started by Chas Emerick after making Friend 

https://github.com/cemerick/friend

Though I think we'd all be happy to have more thinking in this area.

cheers,

Bruce

--
@otfrom | CTO & co-founder @MastodonC | mastodonc.com
See recent coverage of us in the Economist http://econ.st/WeTd2i and the Financial Times http://on.ft.com/T154BA

[Ivan Kozik]

On Sun, Sep 1, 2013 at 7:06 PM, Vincent Ambo <taz...@gmail.com> wrote:
> * How and where do we prevent XSS attacks? Do we have templating engines
> that escape things unless told otherwise, or - if not - do these features
> exist in the form of a helper function? If yes, where? (And so on...)

clojars uses https://github.com/ato/clojars-web/blob/master/src/clojars/web/safe_hiccup.clj
which automatically escapes.

Ivan

[abp]

clojars uses https://github.com/ato/clojars-web/blob/master/src/clojars/web/safe_hiccup.clj 
which automatically escapes. 

But that double escapes attribute values if you don't put them in raw-calls.

[Nelson Morris]

On Mon, Sep 2, 2013 at 6:25 AM, abp <abp...@gmail.com> wrote:

clojars uses https://github.com/ato/clojars-web/blob/master/src/clojars/web/safe_hiccup.clj 
which automatically escapes. 

But that double escapes attribute values if you don't put them in raw-calls.

Yes, it double escapes attributes. In addition, doctype helpers like `html5` might need to be redefined to use a `(raw ...)` for some parts. There might be other functions where a `(raw ...)` is needed. The changes in that file have proven sufficient for clojars, and I much prefer the escape by default semantics, but more work might be needed for others.

Additionally, CSRF protection can happen with ring-anti-forgery.  The clojars source link above includes a `form-to` function that is a replacement for hiccup's `form-to` that adds the token on any non-get/non-head forms.  It does require adding anti-forgery to the middleware stack.

----

Several of Yesod's responses to other items on the list are humorous in there vagueness, but in my experience for clojure:

1.Injection:   Done by JDBC's prepared statements, and clojure.jdbc's use of them

2. XSS injection:   Depends on templating.  Hiccup requires explicit `(h ..)` calls.  laser is escape by default.  I am unsure about enlive, clabango, or others.

3. Authentication & Session Management:  I've used friend for authentication, and bcrypt for encryption.  lib-noir has some functions that use bcrypt, but I've not used it. Session management can be specified by the :store given to wrap-session, and defaults to a in memory store.  A cookie store also exists that provides some protection against cookie mutation.  Immutant provides a store that can work across a cluster.

4. Insecure Reference:  There is not a standard ORM or similar, so handling only the correct parameters is up to you.

5. CSRF:  ring-anti-forgery provides a way to add CSRF prevention tokens

6. Security Misconfiguration: This seems to be the domain of chef, pallet, puppet, capistrano or another deployment tool.  I'm not sure I want my libraries to mess with deployments.

7. Insecure Cryptographic Storage: Use bcrypt. See 3.

8. Failure to Restrict URL access: I've used friend for authorization.

9. Insufficient Transport Layer Protection: I'd recommend letting your front end server handle this and redirect to https.  I believe lib-noir has a middleware that will redirect from http to https if needed. Consider passing `:secure true` to `wrap-cookies` if you have an https only site.

10. Unvalidated Redirects and Forwards: Url generation is a weakspot in a compojure based setup. For comparison, pedestal-service wrote its own routing dsl and stores the routes in a way that allows url generation based on the context passed in.

I believe the use of many small libraries is what causes the lack of a single spot for this documentation. I've picked up most of what I described above by knowing the authors / what to google / asking + watching irc.  That does seem like an unfortunate situation for anyone new to have to learn.

-

Nelson Morris

[Christopher Poile]

On Monday, September 2, 2013 8:10:10 PM UTC-6, Nelson Morris wrote:

----

Several of Yesod's responses to other items on the list are humorous in there vagueness, but in my experience for clojure:

1.Injection:   Done by JDBC's prepared statements, and clojure.jdbc's use of them

2. XSS injection:   Depends on templating.  Hiccup requires explicit `(h ..)` calls.  laser is escape by default.  I am unsure about enlive, clabango, or others.

3. Authentication & Session Management:  I've used friend for authentication, and bcrypt for encryption.  lib-noir has some functions that use bcrypt, but I've not used it. Session management can be specified by the :store given to wrap-session, and defaults to a in memory store.  A cookie store also exists that provides some protection against cookie mutation.  Immutant provides a store that can work across a cluster.

4. Insecure Reference:  There is not a standard ORM or similar, so handling only the correct parameters is up to you.

5. CSRF:  ring-anti-forgery provides a way to add CSRF prevention tokens

6. Security Misconfiguration: This seems to be the domain of chef, pallet, puppet, capistrano or another deployment tool.  I'm not sure I want my libraries to mess with deployments.

7. Insecure Cryptographic Storage: Use bcrypt. See 3.

8. Failure to Restrict URL access: I've used friend for authorization.

9. Insufficient Transport Layer Protection: I'd recommend letting your front end server handle this and redirect to https.  I believe lib-noir has a middleware that will redirect from http to https if needed. Consider passing `:secure true` to `wrap-cookies` if you have an https only site.

10. Unvalidated Redirects and Forwards: Url generation is a weakspot in a compojure based setup. For comparison, pedestal-service wrote its own routing dsl and stores the routes in a way that allows url generation based on the context passed in.

I believe the use of many small libraries is what causes the lack of a single spot for this documentation. I've picked up most of what I described above by knowing the authors / what to google / asking + watching irc.  That does seem like an unfortunate situation for anyone new to have to learn.

-

Nelson Morris

Thank you to Nelson for compiling this list. Since it was posted a number of months ago, has anyone recently written or stumbled over a go-to site for security in Clojure web/non-web apps? The clojure-sec group seems to be dead, but let me know if we should take the thread over there.

-
Christopher Poile