Web Service Security And SharePoint

Web Services, SharePoint, and Building Business Data Interoperability

Web services are becoming increasingly more commonplace within every business environment in numerous industries, and are particularly common within a SharePoint environment for a variety of different purposes. With the introduction of any new technology, as web services are to several enterprises, always brings into light new security issues that must be dealt with. Although Web services provide excellent transfer interoperability with various types of business data to expose and serve in relation to our SharePoint portal, there is also the need to harden and secure these Web services in order to mitigate any risk to SharePoint as well other business applications.

Back to the Basics: What Constructs a Web Service

In order to understand how we can secure web services, we must firstly examine exactly what constructs a web service, how it interacts, and how it functions.

Web services are composed of two main pieces of functionality, two main actors in the aggregate process. There is the web service provider, which is going to provide the stream of data, and the other end of this relationship is the Web service consumer, which is the client which is consuming the provided data. Building on these two actors, there are four main pieces of technology that allow list type of beneficial relationship to exist. The first of these is the Universal Business Registry (UBR).

The Universal Business Registry is the piece of technology that will allow a user to query for specific Web services based on explicitly supplied criteria. It is the third party mediator between the consumer and the supplier, allowing a consumer a uniform location to look for Web services of varying natures provided by several different businesses. The UBR is typically the first player in the Web service process; a user will query the UBR and attempt to find a Web service defined by their unambiguous requirements. Once a user supplies the conditions to the UBR, the UBR will return a list of services that the user can consume, and the user will select the most appropriate Web service to their need. Throughout the UBR query process, the protocol that is being used is UDDI (Universal Description, Discovery, and Integration). This is the same protocol that is going to be used when attempting to start the foot printing process to begin to gather information about different Web services.

After Selecting the Service

Now that user has selected the service that they wish to consume it will ask the UBR to supply an endpoint for their selected Web service for proper consumption. Once the user has the endpoint it can effectively start consuming and leveraging the Web service it has selected coupling with a reader or other API of choice. This endpoint is built upon a technology called WSDL (Web Services Definition Language) which will describe how these services are structured deployed, accessible, and proper usability. Throughout this entire process the HTTP protocol that is being used is known as SOAP (Simple Object Access Protocol) which piggybacks on top of each CTP packets to provide the underlying communication that we need.

Similar to any other type of attack on a SharePoint portal, the first action a malicious user will take is to gather as much information and research as possible in order to gain a knowledgeable standpoint about their target.

Just like with any other Web asset, there are methods and actions that will allow the user to fingerprint and gain more insight into a Web service in order to properly structure an attack.

Why Application Layer Firewalls Just Aren’t Enough

The only way to ensure a SharePoint portal is properly secured is by ensuring that any information that we expose in the portal is also secured. SharePoint is a web application, and therefore will typically always function over the standard HTTP ports, 80 and 443. Web services also function at this level which provides a majority of there benefits over other methods of data transmission. But with this comes evident security issues. Because most security appliances and applications try to examine packets that transfer over other ports often times web servers traffic is difficult to decipher as benign or malignant because it functions exactness aim as a SharePoint a HTTP traffic.

The most typical way to protect a SharePoint environment is by implementing some type o application layer firewall. This application layer firewall typically does packet inspection on the varying types of traffic that are passed through it, however for the reasons described above and Web services acting as a HTTP traffic is difficult for a firewall to distinguish between malicious traffic.

Three Main Pieces

There are three main pieces an attacker will take when trying to maliciously expose a Web service for whatever purpose.

  1. Web Service Footprint Done against the UDDI ( Universal Description, Discovery, and Integration)
  2. Web Service Discovery Queried against the UBR (Universal Business Registry) in order to expose endpoints for service consumption
  3. Web Service Fingerprinting Done Against the Web Service discovery URL in order to expose the technology that builds the web service

The first portion of any attack is information gather reading. In regards to Web service is relatively easy for a user with little or no knowledge about a business to find Web services will by that organization. Although list type of data is typically in a protected repository because the purpose of Web services is to promote interoperability through an open standard it becomes increasingly easy for knowledgeable user to gain valuable insight into what organize a and start to gather relevant information.

