Malicious Sandbox Solutions in SharePoint 2010 – my private data has been stolen!
We all know about the existence of Sandbox Solutions in SharePoint 2010 and why you would want to use it. We also know that server side code running in the Sandbox is very restricted. Things like accessing the server’s file system, using the SPSite constructor, sending e-mails, making web requests, plus loads of other actions cannot be performed when running in the Sandbox for the sake of security.
It is easy to start thinking that Sandbox Solutions cannot do too much harm and that any damage done stays within the walls of the Site Collection. The aim of this blog post is to bust this myth and make people aware that they are still responsible for validating the contents of any Sandbox Solution they activate on their Site Collection.
What if I told you I have developed a Sandbox Solution that upon activation collects documents and list data from your site collection and sends it to me, the evil developer, outside your Site Collection walls? Would you be surprised to hear this is possible? I think many people would be.
It is possible.
- Evil Dev produces Malicious Sandbox Solution
- Site Collection Admin uploads and installs Malicious Sandbox Solution
- Malicious Sandbox Solution collects private data from Site Collection and sends its to Evil Dev
Now it’s time to see it in action.
For obvious reasons I will not post the full source code, but I am happy to explain how it works.
I am assuming all of the code runs under the context of a Site Collection Administrator.
Let’s leverage the “Save as Template” functionality as used in /_layouts/savetmpl.aspx to produce a WSP that contains the site with all its contents, including documents in document libraries and lists with data. The first hurdle we need to get past is to figure out how we are actually going to achieve this, since SPSolutionExporter.ExportWebToGallery() is not available in Sandbox Solutions. One way to hack around this is to use jQuery to perform an AJAX POST to /_layouts/savetmpl.aspx providing all the POST parameters that it expects. Remember, HTTP is stateless. We need to perform an initial AJAX GET to /_layouts/savetmpl.aspx to obtain the values of __REQUESTDIGEST, __VIEWSTATE and__EVENTVALIDATION so we can trick ASP.NET into thinking that the POST we are about to perform originates from a user looking at /_layouts/savetmpl.aspx in his browser. All the other post parameters that the page expects to receive as part of a POST can be obtained using Fiddler as we perform a manual form submit through the browser on /_layouts/savetmpl.aspx
Step 3 - Send template data to a remote server
I don’t think there is anything technically wrong with the security model of Sandbox Solutions. The point I am trying to make with this blog post is that even though there is a lot of stuff that cannot be done from within a Sandbox Solution, there is still quite a lot of stuff that can be done -which can be seen as good or bad!
Do not blindly trust a Sandbox Solution. As Site Collection Administrators, we are still responsible when it comes to assessing and validating the trustworthiness of a Sandbox Solution and its source.
What about custom Solution Validators? You could use these to only allow certain pre-approved or signed Sandbox Solutions to be activated for example, but it comes at a price. You compromise on business agility in order to increase security. Kind of reminds me of Farm Solutions…