[CKAN-Security] Fwd: Potential http Cache poisoning

Mon Apr 29 09:33:59 UTC 2019

If someone has the chance of testing this before our call tomorrow that
would be great. We can discuss then.

---------- Forwarded message ---------
From: Adrià Mercader <adria.mercader at okfn.org>
Date: Mon, 29 Apr 2019 at 11:32
Subject: Re: [CKAN-Security] Potential http Cache poisoning
To: <codywboyko at gmail.com>
Cc: CKAN Security Alerts/Discussions <security at lists.okfn.org>

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/67f31760/attachment-0001.html>