Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-25350

'/users/userpicker.action' exposes users loginids and full names in instance with anonymous access enabled

      LDAP directory users and groups exposed via the /users/userpicker.action.

      There should be an option to restrict this to authenticated users only and perhaps this should be the default behavior.

      The second exposed function that is part of this vulnerability is /spaces/opengrouppicker.action which can be accessed by anonymous users for internal directory browsing.

            [CONFSERVER-25350] '/users/userpicker.action' exposes users loginids and full names in instance with anonymous access enabled

            Don Willis added a comment -

            I added the fix version to make sure it shows up in people's searches.

            Don Willis added a comment - I added the fix version to make sure it shows up in people's searches.

            This fix would be in 4.3

            Chii (Inactive) added a comment - This fix would be in 4.3

            VitalyA added a comment - - edited

            What should I tell to the customers about when it is going to be fixed and how?

            VitalyA added a comment - - edited What should I tell to the customers about when it is going to be fixed and how?

            Matt Ryall added a comment -

            Sounds good to me.

            So we'll leave adding it to the group and individual permissions on the Global Permission screen until later?

            Matt Ryall added a comment - Sounds good to me. So we'll leave adding it to the group and individual permissions on the Global Permission screen until later?

            CharlesA added a comment -

            The "quick fix" of extending the View User Profiles permission to also remove access to anything else that allows you to enumerate users works for me. The existing permission is intuitively what the customer wants, so there's not much point adding yet another one on top. That said, I'm wary of landing the change on stable because it's a backwards-incompatible fix, and will effectively "break" functionality on a stable point release.

            Regardless of its chance of landing on branch, I'd like it if on trunk we took the opportunity to clean up the semantics of the permission so it is actually called "Browse Users", and it's documented that it will also block off things like autocomplete, search, mentions and the people directory.

            CharlesA added a comment - The "quick fix" of extending the View User Profiles permission to also remove access to anything else that allows you to enumerate users works for me. The existing permission is intuitively what the customer wants, so there's not much point adding yet another one on top. That said, I'm wary of landing the change on stable because it's a backwards-incompatible fix, and will effectively "break" functionality on a stable point release. Regardless of its chance of landing on branch, I'd like it if on trunk we took the opportunity to clean up the semantics of the permission so it is actually called "Browse Users", and it's documented that it will also block off things like autocomplete, search, mentions and the people directory.

            Matt Ryall added a comment -

            This seems like a duplicate of CONF-25322. You should resolve that issue with the same change, at a minimum.

            Matt Ryall added a comment - This seems like a duplicate of CONF-25322 . You should resolve that issue with the same change, at a minimum.

            Matt Ryall added a comment -

            Joe, can you check this change with Charles? He should be able determine whether that makes sense given the overall permission model of the app.

            Matt Ryall added a comment - Joe, can you check this change with Charles? He should be able determine whether that makes sense given the overall permission model of the app.

            I think for a quick fix, we could add the view profile permission to the check, i.e., the combination of use confluence permission and view profile permission can substitute for the browse user permission (since, if you have permission to view each profile in turn, you can just enumerate all characters from a to zzzzz... for the url /display/~[username] to find out the user).

            Chii (Inactive) added a comment - I think for a quick fix, we could add the view profile permission to the check, i.e., the combination of use confluence permission and view profile permission can substitute for the browse user permission (since, if you have permission to view each profile in turn, you can just enumerate all characters from a to zzzzz... for the url /display/~[username] to find out the user).

            matt@atlassian.com yeah CONF-25322 is similar to this issue.

            David Black added a comment - matt@atlassian.com yeah CONF-25322 is similar to this issue.

            Matt Ryall added a comment -

            I seem to remember commenting on this issue before. Is there a related similar ticket?

            This is somewhat "by design" at the moment. Anonymous users are able to access features that require a user search API – mentions, autocomplete, search, and so on.

            I believe the best way to address this is to add a global permission for "Browse Users", just like JIRA. Only users which have this permission should be able to access features which require the ability to search through the users on the site.

            Matt Ryall added a comment - I seem to remember commenting on this issue before. Is there a related similar ticket? This is somewhat "by design" at the moment. Anonymous users are able to access features that require a user search API – mentions, autocomplete, search, and so on. I believe the best way to address this is to add a global permission for "Browse Users", just like JIRA. Only users which have this permission should be able to access features which require the ability to search through the users on the site.

              jxie Chii (Inactive)
              gnedel Guilherme Nedel (Inactive)
              Affected customers:
              0 This affects my team
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: