Try ShortPoint nowIntroduction
As the ShortPoint engineering team, we take security very seriously. Our product enhances the features of the battle-tested rich text editor used in SharePoint, Microsoft 365, and other platforms. Nevertheless, that does not mean we should take everything for granted.
In this document, we will go through each potential threat in SharePoint / Microsoft 365 and how we have addressed those threats and increased the level of security at ShortPoint.
TABLE OF CONTENTS
- Introduction
- Full compliance with Microsoft 365 and SharePoint Security principles and implementations
- Cross-Site Scripting (XSS)
Full compliance with Microsoft 365 and SharePoint Security principles and implementations
After you download the package, you install ShortPoint directly into your environment. We do not have any access to your content. ShortPoint is fully compliant with Microsoft 365 and SharePoint security principles and implementations.
Cross-Site Scripting (XSS)
To make sure that the end user’s input through ShortPoint remains safe at all times, we have added a Filters Layer to the product. This layer depends on two of the most well-known XSS filtering libraries:
We have used a mix of those two modules (see the screenshot below) to fit our special needs in handling every aspect of user input in ShortPoint while not breaking important part of the end-users page:
It is good to note that the Filters Layer is not tightly coupled with these modules. Updating any of the modules is just a matter of one click. Also, if we wanted for any reason to drop any module or replace them with a better alternative in the future, it can be easily done by updating only this layer.
Let’s dive into each potential XSS threat that can be found in the product and how we managed to address these threats to protect Microsoft 365, SharePoint, and other users as much as possible.
Page Builder Text Fields Input
The Page Builder is the area in ShortPoint that contains the most text fields: each ShortPoint Design Element can be customized using a bunch of text fields. It is important to make sure that every field does not contain any potentially harmful code by the end user.
All Page Builder fields are being validated using the ShortPoint Filters Layer to make sure the entered data is safe and clean.
Page Builder Rich Text Editor
To enable end-users to write rich text content from the Page Builder dialog, we have carefully picked the Froala Editor, a highly flexible and secured rich text editor.
Froala editor has a strong defense mechanism against all types of XSS attacks. It was tested by the world-renowned Ashar Javed.
Manually Writing ShortPoint HTML
All ShortPoint Design Elements before rendering will look similar to the following HTML template:
<div data-shortpoint=”ELEMENT_NAME: { OPTIONS }”></div>
Before, we used to parse the data inside data-shortpoint attribute using the eval method, allowing the end user to write harmful code inside such attribute as in the following example
<div data-shortpoint=”button: { title: ‘about us’, link: alert( 1 ) }”></div>
To prevent this (since all content of the data-shortpoint attribute should be raw data), the parsing mechanism has been changed to use the safe JSON.parse method instead of eval.
Explicitly Defined ShortPoint Code Attributes
After going through how ShortPoint works behind the scenes, and how ShortPoint code gets parsed into an actual JavaScript code, one may think that any attribute you put into the code will end up being parsed into the data-shortpoint attribute, but it is not the case here.
For example, let's take a look at the following ShortPoint code:
[button title=”hello world” onclick=”callSomething” onmouseover=”callAnother” /]
Once it is converted into a ShortPoint HTML template, it will look like this:
<div data-shortpoint=”’button’: { ‘title’: ‘about us’ }”></div>
As you can see, all extra attributes in the ShortPoint code have been removed once converted into a ShortPoint HTML template. This is because for every ShortPoint Design Element we have a meta-data definition (see the screenshot below), that defines the exact attributes needed to be parsed.
Any extra attribute written into the ShortPoint code, that is not defined in the ShortPoint element meta-data, will not be parsed and will be ignored.
JavaScript Source Protection
Our JavaScript is not only being minified, we are also obfuscating it using Jscrambler.
Most products designed to protect JavaScript rarely go beyond simple regular expression transformations. Still, the Jscrambler is a JavaScript interpreter and parsing engine that creates an Abstract Syntax Tree representing the source code. Because Jscrambler understands JavaScript, it secures the HTML5 and JavaScript in a way that the protected code executes with the same functionality as the source.
This approach allows the product to be easily and affordably maintained, enabling it to evolve naturally and providing it with the ability to produce enterprise-class security and anti-debugging methods.
