peerto

the quarterly magazine of ilta

peer SecuritySeptember 2012

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 PartitionWhile 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 or 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:

•BusinessRisk — The client user could see information about other client users and potentially see their email addresses as well.

•SecurityRisk — If an attacker gains access to this page, they have the user IDs of everyone who accesses the site. The

Fine-Tune Security for SharePointby Sheetal Jain of Prosperoware LLC

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 could 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 _layouts/people.aspx page:

• Navigate to the root of your site collection

• Click SiteActions, point to SiteSettings and click PeopleandGroups

• In the Quick Launch, click AllPeople

• On the toolbar, click Settings and then click ListSettings

• In the GeneralSettings section, click AdvancedSettings

• In the ReadAccess section, select OnlyTheirOwn

• In the EditAccess section, select OnlyTheirOwn

• 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 a 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 ExposureMany 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 popular 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 PagesSharePoint comes with two kinds of pages: ones designed for PCs 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

Fine-Tune Security for SharePoint

Application source code contains implementation details that can be used to refine existing attacks.

Fine-Tune Security for SharePoint

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 remember 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 of 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 NightSharePoint 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.

This article was first published in ILTA’s September 2012

issue of Peer to Peer titled “Security: A Strong Defense” and is

reprinted here with permission. For more information about

ILTA, visit their website at www.iltanet.org.

LegalSEC™ INITIATIVE

ISO CERTIFICATION

MOBILE DEVICE MANAGEMENT

securitya strong defense

SEPT | 12ISSUE 3

VOLUME 28

peerto

the quarterly magazine of ilta

peer

illustration by thomas boucher, all rights reserved

Sheetal Jain is the Chief Technology Officer and

co-founder of Prosperoware LLC. He has designed

and developed business solutions on the Microsoft

enterprise platform for over a decade. Sheetal was

part of the Microsoft developer feedback team for

SharePoint 2007, sharing insight on early releases

and product enhancements. More recently, Sheetal

served as an architect/development manager at

Interwoven/iManage, where he was responsible for WorkSite Web and WorkSite

for SharePoint. Sheetal can be contacted at sheetal@prosperoware.com.