Skip to main content
|
  Help (new window)

Elumenotion Blog

Go Search

 
Elumenotion > Elumenotion Blog > Posts > SharePoint REST (ODATA) is Insecure

8/10/2010

SharePoint REST (ODATA) is Insecure

SharePoint 2010 includes a number of new services to allow interoperability with other systems and to make it easy to create rich Internet applications. Among these is SharePoint's ODATA implementation provided by the ListData.svc service. Overall, I think the REST is an awesome lightweight alternative to formal SOAP. Unfortunately, the implementation SharePoint provides opens a large attack surface that makes it very easy to discover the information for every user in a site.

Unlike alternative interoperability services like the traditional SOAP based services and the SharePoint Client Object Model, you must access the ListData.svc with an account that has Browse User Information permission. Consider a scenario where you want to allow a system external to your organization to read and write items in a site. You can create a permission level that allows this interaction by granting:

  • Add Items
  • Edit Items
  • Delete Items
  • View Items
  • Use Remote Interfaces
  • Open

An account with this set of permissions allows the use of the Client Object Model and some of the SOAP services to the external system to read and write list items and documents. However, the account can't browse the site's contents because it hasn't got View Pages permission, nor can the account access information about the other accounts with access to the site.

SharePoint's WCF Services implementation, ListData.svc, will not work with the above set of permissions. To make it work, you must grant Browse User Information permission.

There are probably many scenarios where you can justify this, but I personally think that a data interchange technology that reveals the accounts with access to the data store is best avoided considering that the alternatives don't have this flaw.

I hope this is fixed soon, because I'd love to use REST with SharePoint and I will as soon as Microsoft makes it possible to harden SharePoint REST (OData) security. At the moment I think it would be irresponsible to do so in most of the scenarios where REST is attractive.

Author: Doug Ware

Posted at 10:48 AM by Doug WareNo presence information | Category: Lists | Permalink | Email this Post | Comments (7)

Comments

OData is secure

Hello Doug,
The information in this post is not correct, usually any HTTP request with the WCF service of any list is established based on the security context of the loggedin user.

Regards,
Mohamed Saleh - Microsoft SharePoint Server MVP at 8/26/2010 4:38 AM

Mohmed, Please Re-read My Post

I think you missed the point entirely! Of course the request is based on the security context of the loggedin user. The problem is that the security context must allow Browse User Information permission.

I am not saying it is insecure because it grants access to list items the user shouldn't see. It's insecure because it exposes a tremendous attack surface by revealing the information for every account on the site including the site collection administrators. An attacker still needs to brute force or socially engineer the password, but the service exposes half of the required information an attacker needs to break into the site.

If the server is connected to a domain it exposes enough information that the attacker can then use the account information to try to penetrate any publicly exposed sites or services over the internet including the ones that are other than SharePoint!
Doug at 8/26/2010 10:00 AM

Great information

This is valuable information.  I'm going to use odata just for my apps and make everyone 'outsiders' use soap.  Or maybe if they own all the permissions.  I think half the battle to a socially engendered attack is knowing who has access to what.  What's more is you can almost predicted the relationships.  These kinds of attacks are the most detremental because they most often acheive their goals without detection.


Thank you for bringing this into the world, I've been very excited about odata.  Still am really but have something g to be aware of that I didn't have to learn on my own.  It's a redicukous flaw that I would have never guessed.  Thank you.
StacyDraper at 10/31/2010 8:01 AM

Re-Mohmed, Please Re-read My Post

Hello Again,
You are right, i didn't notice your point...
I will check it out to see how to work around this issue!
 Mohamed Saleh at 11/6/2010 3:40 PM

sharepoint groups

isn't it best practice to put all AD references in SP groups anyway?

E.g. rather than granting access for domain\usergroup, i set up an SP group called 'My Users' and put in domain\usergroup, then I give access to sp group 'my users'.

If you've done this, then am I right in thinking that the information that is 'browsable' is just the name of the sharepoint group?

Not saying this isn't a massive problem - just wondering if this is a potential workaround...
ali robertson at 4/12/2011 6:08 AM

This permission is included in all acces levels

Further to my previous point, these are access level permissions in 2010. Note how all levels have 'browse user information'. It seems it's not possible to provide access to content without providing this information anyway?

http://www.sharepointdevwiki.com/display/public/SharePoint+Permissions

Ali Robertson - alirobe.com
Ali Robertson at 4/12/2011 6:12 AM

@Ali

Hi Ali,

Great comments!

The default associated goups on a team site are indeed associated with permission levels that contain this permission. It makes sense that they do because they are for sites to facilitate collaboration between users.

However, it is not required for access. Consider the Restricted Read permission level found on a Publishing Portal. It has Open, View Items, Open Items, and View Pages only. In other words, you can read a page that has author information (Created By, Modified By), but you can't traverse those fields to the User Information list.

I stand by my opinion... If the purpose of the REST interface is to provide lightweight integration between systems for access to information in SharePoint then it provides a big attack vector in its current form. The other service APIs do not have this same flaw. 
Doug at 4/20/2011 8:28 AM

Add Comment
Items on this list require content approval. Your submission will not appear in public views until approved by someone with proper rights. More information on content approval.

Title


Body *


Your Name *


Attachments
Follow me on twitter!
The Atlanta .NET User Group
MVP Logo
  Archive
  Archive (Calendar)
  Skinner Created Themes
  New Skinner Download
  New Skinner Tutorial
©  2009 Elumenotion, LLC  |   SharePoint Training, SharePoint Consulting and SharePoint Staffing
8075 Cavendish Place | Suwanee, Georgia 30024 | + 1 (888) 653-5021