Wednesday, June 12, 2013

SharePoint: In Defense of Cross-Site Scripting Attacks


Microsoft introduced SharePoint in 2001.  Originally designed as an intranet for team collaboration and content management, SharePoint has evolved with every new version and enterprises have found additional innovative ways to customize it and manage their line of business applications, to some SharePoint is considered a Web Application.

Today we can find several solutions for help desk, wiki sites, blogging, proposal management, resource and project management, emergency response application, to name just a few, which are all based on SharePoint.

The popularity and functionality of Microsoft’s SharePoint continues to increase. In 2009, it generated $1.3 billion in revenues from an installed base of 100+ million users and it has been growing at a rate of 20,000 SharePoint users per day, every day for the last five years and that’s over 7 million new SharePoint users every year. [1]


SharePoint 2013


Microsoft’s CEO Sever Blamer’s referred to it as "… the definitive OS or platform for the middle tier,.." [2] in his keynote address at the Convergence conference on March 14, 2007, and whether you think of it as a Web OS or simply an Enterprise Information Portal its complexity becomes apparent when you take notice of all the underlying technologies that supports it.

SharePoint is built primarily on Visual C#, Visual Basic, Microsoft .NET Framework, ASP.NET, HTML/CSS, Document Object Model, Silverlight, it interfaces with Microsoft Active Directory, but it can be configured with LDAP, and is designed for use with Microsoft SQL Server and Internet Explorer. Consequently is not without its share of security vulnerabilities.

In fact there has been at nearly 300 vulnerabilities affecting SharePoint and related products over the years many of which have been cross-site scripting allowing remote attackers to inject arbitrary web script or HTML code via crafted JavaScript elements. [3]

One defense mechanism that Microsoft has integrated in SharePoint to protect users against cross-site scripting attacks is the inclusion a form digest for each ASPX web page requested.

The form digest is a security validation specific to a user, site, and time period. It is generated for each HTTP Request and placed on the ASPX page before serving it; it will then get validated on the server side when the user submits the form.


Form Digest embedded in the HTML Form

This mechanism is a feature available to developers who create new Web Pages with just a simple point and click.

Developers have also the option to create their own custom web pages but careful consideration needs to be taken care of to avoid security validation errors, which result in Exceptions errors being thrown out.


Security Validation Exception Error

The way to correct this is by including the appropriate controls in the ASPX page [4], which will instruct the server to create, include, and manage the form digest


ASPX FormDigest Tag

An SPWeb.ValidateFormDigest or SPUtility.ValidateFormDigest [5] method can then be invoked to explicitly check the security validation used in the ASPX page, and works on a second page on which the first ASPX page posts or on the first one, if there is no second page involved.

This mechanism help developers build their own HTTP POST requests to submit and update SharePoint data, but how can we submit data to the server using HTTP GET requests?

The solution is not without some level of risk. The object model provides developers with a method to instruct the server to bypass the form digest validation by setting the AllowUnsafeUpdates [6] property of the SPSite object to true.

However, setting this property to true opens security risks, potentially introducing cross-site scripting vulnerabilities as noted in the remarks for the class reference, so it must be reset programmatically as soon as the update has taken place.


AllowUnsafeUpdates


Several events can also reset the property and prevent the update to the database [7], [8]:

·      SPRoleDefinitionCollection.BreakInheritance ()
·      BreakRoleInheritance ()
·      ResetRoleInheritance ()
·      An Exception being thrown out

The cross-site scripting protection just described may result in errors if you are writing server-side code not necessarily designed to respond to a POST Request.

If your web pages are designed to respond to a GET Request [9] or if you are creating your own SPSite or SPweb objects using the SharePoint object model and you are required to update the database you must then use the AllowUnsafeUpdate property prior to executing the update.

There are also instances in which you may not be updating the database but instead calling functions, which in turn perform a database update. One such case is the call to EnsureUser () which looks for the specified user login in the Site Users collection and if the login is not found then SharePoint looks to see if it is a valid user in the Active Directory, if it is it then adds the login to the Site Users collection resulting in an update to the database.

In case like this you must also make use of the AllowUnsafeUpdates function and set it to true, but remember to always set it back to false --or at least to its previous state-- after the operation is complete, so that other code in your program will not run in unsafe mode.

Many examples I have found on posts on the web, reset it right after line of code executing the database update and sometimes fail to consider exception errors, therefore is always a good idea to reset its value in the finally block of a try and catch. [10]




Use of finally block to ensure reset to unsafe updates

References:











For additional
SharePoint or Project Server
related articles please visit my website at: