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.
- Web Service Footprint Done against the UDDI ( Universal Description, Discovery, and Integration)
- Web Service Discovery Queried against the UBR (Universal Business Registry) in order to expose endpoints for service consumption
- 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.