[CKAN-Security] (no subject)

Tue Mar 10 02:51:38 UTC 2015

Hello, again.

I've attached an updated anti-CSRF module. As before, to enable it, just import the module and call it:

import anti_csrf
anti_csrf.intercept_csrf()

David, this version doesn't do any insertion or filtering if the user is not logged in (based on the presence of the auth_tkt cookie; there's probably a better way), so it shouldn't disrupt your caching :). It's also somewhat more robust when a request passes through multiple page renders, because it keeps track of tokens using ad hoc attributes of the request object (http://docs.webob.org/en/latest/reference.html#ad-hoc-attributes).

It doesn't specifically check a list of forms to ignore, but it does specify an excluded URL pattern (the API, in this case), so that would be an easy enhancement.

I also considered using server-side token storage, instead of cookies. However, besides the overhead, I'm not sure what existing session mechanisms there are to hook into, and obviously I don't want to reinvent that wheel. And with server-side state, either you keep the same token for the entire session (which may leave it more vulnerable to theft), or you tend to run into problems if the user hits the Back button.

All feedback is welcome, though!

Thrawn

>------------------------------
>On Mon, Nov 24, 2014 10:58 PM AEDT David Read wrote:
>
>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
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: anti_csrf.py
Type: text/x-python
Size: 3271 bytes
Desc: not available
URL: <https://lists.okfn.org/mailman/private/security/attachments/20150309/d2f390f2/attachment.py>