Is Custom Script Dangerous

Anatoly Mironov

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.

Comments from Wordpress.com

Hiding Teamify Prompt | CHUVASH.eu - Jan 2, 2020

[…] CustomScript is disabled by default for a reason. Because it is a security risk. At least you should alter the script to reset the CustomScript setting on a site after you have […]

[…] Is Custom Script dangerous (a post in my blog) […]