Over the past few years, a topic that comes up more and more is whether these customization and development approaches within SharePoint are safe. I, myself have built Managed Code and Sandbox solutions, as well as client-side solutions both as scripts, or as part of a controlled and managed deployment such as the SharePoint Framework. Being out in the field as a consultant for best part of 15 years, over multiple versions of SharePoint, clients will create the customization they need in whatever way is easiest and fastest. Honestly, there are not many that go through a full-lifecycle of testing and controlled security review at all.
For instance, years ago I wrote the “Helloitsliam Claims Viewer Web Part” which is a managed code solution (WSP), that you deploy to the SharePoint Farm, and allows you to see the claims attributes, etc. during an Authentication process. This web part was needed, and I used it a lot. What I didn’t realize though was how many Administrators installed it into their Production SharePoint Farms. I would ask the question of whether they checked it and of course, the answer was no most of the time.
https://1drv.ms/u/s!An6eWkVI7cMNgYdO4gFhY6Tj3HdmFQ
Surely “Liam” would not write bad, suspicious or malicious code? I will leave you to decide that
So, let’s go back to the issue at hand. Over the past year, Microsoft has done its best to try and discourage using the “Classic” SharePoint User Interface along with the “Classic” way of customization. Modern is a new way, limited access to modify the pages, etc. and a more controlled approach to customization. Surely this is what you should be using right now?
Why are you still using “Classic” customization approaches?
Three words: Quick, Simple and Easy. That does not make it right though.
While working with different organizations, there are those that adopt the new and those that don’t. I have worked with organizations that have tried to move to the new “Modern” way and have just not been successful, simply down to it not all working that way yet. The biggest complaint has been that not everything is in the modern design and does not support the modern design principles, or further it just doesn’t support what is needed by the organization. Whether this works or not, is out of our hands. Microsoft is actively working on. With the release of the Patterns and Practices components such as the starter kit, we are slowly moving closer to the true “Modern” experience.
https://github.com/SharePoint/sp-starter-kit
However, based on previous guidance offered by Microsoft and others, allowing business and power users to modify the user experience has become normal. Adding a script editor web part to a page, then injecting client code works. It is so easy to do that many environments contain many of them throughout all sites. In fact, I have yet to find a SharePoint Farm or even a SharePoint Online Tenant that does have this. Classic SharePoint is not inherently bad, it has served us well over the past few years and has worked well. However, the “Classic” practice if injecting code into the page that modifies objects and the DOM, is not the best approach. In my last post entitled “Is JavaScript safe for SharePoint?” I laid out why even just using JavaScript could be bad.
https://www.helloitsliam.com/2018/06/23/is-javascript-safe-for-sharepoint/
Why should I use SharePoint Framework?
The real answer is “Microsoft” wants and needs you too, and it is not a bad thing either. Microsoft’s goal has always been to provide a platform or service that has the best Service Level Agreement (SLA), one that means if you customize the system it does not just break. Running Office 365 has taught Microsoft lots of things about what “we” as the normal users do to SharePoint and why it breaks. This information has pushed them to make decisions about what should and should not be allowed. Microsoft isn’t just deprecating something because they want to stop customization or annoy us, it is about creating a more stable and capable platform.
The SharePoint Framework is the better way of controlling customizations as well as creating a true “DevOps” process, which we should have all been doing in the past. What I mean by this, is that code is created, validated, checked for best practices and security, then only deployed after signoff. Giving end users the ability to modify a page with code, goes against this controlled approach. The issue is not just that end users make these changes, but that JavaScript is so powerful. Don’t believe me then read the breakdown of the Ticketmaster data breach. I will give you a clue; the key word is “JavaScript” along with ad-hoc deployment
https://www.databreachtoday.com/ticketmaster-breach-traces-to-embedded-chatbot-software-a-11144
Now is the time to start migrating away from end-user created client-side JavaScript scripts to managed deployment using SharePoint Framework.
Will SharePoint Framework fix all the Security problems?
The short answer is “No” the long answer is “Yes” and “Maybe”
SharePoint Framework will give you a better chance on finding any security of code issues before deployment. The logic here is that you are moving away from isolated scripting and deployment, to centrally managed and controlled. It is true though that I could write malicious JavaScript inside a SharePoint Framework web part, and it could get through. In my last post (mentioned above) I talked about obfuscation of the client-code, this would also affect SharePoint Framework web parts. Writing bad JavaScript has consequences for SharePoint and other elements of a solution or even the browser itself. For example, writing this function and having this load within either a script editor or a SharePoint Framework web part will give the appearance of SharePoint not working, but in reality, it is just crashing the browser.
Running this within the Firefox web console and then watching Task Manager you can see what I mean. The function keeps reloading the page as long as “1 = 1” which it does, which causes the browser to lock, memory to grow and CPU to keep spiking. Imagine this code hidden within a SharePoint Framework Component or even a script editor web part for that. That would be a fun support ticket to try and figure out, with the browser crashing everytime you got there.
Using SharePoint Framework, with the centralized deployment and management, would hopefully find this code, as it would get reviewed before deployment. If not, then let me know, and I am sure we can work something out…..just kidding
SharePoint Framework by itself using rules to validate the functional code structure, ensuring that checks get ran. However, the “tslint” rules which control the structure do not highlight these types of issues. A manual review is needed or use of a tool such as the tools created by the Rencore Team (shameless I know).
What is nice though within the SharePoint Framework, is the ability to load other modules into the projects that can check for security issues. As a side note, when you run an “npm install” command, it will output the vulnerabilities for the various installed packages as it also runs “npm audit“. If you then use the “npm audit fix” it will probably break the SharePoint Framework project due to dependencies breaking.
You can, however, run “npm audit” manually to see the results, as well as outputting a “JSON” file for review later using this “npm audit –json > security.json.”
The tooling allows you to manually make fixes needed for any of the dependencies, or even add in other “npm” packages that can perform security checks on the code. Basic Security checks run within a SharePoint Framework solution as well. An example of this could be the use of “Eval().”
Upon finding an instance of “Eval()” the “jshint” plugin provides further details of the code block.
This simple check goes much further than anything you can do with end-user scripts added to a script editor web part. Even just this, being notified when looking at the code, of what is good and bad is 100% better than arbitrary script added to a page, with an end-user being expected to know what the code completely does.
How do I tell my end-users they can’t add scripts anymore?
From my experience end-users only make these changes because they need to perform some action that doesn’t exist or don’t know another way. I have also seen end-users make these changes because there are no developer resources available. Changing the approach may cause an issue, removing their ability to create what they need when they need, to now a dependency on a developer plus a process of checks and deployment. Honestly, there is no magical answer, but more to explain and then manage.
For me, the SharePoint Framework is the next evolutionary step in building customizations. It offers a much better approach to management and control, as well as flexibility in developing solutions. Combine this with moving from “Classic” to “Modern” user experience then you have reduced the surface area of customization drastically, reducing not only that, but the support calls you may get.
Call to action
I highly recommend the following tasks:
- Check your existing SharePoint or SharePoint Online solution for customizations.
- any existing customizations.
- Perform migration planning to move them from classic to modern customizations.
- Migrate the user interface to “Modern” versus “Classic.“
I am not advocating you do all of these in one go, but prioritize each one, and plan the updates and move in conjunction with working with your business users.
Shameless Suggestion: To help you, take a look at the “Analysis Cloud” service provided by Rencore, it can make lite work of finding those end-user customizations.
This blog was originally posted on Liam’s blog
