Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BUG: Portal user details visible on public link #1914

Closed
estebanruseler opened this issue Jul 23, 2020 · 3 comments
Closed

BUG: Portal user details visible on public link #1914

estebanruseler opened this issue Jul 23, 2020 · 3 comments

Comments

@estebanruseler
Copy link

estebanruseler commented Jul 23, 2020

Summary

  • Inventory app release version TBC (based on CKAN 2.5.2)
  • Environment - PROD
  • Error logs - n/a

If you go to https://inventory.data.gov/user you will see a list of users. This info should only be visible to logged-in users with appropriate access.

This is not a critical security issue but I'm raising as you probably want to protect inventory app user privacy. In its current state, any unauthorized user that stumbled upon the user page can view the email address of every inventory app user (or this could be picked up by a scrapper running looking for @__.gov emails). This is probably an issue for compliance with California Consumer Privacy Act (CCPA) or similar legislation in other States.

How to reproduce

Do not log into the portal, and visit https://inventory.data.gov/user

Expected behavior

If you are not logged in and try to access this page then you should get redirected to https://inventory.data.gov/saml2_unauthorized, and you're presented with a message something like: You are not authorized to view this

Actual behavior

Unauthorized users can view the entire list of user emails.

Screen Shot 2020-07-23 at 20 16 25

Analysis stub (by Datopian)

This is a CKAN 2.5 issue.

In 2.8 there is a config setup which will restrict this page: https://docs.ckan.org/en/2.8/maintaining/configuration.html#ckan-auth-public-user-details

But in 2.5 this config setup doesn't exist, and the implementation needs to be done in an extension. The solution is overriding the user controller, and only allow access to the admin user to this page.

Two options:

  1. Fix
  2. Wait till 2.8 migration to fix this if around the corner
@adborden
Copy link
Contributor

adborden commented Jul 23, 2020

Inventory is pretty confusing about what should be publicly visible vs. not. Unless you're seeing any sensitive information like passwords or private metadata, I don't think this is an issue.

Inventory.data.gov stores a lot of open data and most APIs (including the users and activity pages) are publicly accessible. There are some private datasets, but those should have their access restricted appropriately.

  1. as a government system for government employees, there is no expectation of privacy for users 🙁
  2. this page and the users API allows auditors to view the list of users with access to the system and allows us to write automation around compliance (compliance as code).
  3. as an open data system, we want the APIs to the system accessible to the public for transparency and accessibility. As long as CKAN considers the users page public by default, I don't feel strongly about changing it.

@estebanruseler do you have any ideas on how to improve this? I think that creating a public landing page (#1863) that explains what inventory.data.gov is for would go a long way. I think when a user is hit with "You are not authorized" message, it implies the entire system is for authorized users only, but that is not the case.

@estebanruseler
Copy link
Author

@adborden I like your idea of a public landing page instead of the current redirect which basically says "you're not meant to be here"

CKAN does consider the user page public by default but in CKAN 2.8 - unlike previous versions - there's the ability to config so that the page is only viewable to users with the right access. In the GDPR/CCPA era, I think most people go for the page not being public so that the email addresses of the portal users are not on the interwebs (but I don't know if organizational email addresses count as personal data and needs to be protected). But I get your logic of defaulting to open and going with what the default is in CKAN. Also, if it is a bug I don't think it's a critical bug. We just found it that the page wasn't private and wanted to flag it.

@mogul
Copy link
Contributor

mogul commented Jul 24, 2020

Closing as we don't feel this needs further resolution.

@mogul mogul closed this as completed Jul 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants