I'm excited being an Office 365 Architect/Developer in these days... I can't seem to wrap my head around where MS wants to go when it comes to allowing SAFE customizations of SharePoint in Office 365.
To show you why I'm confused I'm going to walk you through a scenario where "anyone" with the rights to customize a SharePoint page can "take over" all SharePoint sites in an Office 365 tenant. I'm not talking about just one site but eventually all site collections in the whole tenant.
If you are a big company with (tens of) thousands of sites and site collections you should be worried about this. The reason being you probably have tens of thousands of employees and some of them are designing their team site for their team to collaborate on. This is pretty much the selling point of SharePoint right? And you hopefully have enough to loose to take security seriously.
I'm going to walk you through all an attacker have to do to make this happen. I'm doing this because I want to raise some awareness in the "developer/consulting" community about why isolated Add-in webs and OAuth permissions is a good thing and why the upcoming SP Framework is a complete disaster when it comes to security... I'm not hearing anyone raising these questions in the community. Everybody just seems stoked about finally being able to do whatever we want in the host web with the latest tools YO man... To be fair what I'm going to walk you through has nothing to do with SP Framework it can be done right this minute in Office 365. What confuses me is that there is only one setting that can prevent this from happening and that is to disallow ANY script customizations in your tenant.
Since we are not worrying on waiting for the SP Framework to be released we will just look at how an attacker can customize a web part page directly by adding a script web part and point it to an external script hosted on a CDN. But the important point I'm trying to make is. If SharePoint today is so vulnerable to this type of "attack" why is it that MS is all of a sudden doubling down on the exact same architecture for their "NEXT BIG" development story??? Why don't they spend their effort on improving the Add-in story which is by far the most secure way of customizing Office 365.
This is how the "attack" works.
2) The customized page needs to be visited by users with additional rights. This can be accelerated by social hacking, the attacker could send an email to some admin asking for advice on the performance or similar. Let me stress this, the ONLY thing needed is for the page to be VISITED by someone with the "proper" rights.
3) Once the page has been visited by a user which is a site collection admin the script will try to inject itself via a ScriptBlock UserCustomAction so it will be executed on all pages in all sites in that site collection. The script will first run a search query to get all site collections that the visiting user has access to and that is available in the search index. It will iterate through all these site collections querying for a specific CustomAction. If this action is not found it will add it to the site collection. This script, being loaded by the CustomAction, will add a hidden iframe on all pages loading your attack page. Thus the rogue script will execute the above scenario for ALL visitors to ANY page in this site collection without them even knowing that they have loaded the rogue page. To make matters worse the attackers site will probably trend in Delve so more people are accessing the site.
As time goes on the attacker will eventually have injected the rogue script in all sites across all site collections in the tenant. What they decide to do with all this access is up to them. They could just add their own account to all sites granting themselves access. But this has the drawback on exposing them when people audit access. Another way would be to send over documents and data as well as user interactions to an external CORS enabled service.. All this happily executing in the "background" without anyone knowing about it.
Let us stop for a while and see how this is possible by just having people visiting their page.
The same origin policy only takes into account the domain from where the script was loaded. In Office 365 all your site collections sits under the same domain name. There is no such thing as HNSC inside your tenant. Because of this you can freely execute xhr requests across MOST site collections. Did you ever wonder why MS isolated "my sites" under a different domain name? If they hadn't done that it would be even easier to carry out this "attack". The attacker wouldn't have to be trusted by someone else to edit pages in a site collection different from your own, they would use their own.
Not only can the attacker read data across site collections they can also UPDATE state since MS exposes an endpoint to get a valid requestdigest value for any site in any site collection. This is how they can update UserCustomActions across site collections. In all fairness it is possible to screen scrape that value if MS didn't provide an endpoint for it.
Framing pages is also honoring the same origin policy so there is nothing stopping the attacker from embedding their rogue page in an iframe on pages in different site collections. They don't have to embed an iframe since they already own the page but it makes the design a bit easier.
I do hope YOU care if you are the CIO/CTO of a company that actually has assets stored in SharePoint that you want to know is only accessible by people that has the proper permissions to access it. At the same time you might want to add customizations is a SAFE way.
How will MS secure the service with the new SP Framework being rolled out? I have no idea except they will add the capability for a tenant admin to specify a white list of domains from where content can be loaded. Content-Security-Policy Why this hasn't been done long ago I'm not sure...
I have a strong feeling that there will be NO ISV support around the new SP Framework. ISVs won't be able to sell any framework solutions in the marketplace. It is inherently "insecure" and only trusted developers should be able to install these kinds of solutions. But how do you know to trust someone?
And should you trust someone that thinks that the SP Framework is the greatest thing coming out of Redmond in a long time?