[CKAN-Security] Potential http Cache poisoning

Mon Apr 29 09:35:09 UTC 2019

One more thing,

Are you using the standard CKAN package installation? Have you customized
the cache settings in Nginx? Can you share your nginx configuration?

Thanks a lot,

Adrià

On Mon, 29 Apr 2019 at 11:32, Adrià Mercader <adria.mercader at okfn.org>
wrote:

> Thanks for the report Cody. We'll discuss it and get back to you as soon
> as we can. Also feel free to join one of our public meetings in case you
> want to discuss it further.
>
> Dev Meetings Notes - HackMD <https://hack.allmende.io/ckan-meeting>
>
> On Mon, 29 Apr 2019 at 11:24, Cody B <codywboyko at gmail.com> wrote:
>
>> Hi there,
>>
>> I've come across this potential bug previously but was unsure if it was a
>> CKAN core issue or just an extension issue.  After further testing I
>> believe this is originating in CKAN core.
>>
>> I have further notes on my previous experience with this issue that I'm
>> happy to share if you'd like. Also feel free to let me know of any other
>> way I can assist.
>>
>> *Potential security bug:*
>>
>> CKAN does not seem to pass the correct cache-control headers in some
>> cases. This is allowing cache servers to store some user information and
>> return this information to unauthenticated users. See reproducible steps
>> below. The below example is a simple one to demonstrate. This issue
>> thread
>> <https://github.com/NaturalHistoryMuseum/ckanext-ldap/issues/40#issuecomment-485869920>
>> shows the potential larger issues. Note: when I posted there I didn't
>> really believe this was a larger issue (and I may be wrong).
>>
>> *Reproducible steps:*
>>
>>    1. Clean install of CKAN 2.8 on Ubuntu 16.04 LTS (and on 18.04)
>>    following the default Source install documentation
>>    <https://docs.ckan.org/en/2.8/maintaining/installing/install-from-source.html>
>>    and deployment with NGinx and Apache
>>    <https://docs.ckan.org/en/2.8/maintaining/installing/deployment.html>
>>    2. Add new sysadmin user.
>>    3. Navigate to a protected action in a new blueprint
>>    (***All browser testing is done in new chrome incognito windows after
>>    closing the previous ones***)
>>    *Tested example endpoint:* `http://
>>    <site-domain>/api/3/action/dashboard_activity_list`
>>    4. The expected response is given: `{"help": "http://<domain>/api/3/action/help_show?name=dashboard_activity_list",
>>    "success": false, "error": {"message": "Access denied: You must be logged
>>    in to access your dashboard.", "__type": "Authorization Error"}}`
>>    5. New browser - Navigate to same url but pass an Authorization
>>    header with a SysAdmin user's API key. (I used a proxy to intercept the
>>    request and add the header to keep testing in the browser but presumably
>>    this would be the same with a script)
>>    6. The expected response is given: ` {"help": "http://<domain>/api/3/action/help_show?name=dashboard_activity_list",
>>    "success": true, "result": [{"user_id":
>>    "45ddssaa9c4-dasdas-4451-b29e-c399a2db93d6", "timestamp":
>>    "2019-04-24T14:59:28.939536", "is_new": false, "object_id":
>>    "45ddssaa9c4-dasdas-4451-b29e-c399a2db93d6 ", "revision_id": null,
>>    "data": {}, "id": "36asdsas1b9-ece6-4a02-b211-f9afdsaabb927",
>>    "activity_type": "new user"}]}  `
>>    Note: it's a brand new site with no data really so no activity, but
>>    success is true and this is the expected response.
>>    7. New browser - Navigate to same url without intercepting request or
>>    including an authorization header with the API key and you get the same
>>    response `{"help": "http://<domain>/api/3/action/help_show?name=dashboard_activity_list",
>>    "success": true, "result": [{"user_id":
>>    "45ddssaa9c4-dasdas-4451-b29e-c399a2db93d6", "timestamp":
>>    "2019-04-24T14:59:28.939536", "is_new": false, "object_id":
>>    "45ddssaa9c4-dasdas-4451-b29e-c399a2db93d6 ", "revision_id": null, "data":
>>    {}, "id": "36asdsas1b9-ece6-4a02-b211-f9afdsaabb927", "activity_type": "new
>>    user"}]}`
>>     Note: This is a non-authenticated user request, the expected
>>    response should be the same as bullet 4.
>>    8. Clear nginx cache or wait for it to expire (default is 30 min). In
>>    my case I delete the cache directories, then restart the servers.
>>    `sudo rm -rf /tmp/nginx_*`
>>    `sudo service nginx restart && sudo service apache2 restart`
>>    9. New browser - Navigate to same url *without* intercepting request
>>    or including an authorization header with the API key and you get the
>>    expected response as per bullet 4 : `{"help": "http://<domain>/api/3/action/help_show?name=dashboard_activity_list",
>>    "success": false, "error": {"message": "Access denied: You must be logged
>>    in to access your dashboard.", "__type": "Authorization Error"}}`
>>
>> *What I've noticed:*
>>
>>    - This seemed to happen in various areas starting in CKAN 2.8.
>>    - A few authorization extensions (issue thread)
>>    <https://github.com/NaturalHistoryMuseum/ckanext-ldap/issues/40#issuecomment-485869920>
>>    seem to be uncovering this when users login and logout (users can't logout,
>>    or user switching is happening). I think this is around the session related
>>    info being cached unexpectedly (session cookies?). So even though CKAN
>>    tries to clear cookies on logout (`check_session_cookie`, NGinx is
>>    returning active session info on some requests.
>>    - There was a decent amount of work done on flask blueprints and
>>    caching in CKAN around 2.8. I've done some comparisons to 2.7 and 2.8 to
>>    see the changes but there are many.
>>    - CKAN application code isn't passing the right cache-control header
>>    values on some responses which is causing them to be cached when they
>>    shouldn't be
>>
>> Thanks,
>> Cody
>> _______________________________________________
>> CKAN security
>> https://lists.okfn.org/mailman/listinfo/security
>> https://lists.okfn.org/mailman/options/security/adria.mercader%40okfn.org
>>
>> Repo: https://github.com/ckan/ckan-security
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.okfn.org/mailman/private/security/attachments/20190429/96413017/attachment-0001.html>