The Four Structures of the UBR

When discussing how Web service at a very basic level works, one of the key components between a provider and consumer was the universal business Registry. As discussed the UBR axes the mediator allowing businesses a place to expose Web services and a client a place to search and determine methods to consume those exact same Web services. Just as a person can do a whois check against the public Registry in order to gain more insight into such things as IP addresses, a user can query that UBR in order to gain the same type of insightful information. But there are several different queries that a user can in bulk on the UBR in order to gather some information. The four structures that are available are the business entity, business service, binding template, and the technical model also known as the tModel. How users will interact with the UBR is typically provided through an application programming interface supplied by the same company that provides the Web service. Since the protocols that are being used for this type of transmission are HTTP and SOAP, these application programming interfaces will have direct hooks into the same types of protocols. The API will incorporate into the W. STL in order for the user to extract the endpoint information so that they improperly consume the Web service. Since while we are foot crane we are attempting to gain more insight into a specific Web service is necessary to leverage these application program interfaces.

When beginning to footprint process just like a normal user we are going to query the universal business Registry in order to expose a list of all available Web services. The first that in actual footprint process is Web service discovery in order to expose the endpoints. The endpoint will contain the most relevant information about the Web service including the IP host address as well as other information about the location of specific resources. Without having this endpoint information the process of information gathering is infinitely more difficult and will not allow a user to enumerate through the different Web service information.


Item Level Security Model (ILS), Securable Objects (SO), and Content Structure (SharePoint Site Definitions, Lists, Features, and Solutions)

One of the largest causes for complaints in previous versions of SharePoint was the lack of Securable Objects (SO) that existed only allowing end-users the option of securing items at the library level. Within SharePont 2007, this concept of Securable Objects is exposed and allows end users the option to bind a specific identity to a specific object. There are several different objects within MOSS that are allowed as securable procuring an environment that allows a very granular level of permissions:
  1. Web (Site)
  2. Library
  3. List
  4. Item
Therefore, a user can come into a site and bind identities to any of these arbitrary objects. For example, consider the following scenarios. There are several OOB permission levels that exist:
Permission Level Permission Level Description
Full Control Has full control.
Design Can edit lists, document libraries, and pages in the Web site.
Contribute Can view pages and edit list items and documents.
Read Can view pages, list items, and documents.
Limited Access Can view specific lists, document libraries, list items, folders, or documents when given permissions.
Approve Can edit and approve pages, list items, and documents.
Manage Hierarchy Can create sites and edit pages, list items, and documents.
Restricted Read Can view pages and documents, but cannot view historical versions or review user rights information.
SharePoint however allows you the option of divvying these up into groups, that you can use to more easily manage the access that is granted to your site. These groups follow the concept of AD groups in terms of aggregation, but are vastly different in functionality since they are exiled to exist at the SharePoint level. When using Secured Objects, you can optionally bind a group instead of an individual person:
Permission Level Permission Level Description
Approvers Members of this group can edit and approve pages, list items, and documents.
Designers Members of this group can edit lists, document libraries, and pages in the site.
Hierarchy Managers Members of this group can create sites, and they can edit pages, list items, and documents.
Quick Deploy Users Members of this group can schedule Quick Deploy jobs.
Restricted Readers Members of this group can view pages and documents, but cannot view historical versions or review user rights information.
Members Use this group to give people contribute permissions to the SharePoint site.
Owners Use this group to give people full control permissions to the SharePoint site.
Visitors Use this group to give people read permissions to the SharePoint site.
NT AUTHORITYAuthenticated Users Windows builtin user groups which represents authenticated users.
Each of these will have an association by default to the permission levels mentioned before that are rolled out by default. This allows the structure of a typically environment to be setup initially with little or no work.
SharePoint Group/Permission Level Full Control Design Contribute Read Limited Access Approve Manage Hierarchy Restricted Read
Regular website                
Approvers         X X    
Designers   X     X      
Hierarchy Managers         X   X  
Quick Deploy Users         X      
Restricted Readers         X     X
Members     X          
Owners X              
Visitors       X        
NT AUTHORITYAuthenticated Users         X      

