User Custom Actions Get Published via
Content Type Hub Syndication
This article describes SharePoint OOTB behavior that enables a User Custom Action [Custom
Action] to unintentionally get published out to all Content Type Hub [CTH] subscribing site
collections. I say this behavior is unintentional because it is not documented in MSDN nor have I
been able to find any related commentary in the online forums.
If a “site collection” scoped Custom Action is added to the CTH and one or more Content Types
are published via the standard CTH syndication process then that newly added Custom Action will
also get published to all CTH subscribing site collections. Generally, this does not create a
problem so long as the application using the Custom Action has also been deployed to a site
subscribing to the CTH.
However, the bigger concerns are when a power user observes scripts being requested on sites
where the app has not been installed, or even worse, if developer with malevolent intent seeks to
exploit this behavior by executing code on sites that violates security policy (e.g. If a user with
elevated privileges visits a site with the malevolently intended deployed custom action, that
custom action will run with the privileges of the current user who may have restricted access to
content on that site, but not to the software developer who created the custom action . It would
be possible for that custom action to query for content in that restricted site, syphon off whatever
could be found, and sent to a “secret” drop box location.)
For example, assume the Gimmal Metadata Inheritance Rules [MIR] add-in has been deployed to
the CTH site. Since MIR deploys a “site collection” scoped Custom Action, when the Content Type
syndication process is executed, the MIR custom action is also deployed to all CTH subscribing site
collections.
Once a Custom Action has been deployed to the CTH, the next content type to get published will
also receive an association to that Custom Action in the Content Database so that all newly
created site collections will receive that Custom Action—even if the Custom Action is later
removed from the CTH. The net result is Custom Actions will be appearing all over the SharePoint
environment and it will not be evident how to get rid of them.
Prior to understanding the root cause, I wrote a PowerShell script to scan the environment looking
for the Custom Actions on sites where the related app had not been deployed—at least that
addressed the existing sites, but newly created sites would continue to get the Gimmal created
Custom Actions. While we suspected the root cause was related to content type syndication, it
was not evident why. Since this behavior was neither documented in MSDN nor was anything
pertinent found in the online forums.
This problem was first discovered in our Office 365 Engineering 2 tenant. After doing some initial
research, I opened a ticket with Microsoft. After much correspondence, Microsoft neither offered any
information as to the root cause, nor did they offer any advice to remedy the environment. In the end, I
requested that Microsoft recreate the Content Type Hub in our Office 365 Gimmal Engineering 2 tenant,
but the request was denied. In a sense we were stuck… until we figured out the root cause.
Observations
The journey that led to understanding this behavior included several breakthroughs and
observations before we arrived at the identifying the root cause:
1. User Sees Unexpected Network Requests
The said behavior can be seen when a user visits a site and network requests are listed for Custom
Actions that correspond to functionality that has not been formally added to the site. For
example, in Figure 1 below, there was a request made for “carbon.mdi.loadjs.js” script. However,
the actual site does not have any deployed add-ins deployed.
Figure 1 - Network Requests Revealing Custom Actions
2. Custom Actions added to CTH get published to all Site Collections via CTH Syndication
Adding a “Site Collection” scoped Custom Action to the CTH will get pushed out to all sites
(existing and newly created) once the Content Type Hub syndication job is executed.
3. Custom Actions Removed from CTH Prior to any Content Type Publishing Activity Will Not Affect the
Environment
If a Custom Action added to the CTH is removed prior to publishing/republishing any content
type, then the Custom Action will no longer appear in newly created sites. However, the Custom
Action will continue to exist in preexisting sites subscribed to the CTH.
4. Custom Actions Added to the CTH Will Remain Once a Content Type is Published
When a Custom Action is added to the CTH, the set of Content Types that get published the next
time the “Content Type Hub” job is run will get an association to the created Custom Action in the
Content Database. In this case, all subscribing sites and newly created sites will receive that
Custom Action. If Custom Action is removed from the CTH, then all newly created sites will
continue to receive the Custom Action.
5. Relevance of the SharePoint List in the CTH: Shared Packages
When a Content Type is published, it gets registered in the “Shared Packages” list found at the following
URL: {~CTH site}/lists/packagelist. Figure 2 below provides a screenshot from this Shared Packages list
that lives in the CTH site. The contents in this package list also has a corresponding table in the
“Managed Metadata Service” database in SQL Server named “dbo.ECMPackage”.
Figure 2 - CTH Package List
6. Temporary Packages Created During Content Type Syndication
When CTH syndication is running (i.e. Content Type Subscriber job or during SharePoint site
creation), a set of temporary “package” (a.k.a. CAB) files are created on the SharePoint
server. During site creation, these files are generated when the SharePoint hidden feature
“Register taxonomy site wide field added event receiver” is activated during site creation. The
generated package contains a number of files, of which the most interesting is “Manifest.xml”. It
was this content that was the smoking gun indicating the source that was producing the Custom
Action in CTH subscribing sites. See Figure 3 below for a sample Manifest.xml file.
Figure 3 - Sample Manifest.xml from a Taxonomy Package
Notice the Custom Action registration shown above in Figure 2. It is this registration that deploys
the Custom Action to a newly created site (or when the Content Type Subscriber job is run).
7. Relevance of the ECMPackage table in SQL Server
It was also noticed, in SQL Server, that the “dbo.ECMPackage” table contains similar information found in
the “Shared Packages” list mentioned above with some additional columns named Content and
ContentSize. The Content column essentially provided the binary content for the CAB files mentioned in
the previous observation.
Figure 4 - dbo.ECPPackage Table
It is interesting to note that if a content type (identified by the “Id” column) was unpublished, then
when the “Content Type Hub” job was run, then the IsPublished” and “ContentSize” columns were
set to 0 and the Content column was set to NULL. When republished, then the Content (Package
CAB contents) would get set back. Once we saw this behavior, we knew we were getting very
close to identifying the remedy for getting rid of the unintended Custom Actions being loaded in
sites where the corresponding add-in had not been deployed.
8. ULS Logs Related to Content Type Syndication Packages
To further aid our analysis, I turned on Verbose diagnostic logging for the “Taxonomy”
category. When the “Content Type Subscriber” job was run, we noticed the following log
messages in the ULS:
Figure 5 – ULS Log
The key phrase here being “ContentTypeSynchronize got 1 packages”. This message indicates that
a Content Type has been published and needs to pushed out subscribing sites. The “package”
term is not insignificant in that it directly refers to the “CAB” files that contained the associated
Custom Action.
Steps to Remedy
The following steps provide the needed remedy if you are experiencing the described behavior
where Custom Actions are being loaded in sites where the corresponding Add-In has not been
installed.
Remove User Custom Actions from the CTH
The first thing to do is remove all unnecessary custom actions from the CTH site collection. This
can be done via PowerShell with the following “collection” property:
SPSite.UserCustomActions
On-premsies
If you wish to remove all Custom Actions, run the following PowerShell:
$site = Get-SPSite $url
$site.UserCustomActions.Clear()
Office 365
These next set of steps will clean the environment so that unintended Custom Actions will no
longer be loaded when a user visits a SharePoint site in that environment. There are two
approaches provided, the first one is more straight forward, but may taking longer to complete.
Approach #1
1.
Republish all content types in the CTH.
Approach #2
1.
Inspect the list contained in the CTH at: {~CTH site}/lists/packagelist.
Republish all content types represented by the Content Type ID found in the “Published Package Id”
column.