Blog

Oct 06
Full trust JavaScript #SPFx

​​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.


The SP Framework talks about "full trust javascript" and that is exactly what we are talking about here. Any script that has been injected on the host web runs with whatever permissions the user accessing the page has. If it is your tenant admin accessing the page the script has the rights of a tenant admin. If it is your CEO it has the rights of the CEO and so on...

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.

1) The user performing the attack needs to be able to edit a SharePoint page. The user will add a script editor web part or similar loading a rogue javascript. This script can be located in SharePoint or on an external CDN. No tenant admin or site collection admin is ever involved here with the chance to make a decision on whether to allow this customization or not. All that is needed is the ability to edit the page. Compare this to today's Add-in story where you can't sell Add-ins in the store if they require more than "Manage permissions". 

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.

So all this is possible today no need to have to wait for the new SP Framework. It is obviously one of the selling points of SharePoint that you can customize it :) But my point is the way you customize it is inherently unsafe today. As I said in the beginning MS did a fairly good job designing the Add-in framework. They came up with a way to safely customize SharePoint with JavaScript. They even bent over backwards giving us SharePoint hosted Add-ins. We as developers have to understand and appreciate all the effort that was put into this architecture and WHY they did it this way. The did come up with a story for ISVs and third party developers on how to monetize by building Add-ins for SharePoint. What boggles my mind is that it looks like MS is giving up on providing us with a better Add-in framework with more features. Instead they are saying: "knock yourself out" here is how you can add your external scripts right onto the host page, we don't care.... And where do MS leave ISVs here? Don't they think that their service will benefit from third party Add-ins? Or are they so satisfied with the current state of the Add-in model that they ​think it is "feature complete"???

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.

MS is fully aware of these "problems" and by the look of it someone is trying to "lock down" the service. All "new" experiences we are getting are locked down. No UserCustomActions are being loaded in the new Document library or Sites UX. But why can't MS be open about the "issue". Tell us that injecting javascript will eventually not be allowed in the service except if you choose to stay with the old experience.

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?


Oct 27
Install SharePoint on Windows 10

UPDATE

If you want to install SharePoint 2016 on Windows 10 use this installer. Follow the steps here and additionally you MUST install FTP support.

ftp.png


We have updated our installer to support installing SharePoint 2013 on Windows 10. As always you need to understand that this is COMPLETELY unsupported by MS but since we know how to do it here it is.

win10.jpg
​You should follow the previous post to install IIS and WIF. This MUST be done BEFORE starting the prereq installer. And don't forget that SQL server ;-)​


Once you have done this download the Windows 10  ins​taller. This installer will take care of the bug in SharePoint setup​ where it complains about needing .NET 4.5 when .NET 4.6 is installed. So if you have that problem on a server you can use the launcher instead of having to uninstall 4.6. It is impossible to uninstall .NET 4.6 from Windows 10 since it is part of the OS.

Enjoy.

Sep 05
The case for not touching the master page

Nobody is asking the "stupid" questions so I will.

lala.jpg

​If you like me have spent some time in "la la land" lately you have heard that we shouldn't modify the master page in Office365. The reason being MS will push out new functionality via the master page.

At first I just nodded my head and I thought that this makes sense. But then I started thinking... What was one of the selling points for ASP.NET? If I remember correctly it was something called server side controls. I think you can use them to encapsulate functionality. So this completely wild idea came to me that what if MS would actually encapsulate the Suite Bar into a server side control wouldn't that be suite... Now this control is part of the master page and MS can ​update it without having to touch the master page. ​They can actually encapsulate more stuff if they choose to. I personally find the SharePoint master page kind of disorganized.

You know when I start thinking all bets are off​, I have a hard time stop thinking. My mind comes up with all kinds of (wired) stuff. So the next thought that came to my mind was, what if WE own the master page and MS has to use all these server side controls and delegate controls to inject their "stuff". That would be next to impossible.

But who am I to judge.... 


Sep 03
Your local facebook

Imagine that you could download your personal copy of Facebook. You install it locally and you start tinker around just to find the weaknesses of the "real" Facebook. That would really be awesome wouldn't it?

reverse.png

I hope the "foundation" (no pun intended) of the SharePoint2016 version is NOT the one running in the "cloud" let's hope I have been a complete idiot thinking that... I now know why the guys and gals in Redmond have such a tough schedule, they are in fact building two versions..... Really?

Aug 19
POC Bypass SharePoint Add-in permissions.

After I published my last post about SharePoint Add-in permissions being broken I got a few requests about explaining this in more detail and showing what this actually means.

Take a look at this video to get an understanding on what this really means. Like I state in the video it is important to understand that this SharePoint hosted Add-in is using assets that are stored on a CDN that are out of reach for the customer and MS. The Add-in can be distributed globally from the Office marketplace and during the review process it will be all "kosher" and after it has been approved the author can freely update the functionality. If the publisher has bad intentions it is a live "stealth" virus. The Enterprise installing the Add-in has a FALSE sense of security since it clearly stated it's permission requests and they are only Manage permissions on the Web.....

We are now in a state of total meltdown, licensing doesn't work​ but much worse the security model doesn't either....

 


I'm going to post all the sourcecode here so that you can take a look and fully understand how it works.

Lets walk through how all this works. The main idea is to inject script on the host web so that we get a communication channel between the Add-in and the host web. All script that executes on the host web runs with the permissions of the logged in user and SharePoint can't do ANYTHING about this. That is why MS don't allow Add-ins that requires FullControl permissions to be sold via the marketplace. An Add-in with FullControl doesn't have to resort to all these tricks since it can just do a "cross domain" call and inject a script using the REST API or JSOM. 