Scenario of Multiple Users and Item Level Security

We have two users, user A and user B, both heavy users of our collaboration environment running MOSS (SharePoint 2007). Both of these users are in different divisions and geographical disparate locations, user A is a member of the marketing group, and user B is a .NET developer, however the have been merged into a project group who is going to develop a custom SharePoint WebPart for reporting on marketing trends with regression analysis. The site is setup with the following SharePoint assets:

  • An announcements list for important project announcements
  • An event list for team building events
  • A task list for overall project tasks
  • Two document libraries, one for functional design specifications and the other for performance reports for management metrics
In order to orphan this site from the rest of the collaboration environment so only the users that need access to it can get to it, in the current context, user A and user B will be the only people to access the site, therefore we can either make a group for them and add them to it after assigning the appropriate permissions, or explicitly add them as users, with certain permission levels, to the site.

Afterwards, there are sensitive materials that are being placed into the collaboration environment, notably things that the developer might not need the marketing group to see, and things that the marketing group may not want the developer to see. Recall that there are two document libraries in the site, one for development functional design specifications and another for performance reports that the marketing department as the project sponsor are going to submit to management regarding the work done by the developers.

In the development document library, we are going to detach permissions from the parent so that unique identities can be bound to the library or object in the document library. For a functional design specification, there are typically two versions that developers have, one is “sanitized” and another is “dirty”. Dirty functional design specifications are usually what developers use between them selves since the linguistics in it may be past the comprehension of the client, therefore, we would bind the unique identity of this document by selecting “manage permissions” of the object and setting it to the developer’s account. Firstly, select the appropriate manage permissions link from the context menu of the object in order to bring up the “Permissions” page which will allow us to breakdown and assign permissions at a very granular level.

Site Definition and List Breakdown Structure
Site definitions (STS and MPS, along with the SPS prefixed definitions) were the most typical way in WSS 2.0 to provide flexibility and control over an entire site, from design to WebPart provisioning through the ONET.xml file. Site templates, although manually heavily to make modification to either the ASP.NET WebForms or relevant XML files were the most beneficial option in terms of performance, and give power over the overall feel and functionality of the site. Those that have worked with these before know of the pains of working with CAML (Collaboration Application Markup Language), in terms of validation and testing modifications and enhancements, and the repetitive changes that are needed to promote uniform branding across relevant files.
The Two Largest Differences in MOSS
The two largest changes to the concepts of site definitions are the introduction of features and solutions, each which serve a very different purpose, making SharePoint site developers lives much easier. In order to create a site definition in WSS 2.0 it was often necessary to copy the complete site definition file, i.e. making a copy of the STS folder and renaming to something more relevant to your project task, and then making a new WEBTEMPS.XML file that would allow SharePoint to become aware of the new directory in order to populate it to the templatepick.aspx page. This causes the creation of an entire new site, and therefore a fair amount of work to complete the task of creating a new site. The introduction of features cuts down on the amount of work needed for a developer to introduce changes into the SharePoint environment by componentizing packages to push against a site. Developers will be comfortable with the environment of a feature, since it highly resembles that of a site definition with the similar file formats, XML files based off of CAML and ASP.NET WebForms. Instead of having to create a new site definition however to create a list template, or make modifications to the default WSS site directory, features allow you to package one change, and deploy that change to single, or multiple sites depending on your requirement.
The Old Way Of Doing Definition Switches
Many people are aware of the trick to switch a site definition by making the modification to the Site ID in the _SITES database in order to convert an existing site, which carries its own implications since it is not a supported Microsoft technique and is not always 100% effective. Features however solve this paradigm by allowing you to apply them for an existing site, on any site that exists within a farm. The method of deployment can vary depending on requirement, however can be done through:
  • Command Line
  • Code
  • GUI
