“Fine Tune Security for Sharepoint”

“Fine Tune Security for Sharepoint”

Microsoft SharePoint can be deployed as your own private cloud, so it is a popular platform for building extranets in professional services firms. Based on a Web interface, a SharePoint extranet portal is a proven, user-friendly solution for managing external business activities and providing useful, transparent interactions with your clients. However, SharePoint was not designed to function as an extranet out-of-the-box, and it could leave you vulnerable to security issues unless you take specific precautions to fine-tune the configuration.

Partitioning the Partition

White your extranet is secure within the partition that is your private cloud, your firm’s challenge is to maintain the security and privacy of individual client data maintained within that partition. There are a number of approaches. The simplest and most obvious approach to maintain security is to create a SharePoint site collection for each client, which establishes a secure database for each client. However, unless you have very few clients, this model is not scalable. Think of the difficulty of maintaining hundreds of thousands of separate databases. There are other alternatives, such as creating a Web application for every customer, but each would require sharing the infrastructure and taking extra steps to secure the data. Rarely will an organization be able to deploy a SharePoint extranet out-of-the-box without leaving themselves open to the accidental exposure of client data.

Inadvertent Authorization Bypass

Depending on how you design your site hierarchy, you can inadvertently give access to certain aspects of your sites that you’d rather not expose. For example, let’s say you want to store a list of courts in a SharePoint list. You would typically store this list at the top-level site and give ‘read’ access to all users so that the list can be used as a lookup for all subsites. Users won’t access this list directly, and, even if they do, all they will see is the list of courts, which is public information. However, once users have access to the list, they also have access to other URLs associated with the list. For example, a user can directly access the following pages:

      • /_layouts/user.aspx
      • /_layouts/People.aspx
      • /_layouts/groups.aspx
      • /_layouts/aclinv.aspx


This means, depending on how you configure these pages, you could expose information about other users and groups. What’s wrong with this? There are two major risks:

      • Business Risk – the client user see information about other client users and potentially see their email addresses as well.
      • Security Risk – if an attacker gains access to this page, they have the user IDs of everyone who accesses the site. The attacker could launch a denial of service (DOS) attack by trying to log in with an ID multiple times. When you have account-locking in place, all user accounts cloud be locked out after three to five failed attempts, and no one would be able to log in to the system.


Remedies: There are several ways to address the issue of providing unauthorized access to information on your site:

Lock down the identity of the user viewing the site by securing the _layout/people.aspx page:

      • Navigate to the root of your site collection
      • Click Site Actions, point to Site Settings and click People and Groups
      • In the Quick Launch, click All People 
      • On the toolbar, click Settings and then click List Settings
      • In the General Settings section, click Advanced Settings
      • In the Read Access section, select Only Their Own
      • In the Edit Access section, select Only Their Own
      • Allow only admin-level access to files, such as people.aspx, on your root site or sites where you don’t intend to provide user access
      • Put custom logic on the page to prevent direct access, either page by page or by creating custom HTTP handler, and control access to pages based on a user’s identity.


Cross-Site Scripting (XSS) Vulnerability

SharePoint provides a document-attachment feature with its collaborative list objects, such as announcements, tasks and calendars. When you create a new calendar or announcement, you can upload and attach any document format, including an HTML file. When a user clicks on the link, SharePoint will display the HTML page. If the HTML page has JavaScript in it,  it will execute it because the browser trusts your site. This means that a malicious user or a hacker could potentially trick users into clicking on harmful links or track cookies and other vulnerabilities.


Remedies: There are a couple of approaches you can take to mitigate cross-site scripting vulnerability:

      • Prevent the attachment of HTML or HTM files.
      • In SharePoint 2010, change the behavior of how attachments are handled, instead of displaying the page inline, you could have SharePoint download the file. This way, the harmful page is not executed under your site URL.


Source Code Exposure

Many SharePoint pages – such as images, CSS, templates, and master pages – are stored in special document libraries. Some of them are static files, such as images and style files, while others are more dynamic, such as master pages and page templates. Any user with read access can get to these special libraries and download these files. These files can expose the internal logic of how data are gathered, the name and path of machines, developers’ comments, and contact information. Source code disclosure vulnerabilities are an extremely target for malicious users because application source code contains implementation details that can be used to refine existing attacks against an application.


Remedies: There are a couple of approaches to mitigating source code exposure:

      • Write a custom HTTP handler that can prevent access to the page by examining IDs.
      • Develop best practices that eliminate writing sensitive data or comments in these pages, periodically reviewing code to make sure no sensitive information is exposed.


Mobile Pages

SharePoint comes with two kinds of pages: ones designed for PC’s and others for mobile devices. Mobile pages are designed for small screens with minimal and simple user interfaces. However, they usually display some information about the site and the list. Developers typically ensure that only relevant links are displayed on the PC interface, or they use security-trimming controls to hide certain links from most users. But they often forget that if you are hiding the links through security trimming or by simply removing the links, this customization also needs to be performed on the mobile pages. If it’s not, a smart user could simply go to the mobile links to access the information. you also need to rembmer that the mobile links are not just accessible via mobile phones or tablets, they can also be accessed from a PC as long as the URL is known (most mobile pages can be accessed from the /_layouts/mobile directory).


Remedies: There are a couple solutions for preventing exposure of information on mobile pages:

      • if you are not supporting a mobile interface, block access to the /_layouts/mobile directory.
      • if you are using a mobile interface, make sure that all mobile pages are tested.


Sleep Better at Night

SharePoint is an excellent collaboration platform with many features for deploying a client extranet. However, as with any external-facing web application, security is the primary consideration. Your SharePoint project should include a security review of your current design and security testing to ensure you don’t expose information you didn’t intend to expose, directly or indirectly. You should also periodically perform a security audit of your site or have it audited by a third-party security company. Forewarned is forearmed, and you’ll sleep better at night.

Click this button to read the ILTA Peer to Peer article

Want to learn more about Cybersecurity & Risk Management?

Read more about Cybersecurity & Risk Management from our solution page.

Learn more

Check our related articles