In a recent PowerShell SharePoint Auditing class we got side tracked on a discussion about security and the Limited Access Permission Level. I mentioned that even the names of lists and libraries can leak confidential information and that users with Limited Access permissions can often see these names. That led to a mandatory demo of the issue and a promise of a blog article with complete demo steps…
The Summer Co-Op said what?
You granted permissions to an innocent library like Sales Training Materials to a summer co-op. Later they ask you about plans to acquire a competitor. In a panic you check every document in that library for anything about the other company or about acquiring anything. You find nothing. You finally ask the co-op how they heard about that and they just answer "I saw it in SharePoint while looking for the training materials".
More fun security stuff!How did they discover it? In the Quick Launch on the page for the training materials library there's a link named "Confidential: XYZ Acquisition Documents". How did they even get to see that? Limited Access.
Even worse… when they clicked the link they went to the library's page and there could the verbose description that was added by the person who created the list!
What about SharePoint 2013? 2013 has similar issues, but does hide the Quick Launch. I'll follow up with a 2013 specific article.
Demonstration:
Test setup:
- Create a new site collection. (just so everything is "clean")
- Go to Site Actions, Site Permissions, click Check Permissions and confirm that your test user currently has no access to the site.
- Create a new library or two so you have at least two for testing. Give them fun names like "Training Documents", "Top Secret", "Department Layoff Documents", and "Confidential Mergers and Acquisitions".
- Break inheritance on one of the more confidential libraries (Stop Inheriting Permissions button).
- Remove all access except for the Owners group.
You now have a site with all content visible to your Owners, Members and Visitors groups… except for your test library, which only the Owners can see.
Test 1 – Grant a user access to the site
- Go to Site Actions, Site Permissions and click Grant Access
- Add your test user to the members group
- Open a browser and login as your test user.
- Best ways to test (in order or preference):
- Logon from a different computer as your test user.
- Open a different brand of browser (Firefox, Chrome, etc.) using "Run as different user".
- Open a different brand of browser. (Firefox, Chrome, etc.)
- In Internet Explorer use File, New Session.
- Visit the site as the test user
- In Quick Launch and All Site Content you should see all site content, except for the library where you broke inheritance. This user will not know that the secured library even exists. (This is probably what you expected with security trimming.)
- If you copy and paste a URL that goes directly to the confidential library, or a file in the library, then you should get an Access Denied message.
Results:
- User can't discover the secured content.
- Actually a good hacker can discover that the library exists. If they type or copy and paste the URL to a real library then they will get "Access Denied". They at least now know that the library exists. If they type a URL to a library that does not exist they will get a 404 Not Found error.
- Users using the REST web services (see later in this article) won't discover the secured lists.
Test 2 – Grant a user only access to a library with broken inheritance
- Remove any permissions granted in Test 1. Use Check Permissions to confirm that they do not have access to the site.
- Grant access to your test user to just the library (don't add to one of the site groups!) Grant permissions to your test user and grant "Contribute".
- Visit the library, click the Library ribbon, click Library Settings and click Permissions for this document library
- Break Inheritance
- Grant the Contribute Permission Level to your test user.
- Open a browser for your test user (see the info in Test 1) and paste in the the URL to the secured library. The user should be able to see the library and the library contents.
- Note the Quick Launch menu… All of the lists and libraries are visible!
- Click on any of the libraries listed in Quick Launch. The user will see the library's page, but no content. While the content is secure, the user now knows that the library exists. They can see both the list title and description.
Results:
- User can't discover the secured content., but the user can discover the names all of the lists and libraries in Quick Launch.
- The user will get Access Denied when accessing the home page.
- The user will see all custom links and content added directly to the master page.
Why?
Limited Access.
If you return to the browser where you are logged on as a Site Owner and visit the libraries you will see that the user with only access to a single library actually has the Limited Access permission level to all lists and libraries.
Why does Sam have Limited Access to this library? Sam was given "Limited Access" to the site when he was given Contribute to the library so he could see the master page and other resources needed to display the pages for the one library he was granted access to. All of the lists and libraries currently inherit their permissions from the site, therefore they inherit Sam's Limited Access permissions.
Side effects of granting permissions to a List, Library, Folder or Item, but not to the Site:
- User gets access to the List, Library, Folder or Item where they were directly granted permissions.
- User can see links to all lists and libraries in Quick Launch and other links. (I.e. no security trimming in Quick Launch.)
- User cannot see the content of the List, Library, Folder.
- User can hand enter a URL to any list or library and confirm that the item exists. (I.e. Gets to the list or library pages, but not to the items in the list or library.)
- User cannot visit the Site Content page. But that link is listed in their Quick Launch area and in their Site Actions. Clicking the link will display Access Denied.
- User cannot visit any page stored in the Site Pages library. Your home page is Site Pages.
- Your site icon may not display properly as they are often stored in Site Assets or other library. The same is true for any image, CSS or JavaScript stored in libraries.
What about all of the other lists not in Quick Launch?
Are they discoverable by the Limited Access user? Yes, if they can Google or Bing! SharePoint 2010 has a RESTful web service that exposes lists. While this is security trimmed, the user in the above scenarios has access to the list's name through the inherited Limited Access permissions. I.e. this is not a bug with Quick Launch, it's a "feature" of Limited Access! Here's what the user will discover from a web search:
http://yourserver/sites/yoursite/_vti_bin/ListData.svc
That link will display via XML the list of lists and libraries!
SharePoint 2013 includes the above REST service plus a more generalized version.
https://yourserver/sites/yoursite/_api/web/lists
The Fix?
To prevent the accidental discovery of other lists and libraries when using unique permissions on a single list or library you will need to break inheritance on every list and library and grant the appropriate access.
You will need to:
- Break inheritance on all content lists and libraries and grant access to the appropriate groups and users. If you do this after you have granted unique permissions to a user, you will need to remove the Limited Access users from each list and library.
- Grant View access to everyone to the Site Access library (or where ever you store site logos, CSS and other support files) so your icons and custom branding will display correctly. "Everyone" could be a group unique to your site or department or "NT AUTHORITY\Authenticated Users" for everyone who can logon to your networks. Granting access in anyway to "NT AUTHORITY\Authenticated Users" is not generally a good practice!
There's no end to learning SharePoint!
.
) after November 1st.