This obviously has implication in how development of site definitions should be structured and planned, since features can be referenced across a farm from any site. List types can be spread and referenced from differing sites, therefore allowing a container of reusability and cutting down on the amount of work required for a developer to make sites and site collection that are more intelligent and tiered towards business purposes. As a developer, this is a must have feature that has immediate ROI. Typically, to make new types the process described above (copying the STS site definition etc.) is needed if you simply want a new list type, however leveraging the WSS 3.0 allows you to solely develop a singular features without having to make new definitions, and extend these references to the feature throughout differing portion of the farm.
Deploying New Site Definitions
Developing and deploying features is not that different than creating new site definitions, so should be familiar to those who have created site definition in WSS 2.0 (besides the introduction of the 12 hive). Features in WSS 3.0 are created by creating a folder in
C:\Program Files\Common Files\Microsoft Shared\web server extensions \12\templates\features
When you create a new folder, you can place all the relevant features files that you wish to include, however the one file that MUST exist is the feature.XML. The feature.XML file is the basis for the entire feature, providing the structure of the feature by exposing base properties and other supporting features. Within the feature.XML file, you can point to other relevant assets that will build up your aggregate feature, such as rendering resources or assembly files. Your feature file can also only contain the feature.XML file, depending on the requirements of your project and what type of logic is needed in order to complete the requirements of your feature.
Breakdown A Feature, and Then Build A New One
Features are really easy to dissect because typically unless it is a very intensive feature the amount of files that exist within them is very, very small. As mentioned before, this may be just the feature.XML file which is the only file that is actually required for the feature to be implemented within the SharePoint 2007 environment. Provisioning this file out into your environment as described above is rather easy and unproblematic, and can be done in a variety of fashions depending on user preference.
Before you get started writing the feature though, it is best to define who exactly you are tailoring to write the feature for! Is it for a site? Is it for the whole server to be able to active? (Remember, this is going to be available for users throughout the SharePoint GUI so it is best to plan the feature scope.
There are four main kinds of scopes that exist in relation to features, Site, Site Collection, Virtual Server, and Server Farm. The differences should be rather apparent; however for the sake of being complete, here is a little breakdown.
Assume you are developing a list feature that establishes a different type of view that applies to a product inventory list within your company. This feature doesn’t have much application in relation to other sites since this list really only exists at one site within your entire environment, most likely on your inventory management site (or site collection, which we will get to in a minute).

Solutions, Site Definitions, and Features

The other major change that exists within site definitions is that of a solution, whose structure should be very familiar to WebPart developers. The idea of a solution replaces that of using a .CAB file (deployed typically using the wppacker method) for a WebPart deployment, and extends the possibility of packaging other SharePoint assets such as site definitions. So why should the structure be familiar? Within WSS 2.0 a WebPart typically had a manifest file, and .dwp, and a related assembly that acted as a container of business logic. The .dwp played the role of establishing the connection between the presentation layer and the assembly describing things such as Title, TypeNames, and Assembly Names. The manifest handled many roles most importantly that of making the safecontrol entry into the web.config file so that the WebPart could actually run correctly. Within a solution, the same context of using an XML file within a .CAB solution which can describe the package and method of unpackaging and delivering the assets onto the server. Typically however with WebParts, the wppacker method had to be run to drop the assembly and relevant assets onto the front end web server. This is no longer the case, since the WSS 3.0 as described in other sections is more dependent on the database for storage of assets that would otherwise be stored in other location in WSS 2.0. When the solution is deployed onto one of the servers into the farm, it is housed within the configuration database, after which a job is tripped which will deploy the WebPart to the remaining front-end web servers that exist within the SharePoint farm.

Auditing List Changes With A Workflow

A common requirement within a collaborative environment is to implement a workflow for critical assets to be routed and intelligently automated throughout an enterprise. More often than not, this is a Microsoft Office document of some nature, and in most businesses this is typically a Microsoft Word document. Encompassing certain documents and tasks within a defined and standardized process is something that is typically a largely manually task, often resulting in redundant information being sent to both parties. This process could also be largely housed within persons head, not transparent to the rest of the parties involved in the business processes, and therefore remaining loosely defined and subject to several mistakes.

Windows Work Flow Foundation (WinFX/.NET 3.0)
WSS 3.0 however solves this common dilemma by introducing new technology called Windows Workflow Foundation (WinFX) which forms a basis of methods at a workflow developer’s disposal to build intelligent foundations to automate these business processes. There are all types of workflows, which break down further when examining how the workflow is supposed to be structured around the human element. The two workflows that are supported on the WSS 3.0 platform are sequential and state machine workflows, both of which can be tailored around arbitrary business processes, however the latter being well-suited or tasks that largely involved a human element. Sequential workflows are like a software development lifecycle; you define requirements, build the software, test, and go production with the push build. It builds a series of events up that in turn will happen one after another, executing when one event expires. A state machine workflow exists on different states, an event may occur is a certain state is adjusted whereas that same event may not occur, establishing a grey area and therefore the introduction of the human element.
Using a workflow within a SharePoint site can be extended in many different fashions, such as on a document that exists within a document library or on an item that exists within a list. One of the most typical processes is an approval routing workflow, whereby a document is sent between different parties to achieve signoff until it hits executive signoff to end the workflow. This can be routed in multiple ways, through serial, where a document goes one by one through a workflow route or through a parallel (also known as shot gunning), where the approval is sent to multiple parties or signoff after an event is tripped. Assume that there is a sales document that has to go through multiple parties, originating at the sales department, but going through the graphics department for design, marketing department for corporate conformity checks, financial department for verification of metrics and statistics of the document, and finally getting executive sign off before the document goes production. This is an example of a serial route, where the document will be routed to each department in a single step fashion, getting sign of until it reaches executive management where the final threshold of the workflow is satisfied and the cycle ends.
The built in workflows when first using WSS 3.0 are fairly rudimentary, however let you explore the options that are available when exposing Windows Workflow Foundation since they are built upon the same technology. One of those workflows is the example given above, setting up an approval route on an arbitrary document that you wish to route through your company in a fashion that you deem appropriate based on the given requirement.
Workflow Across Relevant MS Sister Server Systems
SharePoint by design has always had the ability to integrate with sister server platforms offered by Microsoft, and Windows Workflow Foundation provides the same types of facilities. Because Microsoft Exchange has close ties with how workflow functions within a company, it also provides the hooks so that the workflow can be integrated across relevant client applications. This extends further to the entire 2007 Microsoft Office suite, allowing you to build workflows intelligently integrated directly into your office applications.
Windows Workflow Foundation Run-Time Engine
The heart of SharePoint workflow is run by a component known as the Windows Workflow Foundation Run-Time Engine, the same entity that is responsible for the generation of workflow elements as they exists within the entire WinFX engine. The reason that there is one entity that is the heart of WinFX is that it is specifically built to keep active during periods off activity that other programmatic elements might have trouble surviving in, such as when your SharePoint server reboots. In essence, WinFX plugs into SharePoint similar to a puzzle piece, there are two sides of the equation that are unique to each other but they have common sides that are provided by both ends. The workflow however is the base piece, it is the base engine whereas SharePoint is the higher level functionality that plugs into this workflow to implement its own custom routines. It is possible to mimic this type of functionality through the SharePoint API and exposing programmatic elements as thus, so you are not restricted to building just one type of workflow to conform to a SharePoint standard. This is my task right now!
Fortunately, creating these workflows is easy through the Visual Studio 2005 interface, there is even a visual designer that cuts down significantly on the programmatic effort that is required to do so.

SharePoint Security Monitoring Policy Template

This file was edited for correctness by Edgardo Gonzalez of PSLR.

Introduction – SharePoint Server Monitoring Policy Security Monitoring is a method used to confirm that the SharePoint security practices and controls in place are being adhered to and are effective for the SharePoint environment.

Monitoring consists of activities such as the review of:

  • Automated intrusion detection system logs
  • Firewall logs
  • SharePoint User account logs
  • Network scanning logs
  • SharePoint Application logs
  • SQL Data backup recovery logs
  • Help desk logs
  • Other log and error files
Purpose The purpose of the SharePoint Security Monitoring Policy is to ensure that SharePoint security controls are in place, are effective, and are not being bypassed. One of the benefits of SharePoint security monitoring is the early identification of wrongdoing or entrance of new security vulnerabilities. This early identification can help to block the wrongdoing or vulnerability before harm can be done, or at least to minimize the potential impact. Other benefits include Audit Compliance, Service Level Monitoring, Performance Measuring, Limiting Liability, and Capacity Planning.
Audience The [Organization] Server Monitoring Policy applies to all individuals that are responsible for the installation of new SharePoint property, the operations of existing SharePoint property, and individuals charged with SharePoint security.
SharePoint Server Monitoring Policy Automated SharePoint security tools will provide real time notification of detected wrongdoing and vulnerability exploitation. Where possible a security baseline will be developed and the tools will report exceptions. These tools will be deployed to monitor:

  • LAN traffic, protocols, and device inventory
  • Electronic mail traffic
  • Operating system security parameters

The following files will be checked for signs of wrongdoing and SharePoint vulnerability exploitation at a frequency determined by risk:

  • Automated intrusion detection system logs
  • Firewall logs
  • SharePoint User account logs
    Network scanning logs
  • System error logs
  • Application logs
  • Data backup and recovery logs
  • Help desk trouble tickets
  • Telephone activity – Call Detail Reports
  • Network printer and fax logs

The following checks will be performed at least annually by [Organization] assigned individuals:

  • Password strength
  • Unauthorized network devices
  • Unauthorized personal web servers
  • Unsecured sharing of devices
  • Unauthorized modem use
  • Windows Operating System and Software Licenses

Any security issues discovered will be reported to the [Organization] appropriate management for follow-up investigation.

SharePoint Server Monitoring Policy Supporting Information
  • Access to, change to, and use of SharePoint Account Managmenet Policy must be strictly secured. SharePoint information access authority for each user must be reviewed on a regular basis, as well as each job status change such as: a transfer, promotion, demotion, or termination of service.
  • The use of SharePoint must be for officially authorized business purposes only. There is no guarantee of personal privacy or access to tools such as, but not limited to; SharePoint areas, WSS team sites, any and all collaboration and communication functionality, and any sister sever integrations (i.e. integrated Microsoft Exchange environments). The use of Sharepoint and SharePoint related tools may be monitored to fulfill complaint or investigation requirements, including forensic an analysis into IDS or other security systems. Departments responsible for custody and operations of the SharePoint servers (custodian departments) shall be responsible for proper authorization of SharePoint server utilization, the establishment of effective use, and reporting of performance to management.
  • [Organization] server custodian departments must provide adequate access controls in order to monitor SharePoint systems to protect business data and associated programs from misuse in accordance with the needs defined by owner departments. All SharePoint access must be properly documented, authorized and controlled, following [Organization] standardized processes.
  • All [Organization] departments must carefully assess the risk of unauthorized alteration, unauthorized disclosure, or loss of the data within the [Organization] SharePoint environment for which they are responsible and ensure, through the use of monitoring mechanisms such that [Organization] is protected from damage, monetary or otherwise. SharePoint owners and server custodian departments must have appropriate backup and contingency plans for disaster recovery based on risk assessment and business requirements.
Disciplinary Actions Violation of this policy may result in disciplinary action which may include termination for employees and temporaries; a termination of employment relations in the case of contractors or consultants; dismissal for interns and volunteers; or suspension or expulsion in the case of a student. Additionally, individuals are subject to loss of [Organization] SharePoint access privileges, civil, and criminal prosecution.
Compliance / Regulation Contributed to by this Policy
  • Copyright Act of 1976
  • Foreign Corrupt Practices Act of 1977
  • Computer Fraud and Abuse Act of 1986
  • Computer Security Act of 1987
  • The Health Insurance Portability and Accountability Act of 1996 (HIPAA)