Earlier this year, a script offering screen reading capabilities for websites was hacked. For a while, over 4000 government websites all over the world, were loading a crypto currency miner along with the screen reading script. And while no real harm was done and the issue has been fixed eventually, it makes you wonder: what if it happened on your Office 365 tenant and the script did something far more malicious than mining coins?
Fewer issues, but really?
For a while now, extending SharePoint using JavaScript has been gaining popularity. Originally, SharePoint users would load jQuery to quickly modify SharePoint DOM, but soon that evolved into using Content- and Script Editor Web Parts to embed turn-key widgets and build complete business solutions.
Extending SharePoint using JavaScript felt like a great relief to many. In the past, developers used to write managed code that had to be deployed to SharePoint Farms. If there was anything wrong with the code, the solution could even bring the whole farm down. And doing something wrong in SharePoint wasn’t all that hard. So, building SharePoint customizations using JavaScript became the holy grail. And it were not only the developers who embraced it. Administrators appreciated the fact that they no longer had to run any custom code on their servers. Also, the power-users appreciated the empowerment of being able to solve their own problems.
But by using JavaScript instead of managed code, it feels like we’ve traded one type of problem for another. One, that’s maybe even more dangerous.
The risk of using JavaScript in SharePoint
By using third-party JavaScript libraries and solutions built by others you can focus on what truly matters to your organization. But putting JavaScript that you haven’t written yourself in your SharePoint tenant is risky. JavaScript that runs as a part of the page has unrestricted permissions and can do anything the user visiting the page with the script can do. If that user happens to be tenant administrator, the CEO or an HR employee, a piece of JavaScript could access confidential and personnel information, send it to a third party and you couldn’t do anything about it. In many cases, you might not even know about it unless you paid really close attention to your network traffic and knew exactly what to look for.
SharePoint offers rich APIs that developers can use for anything from retrieving your personal documents, latest projects or your colleagues to changing permissions and searching for confidential information. That’s not all. With recent additions, tenant administrators can grant scripts access to the Microsoft Graph and enterprise APIs. And it’s exactly that flexibility that puts you at risk. In hands of a skilled developer who understands SharePoint, these are all invaluable tools to get to your confidential and personnel data.
What can you do about it
Being paranoid about using JavaScript won’t get you anywhere. But here is some practical advice that you should consider to lower the risk of your SharePoint tenant being hacked by JavaScript.
Know what scripts are being used in your tenant
There are many ways to embed a piece of JavaScript in SharePoint. You can add a script reference in the Master Page, Page Layout, Content- and Script Editor Web Parts or a Display Template, just to name a few. If you want to minimize the risk of being hacked by malicious JavaScript, you should start with an inventory of all scripts in your tenant. Sure, it’s tedious to do manually, but there are tools that can help you with it.
Rencore’s AnalysisCloud is this tool! AnalysisCloud continuously monitors your SharePoint Online tenants to discover all changes made beyond mere configuration, i.e. scripts. It then assesses these scripts and reports those that might be harmful. Click the link below and try out AnalysisCloud today!
Don’t use different script for everything
There are hundreds of thousands if not millions of scripts that developers and users can use in your tenant. The more different scripts are being used, the bigger the possible attack surface and the harder it is to evaluate all of them. Once you know what scripts are being used in your tenant, you should go through all of them and verify how widely they are being used and if there is an active community behind. The less popular a script is, the bigger the chance that a change to its contents will go unnoticed.
Know what you’re loading
The same way as you wouldn’t give a stranger the keys to your house, you shouldn’t just put every script on your portal next where your confidential data is stored. Before using a piece of JavaScript created by someone else, check what’s inside. If you find anything suspicious like `eval` or obfuscated code, you should be wary of using that script without a closer review. It will take some time, but are you willing to take the risk of that script stealing your confidential information?
Where are you loading your scripts from
You might trust specific hosting locations and CDNs more than others because your organization has a relationship with them or you trust their security measures. While it’s hard and tedious to do manually, there are tools that can help you ensure that all scripts in your whole SharePoint tenant are loaded from locations your organization approves. Discovering a piece of script being loaded from a different URL and changing to the preferred URL is still less work than evaluating what data has been stolen.
Use integrity hash with external scripts
In the case I mentioned earlier, a piece of script has been modified and some extra code has been added to the original JavaScript file. To protect yourself from this possibility, when referencing external JavaScript scripts you should always specify the integrity hash for that script. If the specified hash doesn’t match the script’s contents, the web browser won’t execute it.
Including the integrity hash can be easily done if you’re referencing scripts in HTML using the `script` tag. The SharePoint Framework doesn’t support specifying the integrity hash at this point. But given the framework’s popularity, I hope we will see this capability being added soon.
What you can’t do, at least for now
The problem of securing websites and web applications from risks coming from external scripts isn’t new. Web browsers offer different degrees of support for additional security measures. One of the most interesting capabilities is the ability to define a content security policy for your web application. In a content policy you can specify many settings such as which URLs scripts can issue AJAX requests to or from which URLs the web application is allowed to load fonts, images and scripts. Since the policy has to be specified as a response header, you can’t do it in SharePoint Online yourself, but given how popular using JavaScript to extend SharePoint is, I hope we will see Microsoft invest in this area in the future.
Over to you
If you want to take an even deeper dive into securing your SharePoint Online, I would recommend you sign up for our upcoming webinar “Securing SharePoint Online in 47 easy steps! (Or 5 steps, you choose)” by fellow Microsoft MVP Jussi Roine where he will show you around all the areas you have to understand, secure and monitor to keep your data and organization secure using both Azure and Office 365 capabilities and some common sense. Sign up today. It’s free!