Almost all patterns and practices samples need FullControl permissions since they do all kinds of manipulation of master pages and scripts. And I assume that people are aware that these are highly priveleged actions. An Add-in with FullControl at the Web level should be treated by you as having FullControl at the SiteCollection level too. Because of this MS doesn't allow them to be sold through the marketplace

communication.png

The picture above shows the flow. The Add-in part is "isolated" in the iframe loaded from a different domain so no direct calls can be made from the IFRAME to the host window. But after injecting script on the host web using a user custom action we get a communication channel between the windows. My POC is using pmrpc.js (post message RPC).

A few hours later....

Vesa Juvonen has my RESPECT a fellow Scandinavian "getting things done", we have all read his amazing BLOG and he is on top of things, he contacted me right away. We just had a Skype call and all you ISVs and "would be ISVs" that have been using JSLink in your Add-ins AND selling through the marketplace your time has come. What I'm utilizing here is a MAJOR security hole and it will be closed ASAP. I really do appreciate the transparency. I told Vesa that they should close down the marketplace SharePoint isn't Facebook but "someone" at MS probably thinks so ;-)  What the PnP group is promoting and what you are getting is patterns for Consulting Companies and the local IT Department. You and I will lift our vision and Dream On. Remember ANYTHING that would allow you to put ANY SCRIPT on the host web of ANY sort is a security threat that would (SHOULD) never be allowed by MS. ANYTIME you require this and utilize this type of "feature" you know you are just a Consultant :-)


to be continued....


Thanks,

Jonas

Aug 12
SharePoint Add-in permissions

I was on the TAP for SharePoint 2013 since I used to work at Bamboo Solutions.

This was way back when I was still living in the US of A. They showed us the new App story sorry Add-in model and we showed them CloudParts(TM) from Bamboo Solutions.

download (1).jpg 

I'm the architect behind the Bamboo CloudParts(TM) which are actually pretty close to what the Add-in model is whith one big exception we didn't try to give the impression we could enforce any special Add-in permissions. Since the CloudParts(TM) run in the browser they can do whatever the user has permission to do.

I'm going to state a few facts that are WELL known in our industry. BUT I'm flabbergasted... NOBODY in the Office 365/SharePoint/Office community is talking about it. There is a Patterns and Practices group that are even promoting these potentially BAD practices.... I'm saying that they are BAD practices if you want to have people belive that SharePoint will be able to enforce any granted permissions.

1) IF you can inject client side script on the host page all bets are off. Why do you think that Redmond put all his effort into "sandboxing" the apps? It is because that is the ONLY way they can enforce app rights. BUT they realized that this "sandboxing" would drive their customers bat shit crazy so they opened up their _api, and by this they opened up Pandoras box. IT IS IMPOSSIBLE TO ENFORCE APP RIGHTS IN THE BROWSER....

2) There is only one way to truly enforce these Add-in rights and that is to disallow ALL client side script on the host page, no xross domain libraries. NO CEWP no client side customizations EVER, no JSLink. ONLY allow server side code to access SharePoint from a provider hosted app.

We all know that this will never happen. JSLink and client side rendering is a fundamental part of SharePoint. So what I'm suggesting is that MS is dropping this domain isolation of apps since it's NOT working. Keep it simple stupid and drop App principals all together since it's giving people a false sense of security.

We are now at a point where we know that the Licensing of SharePoint hosted apps are broken and we now know that the Add-in permissions can also be circumvented...

 

 

 

 

Apr 10
Making it harder

I'm trying to do it the app way but everything else seems so much easier. Why should I bother with certificates PowerShell and such when I can just embed a SriptEditorWebPart or a FormWebPart or using JSLink or.....

I'll tease you some, what if we could trust SharePoint to do the right thing? We could import SharePoints public key and we could make sure the request is actually from SharePoint. We could then ask SharePoint to send us a JWT token. We will verify it and pass it back :-)

That my friends will cover 80% of the use cases. We could have the option of building the token ourselfs and sign it. That my friends will cover the REST 20%

Think about it...

//Jonas​​

Feb 18
OAuth and XSS

I really like what MS is with the AppModel related to isolation.

But seriously why bother when you can inject "any" script anyways with JSLink, a script or a content WebPart....

​Think about it :-)

Jan 06
SharePoint out of context

Have you ever had the need to use the SharePoint OM outside "of SharePoint". If you could get away with a console app or winforms app (or PowerShell) you don't have to read on. BUT if you ever have been tasked with accessing SharePoint from a web application read on.

​The scenario: You need to do xyz in SharePoint from a custom non SharePoint Site...

1) CLEAR THE HTTP CONTEXT before accessing the SharePoint OM.

Now SharePoint thinks we are a console application and won't try to load configurations from web.config.

Use a helper class that will save the HttpContext and clear it in the constructor, then restore the HttpContext in the Dispose method, RAII style.

using( new ClearHttpContext() ){

   // Access SharePoint OM

}

//Jonas


Dec 20
AOP and Javascript

Last week I wrote about Application Insights from Microsoft and how awesome this "framework" is.

This has lead me to think about AOP ​and Javascript. Since Javascript is soooo dynamic by nature AOP is  actually pretty straight forward in the JS world. In January I will write some more this space. 

But just imagine you want to "enforce" some error handling strategy but you have legacy code aswell as third party code. Why not walk the "namespace" and inject your strategy automatically?

More to come!

//Jonas

1 - 10Next