[CKAN-Security] CSRF vulnerability from TRAC ticket 1001

Mon Nov 24 12:03:01 UTC 2014

Thrawn,
Yes, good point about the cookie and API requests, especially in
elaborating the issue when combined with JSONP. As mentioned in my
previous reply, we're all keen to stop that although I think we can
keep it for GET requests as nothing is changed.
David

On 24 November 2014 at 06:51, Thrawn <shell_layer-github at yahoo.com.au> wrote:
>
> TRAC ticket 1001 (back when CKAN used TRAC) opened a very significant CSRF weakness, by making the API honor auth_tkt cookies.
>
> This is a real problem, for two reasons:
>
> 1) The JSONP support means that websites can not only launch CSRF attacks, but can actually read the response data. In the case of administrators, this includes password reset keys for all accounts (via the user_list API).
>
> 2) The API cannot easily be protected against CSRF attacks, since it can't apply the normal patterns of HTML forms containing secret tokens, or even referrer-based defences.
>
> I'm also troubled by the fact that the CSRF problems were brought to the attention of the ticket author and committer at the time, and he chose to dismiss them.
>
> The approach I'm taking at my workplace is to drop all cookies on API requests, at the Apache level. Normal usage of the API should not involve cookies, in my view. For the purposes of AJAX, can the API key be supplied in the POST body instead?
> _______________________________________________
> 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