[CKAN-Security] CSRF vulnerability from TRAC ticket 1001

[Thrawn]

Hi, David.

Allowing cookies on GET requests would still be enough for an attacker to read password reset keys.

Suggested attack snippet (from our recent penetration testing):

<script>
function callbackFunction(data){
document.write(JSON.stringify(data));
}
</script>
<script src=https://<hostname>/api/action/user_list?callback=callbackFunction>
</script>

The attacker could easily trigger a password reset for any account (including the admin), then use the snippet above to steal the reset key and take over the account.

Regards

Thrawn

------------------------------
On Mon, Nov 24, 2014 11:03 PM AEDT David Read wrote:

>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