Allowing custom script has its security implications. But what exactly does it mean? Is it dangerous? My colleauge Daniel and me have done a little experiment. There are two implications stated on MS Docs:
Scripts have access to everything the user has access to.
Scripts can access content across several Office 365 services and even beyond with Microsoft Graph integration.
To summarize, we can look at that picture:
So the risk that user 1 (the Blue User) intentionally or unintentionally places a script and lets user 2 (the Red User) run this script by linking to the page that has this script. The page must be in a “common” place.
Let’s try that. Let’s have a little hackathon.
Experiment A. Very Simple.
Scenario: the Red User (my colleague Daniel) has a site with with sensitive information (He has a list called Secrets). The Blue user (me) does not have access to that site. The Red User accidentially shares the link to the secret list. Now, to prove the security risks with the custom script, the Blue User has to get the secret information.
To make it more visual and fun, we have found a box where we have put candies and locked it with a combination lock. The code (the combination) is stored in the Secrets list.
The combination consists of three digits from 0 to 9. So there are 1000 possible combinations.
Since the Red User knows that he is going to be hacked, he acts as normal as possible, not especially suspicious. And since the experiment A is a simple one, we let the Red User to accidentially show the link to the Secrets list. That can be:
A screenshot that shows something else but contains the confidential site url
An email that is sent to a wrong recipient
A pasted link in a wrong Teams chat
etc.
So the Blue User finds out that there is a Secrets list that has the following address:
/sites/DailyWork/Lists/Secrets
“Fortunately”, the Blue User has access to a classic site (where Custom Script is allowed). He shares that site with the Red User. Now both the Blue User and the Red User have it in common.
Then, a new Web Part Page is added with a tiny script.
That script makes a REST call to the Secrets list and uploads the result in Shared Documents. For the sake of simplicity, a built-in document library is used. An attacker would probably add a hidden list for that.
Now to get the Red User to that page, the Blue User adds some “important” information so that the Red User will not become suspiciuos.
The “important” information and the actual script editor
Now it is just the matter of sending a link to the Red User. The Red User navigates to that page and the script is executed while he is reading the information on that page.
The Blue User gets the Secret that was generated by the Red User:
With that information the Blue User has hacked the combination lock and he can now open the red box with candies!
Skitgott Candy
Experiment B. Harder
For now I think it is enough with the Experiment A, the Simple Experiment. We have proved, that, indeed, security is compromised with custom script allowed. A user can get confidential information from another user. Maybe some of you want to set up a more sophisticated experiment. Make sure the “hacked” person is warned and agrees to be part of an ethical hacking act. We maybe can try more to show the importance of keeping custom script disabled and not using classic sites that have it by default.
Wrapping up
Custom Script (or DenyAddAnCustomizePages=false) is dangerous, it is of course not black and white. It provide the ability to have small appications directly on sites created by users. But as with all other aspects of IT, you should know what you are doing. Every site with custom script is a potential trojan horse. Minimizing the number of classic sites and sites with custom scripts lowers the risk. All the collaboration sites should be modern team sites without custom script.
Yesterday Waldek Mastykarz published a cool post: Globalizing JavaScript in SharePoint 2013. This is a very cool technique to localize your client code in javascript and reuse your resx files in Server Side and Client Side. This is actually not new for SharePoint 2013 despite it has become more needed with the huge client focus in the new SharePoint. I have used this in SharePoint 2010 for a long time. In my blog post: ScriptResx.ashx in SharePoint I told about that technique. What I didn’t know that you can define your javascript namespace directly in the resx file. Waldek wrote in his comment that SP.Publishing.Resources.en-US.resx automatically are SP.Publishing.Resources in javascript. That was not the case for my own localization files. A simple look at SP.Publishing.Resources.en-US.resx helped:
<!--
Whether this .resx could be read by scriptResx.ashx handler. Only a file
marked with scriptResx:true could be returned to client.
-->
<resheader name="scriptResx">
<value>true</value>
</resheader>
<!-- the full name of the JavaScript class. -->
<resheader name="classFullName">
<value>SP.Publishing.Resources</value>
</resheader>
This results in:
_EnsureJSNamespace('SP.Publishing');
So what we have to do for our custom resx file is to add classFullName resheader:
For a while ago I needed to copy all files from a document library within a SharePoint 2007 site to the hard drive. So I didn’t need to copy files from SharePoint to SharePoint so I couldn’t use the stsadm -o export command or Chris O’Brien’s nice SharePoint Content Deployment Wizard. I came across the SPIEFolder application which should work with SharePoint 2007 and 2010. It has a site on codeplex: spiefolder.codeplex.com, but neither the binary nor the source code can be downloaded from there. After some searching I found the binary in the author’s skydrive. The fact that the source code was not available seemed as an disanvantage because I could not know what code was run. Nevertheless I tried it out and it didn’t work:
The Web application at http://dev/Documents could not be found. Verify that you have typed the URL correctly. If the URL should be serving existing content, the system administrator may need to add a new request URL mapping to the intended application.
So I wrote my own code to copy the documents. To write a console application feels so yesterdayish, so it is written in PowerShell. Even if there are no PowerShell snapins for SharePoint 2007, you have access to the entire Server Object Model, the only thing you have to do is to load the SharePoint assembly:
I have created a ps1-script which only does one thing – it copies an entire document library to disk. Much of inspiration to structure the script comes from “Delete-SPListItems” (sharepointryan.com).
Läser ett intressant inlägg om deployskript i powershell. Har upptäckt att man kan stoppa in ett defaultvärde i funktionens parameter. Så i stället för
function hello($name) {
Write-Host $name
}
Kan man köra:
function hello($name = "Gregor") {
Write-Host $name
}
PowerShell är ett sätt att manipulera data och struktur i SharePoint-portalen. Samma uppgifter låter göras med konsoll-applikationer. Fördelen med PowerShell är att man kan skapa skript som är flexibla och kan köras med olika parametrar. PowerShell påminner starkt om shell-skript i Linux. För mig som egentligen kommer snarare från bash-världen. Där har Microsoft låtit sig inspireras starkt :).
Det finns en bok om PowerShell, skriven av svenskar, som låter intressant.
Man behöver inte heller uppfinna hjul på nytt: det finns färdiga skripts som man direkt. Bara man skriver rätt parametrar. Här är ett ställe där man kan hitta skripts. Det finns många sidor som förklarar hur man skriver skript.
Recent Comments