[CKAN-Security] Potential http Cache poisoning

[Cody B]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.okfn.org/mailman/private/security/attachments/20190424/4efa6596/attachment.html>