Understand NetSuite Clickjacking SuiteLet Considerations

This article is relevant if you are programming NetSuite externally facing web pages and you need greater control over security to prevent malicious activities.

Background

After producing software development for many years in the NetSuite ERP platform, many of us begin to forget that we are indeed producing user experiences in a web browser. I say that because the NetSuite API allows us to produce consistent user experiences without having to think much about any aspect of the underlying HTML. Most of us are grateful for this because we focus on what matters most to our users: the business logic.

Yet, let’s remember that the NetSuite platform allows us to produce web experiences that are “outside the provided library”.  By using SuiteLet technologies, we can drive a web user experience that opens up the NetSuite database platform to any community we wish to reach.  The use of the SuiteLet Anonymous mode means that users do not have to be authenticated and/or have a NetSuite user license to access information.  However, once we open our web logic to other communities, we are obligated to act with greater responsibility for the security of our pages.

Recently, a fellow NetSuite developer located in Australia, Tim Pilgrim, reached out to me to discuss a concern he had helping one of his clients who was working on an ethical hacking project. He posted a concern in the NetSuite Professional Slack channel and he wanted to share it with us hoping to extend reach.

The rest of the article was inspired by Tim’s research and I appreciate that he reached out so that I too can help the NetSuite community.

NetSuite Version 1.0 SuiteLets and Clickjacking

Tim’s client work revealed that they had a number of externally facing SuiteScript 1.0 web pages that were vulnerable to Clickjacking. He was asked to help close these vulnerabilities.

What is Clickjacking?

What is Clickjacking? Clickjacking occurs when an attacker uses a transparent HTML IFrame to trick a user into clicking on a web element, such as a button or link, to transport the user to another server that looks like the origin server.  In other words, the attacker hijacks the clicks meant for the original server and sends them to the hijacker’s server.

As the web has become increasingly more sophisticated, the demands for better web programming has also increased. The primary way that Clickjacking happens is by injecting code into the web page that gets loaded into the user’s web browser. Code can get injected by using mechanisms that allow for content to be loaded that did not originate for the requested web domain.

Getting Control Over Clickjacking

To get control over this concern generally requires two major actions:

1. Server Based Header Policies: send information in the server’s web response header (not visible to end-users) that specify specific policies that the web browser will respect.
2. Enhance HTML JavaScript Practices: modify the way code is executed within the HTML to prevent inline JavaScript execution.

The good news is that modifying the HTML Javascript practices is well within the control of web developers. However, the Server Based Header Policy management demands more understanding and capability.

Which HTTP Headers are Needed?

The following headers allow the web developer to get control over the situation.

• Content-Security-Policy: This header allows you to specifically indicate which content (code) sources can be loaded by the web page. It is the most important header we need. Think of it as a trusted “whitelist” of places the page trusts.  This sample header, “Content-Security-Policy: script-src ‘self’ https://apis.google.com”, trusts itself (generally always) and the google APIs domain. See related article.
• Access-Control-Allow-Origin: This header is blacklisted by NetSuite. It is designed to indicate what cross-site policies are allowed. The Content-Security-Policy header should be able to give us what we need. See related article.
• X-Frame-Options: This header allows us to control how IFrames can interact with our pages. However, our Content-Security-Policy has a “frame-ancestors” directive that can also give us control.  See related article.

SuiteScript 1.0 SuiteLet Header Management

Many SuiteLets written in SuiteScript version 1.0 continue to exist including those provided directly by the NetSuite product and professional services teams. The challenge with version 1.0 SuiteLets is that you can not set standard header values expected by the browser. If you try, you will receive an SSS_INVALID_HEADER header error.

Ideally, SuiteScript 1.0 would be more open to allowing the developer to set standard and expected header values.  Note, Tim referenced a NetSuite Enhancement, #463008, to help. However, the description is general and, if anything, it looks like it would restrict our control even further.

SuiteScript 2.0 SuiteLet Header Management

SuiteScripts Suitelets written in version 2.0 give us more control. We can indeed write the Content-Security-Policy.  Note, see the HELP and related image for NetSuite blacklisted headers. Thus, we can take care of our concerns natively here.

SuiteScript 1.0 to 2.0 SuiteLet Proxy

Since SuiteLets written in 1.0 do not give us the header control we need, we may have to take matters into our own hands. The first thought that may come to mind is that you need to rewrite the 1.0 logic to 2.0.

Yet, there is another option. You can create a 2.0 SuiteLet that calls out to a 1.0 SuiteLet server side. I call this a proxy pattern because it sits as an agent in between the client web page and 1.0 SuiteLet server page. This approach will impose a performance penalty (generally insignificant) but it may be a satisfactory workaround. Our firm often uses this and other proxy patterns to break through general SuiteScript 2.0 and SuiteScript 1.0 logic situations.

Thank you for Reaching Out

I would like to thank Tim for reaching out to share this concern. My commitment is to hold high standards for care in our firm, for our clients, and how we act in the NetSuite community. When Tim reached out, it was important that I listened to his concerns. If you found this article meaningful, feel free to sign up for notifications when I publish new articles. If you have a challenging NetSuite endeavor that you would like to tackle, let’s have a conversation.

Marty Zigman

Holding all three official certifications, Marty is regarded as the top NetSuite expert and leads a team of senior professionals at Prolecto Resources, Inc. He is a former Deloitte & Touche CPA and has held CTO roles. For over 30 years, Marty has produced leadership in ERP, CRM and eCommerce business systems. Contact Marty to set up a conversation.

More Posts - Website - Twitter - Facebook - LinkedIn - YouTube