[CKAN-Security] (no subject)

Mon Nov 24 11:58:03 UTC 2014

Thanks very much for this Thrawn! This code is very useful. I've had a
bit of a think in how to implement this in core and take account of
various people's set-ups and customizations.

Having a token is v. bad for caching - for DGU we'd not want any token
in the form or cookie headers until the user is logged in, when we
don't cache.
e.g. DGU use POST requests for drop-downs lists that auto-submit (e.g.
language selector, 'sort-by' drop-down etc) - we don't want CSRF
protection for this.

It is recommended to require a token in all form POSTs apart from a
specific list of unchecked forms. That way when someone adds a new
form, POSTs will not work until the form is CSRF protected or
whitelisted - it does not become a security hole by default. However
as Ross says, this could disrupt extensions that have POSTs.

So I suggest a smooth transition over two CKAN releases: in the next
release we have a list of forms to check and a list of forms to not
check, and the remaining forms (extensions) are not checked but have
warning log messages. And in the following release we switch the
default so that those non-listed forms are checked. We could add a
note in the CHANGELOG for each release saying that every form needs a
csrf token adding, or the form is added to the 'not-checked' list.

I don't like adding cookies as it is one more thing to ignore in a
cache and explain in the site's privacy page. I prefer Django's way of
simply using a hidden form field containing the token. The Django page
suggests that cookies are useful for AJAX that needs protection, but I
don't think we have any AJAX to edit things the moment (do we?). We
could always simply add cookies if they are really necessary.

Yes we need to stop the ckan cookie being allowable authentication
when doing non-GETs to the API. As a sysadmin logged into ckan in a
browser, it can be useful to GET a group and see its users. However I
don't think people would use a browser to create or update objects. So
we could only allow API GETs to use the browser cookie.

David

On 24 November 2014 at 05:35, Thrawn <shell_layer-github at yahoo.com.au> wrote:
>
> Hi, folks.
>
> I'm still not subscribed to this list, so I won't see any replies, but I thought I'd let you know that I've developed a simple CSRF protection based on double-submitting cookies.
>
> Currently it's implemented as part of a custom plugin, so it's not something to be just applied directly to CKAN code, but it's small, and I thought reading through it might give people some ideas.
>
> The basic algorithm is:
> - Intercept the 'render' function. Generate a random token and perform string substitution to add it to all HTML forms, then also add it as a cookie.
> - Intercept the BaseController '__before__' function. If the request is a POST other than the API, then check that the token is present in a cookie and in the request body.
>
> Anyone interested in adding this to CKAN core?
> _______________________________________________
> CKAN security
> https://lists.okfn.org/mailman/listinfo/security
> https://lists.okfn.org/mailman/options/security/david.read%40hackneyworkshop.com
>
> Repo: https://github.com/ckan/ckan-security