The typical consultant answer is correct “It depends.” I am also expecting that there are multiple views on this and there are many I am sure who might say “Yes” and “No” and even “Maybe.”
What do you think?
Do you think it is safe?
Is it always safe?
Can you guarantee what it is doing?
What impact can it have on SharePoint?
This post is not supposed to be a definitive answer but more of a conversation starter to highlight why this question should even come up. Firstly, let’s understand the real problem.
Yes and no really. Back then client-side was a last resort, with server-side being the option of choice for most coding. I remember back in the day converting a VAX VMS (for those that don’t know what that was:
https://en.wikipedia.org/wiki/VAX) system to Classic ASP, SQL and COM+ components, still have nightmares about it, but you know it worked perfectly.
I get what you’re saying, but what is the problem then?
Sandboxing is a vital security technique that isolates programs, preventing malicious or malfunctioning programs from damaging or snooping on the rest of your computer. Sandboxes restrict what a piece of code can do, giving it just as many permissions as it needs without adding additional permissions that can get abused. The web browser essentially runs web pages you visit in a sandbox. The Sandbox restricts your browser to a limited set of resources. Visiting websites not using a sandbox could mean that the executing code is not isolated from the rest of your system. If the site is malicious, potentially damaging changes can be made directly to the operating system itself.
Managed code is code written in one of over twenty high-level programming languages that are available for use with the Microsoft .NET Framework, including C#, J#, Microsoft Visual Basic .NET, Microsoft JScript .NET, and C++. All of these languages share a unified set of class libraries and can be encoded into an Intermediate Language (IL). A runtime-aware compiler compiles the IL into native executable code within a managed execution environment that ensures type safety, array bound and index checking, exception handling, and garbage collection.
Browser User interface
Now even though the executing code has access, it is controlled and sandboxed as explained before. The code can manipulate the user experience by interacting directly with the browser controls and components, causing potential problems within the browser.
The third problem is the code itself, and what it is directly trying to manipulate within the Document Object Model (DOM). Most browsers use multiple rendering engines:
Gecko – Mozilla
Servo – Mozilla
Goanna – M.C. Straver
WebKit – Apple
Blink – Google
EdgeHTML – Microsoft
Previous engines now discontinued are KHTML, Presto, Tasman, and Trident. More details on these can be found here: https://en.wikipedia.org/wiki/Comparison_of_browser_engines
Each browser contains versions of the rendering engines. The rendering engine within all browsers performs five core tasks:
Parse the HTML, and construct the DOM tree
Construct the Cascading Style Sheet Object Model (CSSOM)
Construct the render tree (combining the DOM and CSSOM)
Layout the render tree
Paint the render tree
The sequence of the entire process can, however, can break by introducing “<script>” tags. Scripts tags are parsed and executed immediately, as the parser reaches them. The parsing process stops until the script is fully executed. If the script is externally referenced, then it first has to be fetched from the network (synchronously), at that point all parsing stops until the fetch completes. HTML5 however, does provide a way to fetch externally referenced script asynchronously, mitigating this issue.
Using Chrome Developer Tools, you can view the “Shadow DOM” giving you the ability to see deeper into the HTML structure, especially inside of predefined components. As an example, the following code outputs the standard browser media control.
The assumption is that when you view the control source in the site after load, that this would be the code would see. As expected it is rendered that way.
However, if you look next to the beginning “<audio>” tag in the code, you can expand within the control to reveal the hidden from view “Shadow DOM.”
You can see that the internal elements render prefixed with “-webkit” and “-internal” denoting these are inside the “Shadow DOM.” You then can interact and modify them as needed. However, a problem that often occurs is that code written does not follow the required rules for utilizing the “Shadow DOM.” The user experience can be inadvertently affected, or cause unknown side-effects resulting in potential performance, layout or even security problems.
Learn more about Shadow DOM and which browsers fully support it, use any of the following links:
It depends on what the code is doing.
It depends on what it is trying to access.
It depends on what it is trying to manipulate.
It depends on which browser you are using.
It depends on whether the code is performing malicious actions.
It depends on what you as an organization want to use.
Resources and Guidance
This blog was originally posted on Liam’s blog
Liam is currently a Microsoft MVP and Product Owner – Security at Rencore. Please click the button below to see how the experience of our 5 MVPs is used in the offerings of our products!