Sharing a Document to Guest Exposes Organization Membership/Information

[Michael DeMond]

Hello Community,

Cross-posting here from another forum to ensure visibility:

https://social.technet.microsoft.com/Forums/Sharepoint/en-US/a6eac395-1fc6-4ab7-be7d-29ade66f78c1/sh...

Essentially, it appears that giving guest access to a SharePoint document by way of the Share command gives this guest access to my directory data even though they technically do not have sufficient rights/permissions to Share the document in the first place.

I am wanting to, of course, protect my organization's data as much as possible from external sources.  Is there an obvious setting somewhere that turns off the Share functionality if the user does not have access/permission to do so?

Thank you for any assistance you can lend!

[#2]

Hi Michael,

If you invite a guest user to a SharePoint site, they should only be able to see other guest users in that site collection. If your guest users are seeing users from outside the site collection, please let me know. Thanks,

Stephen Rice

OneDrive Program Manager II

[#3]

Hi Stephen, thank you for your reply.  Unfortunately this does appear to be what's happening.  These are the steps as best as I can reproduce them:

1. Sign in as a domain user that has permissions to a SharePoint folder, and share this folder specifically to an external guest user that is not registered on the domain.
2. As the external user, check your email to get the link to the folder.  Click on the link and follow the process to authenticate with the code.
3. Upon entering the code from previous step and authenticating as the external guest user, note that the Share button is available in the top left.  Click it to open the share dialog.
4. From the Audience drop down ensure Specific People is selected.
5. Start typing email addresses of users in the domain as well as the email addresses of other guest users that this has been shared with.  In my case they consistently appear as if the external user is a member of the domain, which should not be allowed as they are gaining unauthorized data (membership) of the domain.  In addition to members of the domain, they are able to poll what appears to be service accounts, with SharePoint App being an example.

In my estimation, the external guest user should not see the Share functionality to begin with by default.  This should only be a feature that is allowed for domain members only (again, by default).  At a minimum a guest user should not be able to simply type a few characters within a field and do a poll on my domain membership as that is technically unauthorized activity and they are gaining access to unauthorized data.  Additionally, it doesn't take much from there to create an automated bot of some sort to perform the lookups in an automated fashion, essentially pulling my directory contents for whatever uses they like, nefarious or otherwise.

Please let me know if I have something misunderstood, if I am overlooking an obvious setting, and/or if you have any further questions around this.

Thank you,

Michael

[#4]

Thanks for elaborating Michael. Let me investigate further with the team and I'll get back to you. Thanks!

Stephen Rice

OneDrive Program Manager II

[#5]

Awesome, thank you Stephen.  FWIW I have been exploring this a little more as I do believe there is some confusion on my part with Site Collections vs. domains.  Additionally, there seems to be different behavior with sharing a document vs. sharing a folder.

Sharing a document works better from a security perspective than sharing a folder.  With a document, a guest user can see the parent folder, but when they visit that parent folder they see the document and no other information.  Perfect.

Sharing the folder, however, I as an external guest user can see the full membership of that folder in the top right.  This again seems like unnecessary (default) information for a guest user.  Additionally, the guest user can see all recent activity for a document, but not who did it.  That tells me that some effort is made somewhere to conceal identity information (good thing) but now there is at a minimum inconsistent behavior as all members who are in the group are in plain sight anyways (bad thing).

Finally, I did manage to create several new users who were not in the site collection.  As a domain member I was able to query them in the Share feature.  As a guest I was not.  I was able to add the non-site domain user's email but their name did not resolve like site domain users. So, this appears to be working as you have stated.   

However, I was also able to query other guest users of both folder and document, which I feel is a concern.  If I am invited to view an external document somewhere, it is not my expectation that other guest users can pull my information without my consent and/or awareness.  Additionally, being able to query *any* member -- regardless of whether they are domain or guest -- as an external guest is a security concern.  Consider that:

1. There are no terms of use presented to the guest user (that I can see -- feel free to correct me if I am wrong here) so they are essentially free to use the data as they wish.
2. This behavior works on any SharePoint online account that has sharing enabled so if this guest user has access to other SharePoint online accounts, the same behavior applies and they can harvest information from these other accounts and connect the dots as they may.  This is, of course, a compounded concern if this user is part of a coordinated set of other users who are performing similar operations.

[#6]

Hi @Michael DeMond,

The model for ODB/SPO is that permissions/discovery occurs at the site collection level. We allow users to see other people in the site to enable easy collaboration. There's certainly a balance here though. Also, the list of people you are seeing in the upper right is actually the membership of the site, not the permission of the folder (I believe at least, depending on which list of faces you are seeing :) ).

If you have any other concerns, feel free to submit a Design Change Request to the team. Thanks!

Stephen Rice

OneDrive Program Manager II

[#7]

OK that sounds good Stephen.  How does one go about doing that? :)

FWIW, I believe there are two scenarios for collaboration here:

1. The external guest user is registered in the domain (this is done via Office365 or Azure Active Directory.
2. The external guest user is not registered and their email is used to provide authentication to the document.

In the first scenario, especially when the document is given edit permissions, I can see providing more information to this registered external guest user.  In the 2nd one, however, I think it makes more sense that the user has less access to domain information.

Also, please do not lose sight of having someone's PII given to other members of a document/site without their permission.  I think if you did a survey/poll and asked external users of SharePoint/OneDrive sharing if they are OK with this, a good majority would find this surprising.  I certainly was because there is no messaging provided that this happens anywhere.

That said, I would like to pursue the design change request.  Please let me know what the next step would be for this and I will certainly provide my thoughts.

Thanks again!

Michael

[#8]

Hi @Michael DeMond

Actually, there is no difference between the two scenarios you listed (wrt the final outcome)...

In any case, in order to access a tenant' s resources, the external user should be present as a guest in the tenant's AAD. You have several ways, both direct and indirect, to add a guest, but you get the same final result.

[#9]

Right @Salvatore Biscari there is no difference currently and what I am suggesting is that there should be, as one (the former) is more of a collaborative intent, whereas the other (latter) is more focused on sharing.  With collaborative intent, the guest user should have more information (which is known and accepted by all parties).  Otherwise, the guest should only be given access to the specific resources and information that they are explicitly provided and no more.

Also, I am in agreement when your statement about tenant resource access, but looking in my AAD, I do not see any guest users that have been added to my directory as a result of the the share functionality that we're discussing here.

Also also. :)  Having said that, I think there's a distinction between accessing:

1. A tenant's resources such as documents and folders, and
2. A tenants' site membership and related information (PII in this case).

THAT said (whew!), there is still the whole issue of accessing PII by external users without explicit permission which I have not heard addressed by anyone just yet.  There is nothing that is sent via the invite or authentication code message about this taking place.  It would be great to know if I am overlooking an obvious consideration here as it seems very doubtful to me that external users would agree to having their PII available to anyone who has access to any of the documents in the same site collection (which is quite the exposure, IMO).

I think we have to only look at the recent Facebook scandal to know that users are not exactly happy with this sort of activity happening without their consent.

[#10]

A couple of thoughts:

1. Forgive me, but I don't grasp the difference between collaboration and sharing. To collaborate there should be something shared (i.e. a resource) and, conversely, when I share an item I am instantiating a collaboration on that resource. Hence, IMHO, the two concepts are the same.
2. Every time you share with an external user, he/she is added as a guest to the tenant. AFAIK, the only exceptions are anonymous sharing (where there is no authentication) and the new secure links (which use a form of validation that does not create a guest user in AAD.
3. Have you tried to uncheck "Let external users share items they don't own" in the OneDrive Admin Center? Does it solve your problem?
   
   
   

[#11]

Thank you for your continued dialogue here @Salvatore Biscari. :)

1. So, imagine creating a document that is simply meant to inform or to provide information, much like a simple web page.  It could simply be notes for this matter.  I as the owner of this domain-owned document simply want an external user to my organization to have access to this document so that they can see it and nothing more, while retaining privacy from the external world.  That is, only a certain person (or people) can see this document.  To me, this is not collaboration (yet) but rather sharing which is the most fundamental step here.  Collaboration takes this fundamental step (or notion) of sharing further by allowing this user to edit the document and provide feedback in an interactive fashion.  So, at the most basic level there is sharing, and then on top of that there is collaboration.  That is, you can have sharing without collaboration, but you cannot have collaboration without sharing.
2. We are indeed talking about the new secure links here, thank you for identifying that.  Recall that I am the newb and I am still feeling my way around here. :)  Given that, it would seem that since this user is never added to my domain in any capacity, their default security posture would be as restrictive as possible, very much like an anonymous user.
3. WOW.  Yes, that is exactly what I was looking for... why is this UI not readily available from my share screen?!  What am I missing here?  I had to find your forums and hassle your community for several days now with several lengthy posts to find this most valuable and obvious of features.  This seems like something that should be front and center as an administrator.

However, when I do go now as an external user, when I click the "i" (or Information), both the "Share" and "Grant Access" features are still readily available to me.  In fact, the drop down to perform a query is still displayed but quickly hidden from me.  I am actually able to type a few characters before it is hidden.

Why is "Share" (or worse yet Grant Access) even displayed to me as an external if it has been turned off altogether in administrative controls?  This seems (and feels) very sloppy and provides users with unnecessary surface area and awareness around the capabilities of my (or rather, YOUR :)) offering.

Thank you again for your assistance @Salvatore Biscari!

[#12]

Popping back in here. :)

You can submit Design Change Requests via the Office 365 Admin Center (I believe). I can't guarantee that any specific changes will come of it but it is a good way to suggest improvements on the product. The other thing you can do is submit a request for the OneDrive or SharePoint User Voice. We use votes/popularity of items in those lists to help guide our priorities for features requested by the community.

Can you describe the experience you are seeing when that box is disabled? Does the Share command come up and then disappear after a few seconds?

Going back to your privacy concerns, the model we generally propose is for each site collection to be scoped to the set of external users you want to collaborate with. For companies that have strict privacy requirements around external sharing, we recommend separating them into separate sites. This model has generally resonated well with the customers we've talked to but we're always open to feedback via the channels above (and forums like this). Thanks!

Stephen Rice

OneDrive Program Manager II

[#13]

Awesome, thank you @Stephen Rice for that information.  Actually, from a design perspective, everything is technically operating as I'd like now, thanks to @Salvatore Biscari taking the time to point me in the direction of the share controls (thanks again Salvatore!).

The only suggestion I have at this point from a design perspective is to make these advanced controls more obvious to administrators so that they can modify them accordingly.  I will look into sending a design change request and/or UserVoice to your team in for this issue.

From a privacy perspective, however, I still have concerns.  I hear what you are saying in regards to your modelling at the site collection and that makes sense, in fact I am in agreement with it.  However, the assumption and perspective here is from the site owner and not its external participants.

I cannot stress this enough (until I hear a reply for it from someone :) :( the external user never signs a terms of use that says that their PII is available to other quasi-authenticated external users of the same site collection. 

Again as a user, if someone from an organization sends me a link to one of their documents, the default expectation is that the organization has access to my PII (that's how they contacted me, after all), but other external users do not (unless provided explicitly).

But the worse part is that at present, external users can still harvest PII using the means above, even if you turn off external sharing as prescribed by Salvatore.  Since all the UI is still sent to the client and then later disabled/hidden by script, a nefarious actor can still simply use the browser's development tools to unhide the necessary UI and perform the actions as if they had the proper permissions.

Does this all make sense?  Please let me know if you have any questions around this as I still believe this is cause for concern and outside the realms of a design change request.  That is, I feel this is more of a security issue and bug.  However, if a design change request is required to report a bug and/or security consideration, who am I to argue with your process? :)  Please let me know the best way to proceed.