In Part 1 of this series, we reviewed NetSuite’s permission model. I explained that the “Run Unrestricted” saved search mode generally applies to restrictions and not permissions. In Part 2, you learned that there are important exceptions to this rule notably among which is the
Transaction record where “Run Unrestricted” overrules both restrictions and permissions. In this concluding part, we’ll explore a longstanding security loophole that makes the “Run Unrestricted” option precarious. We’ll also teach you how to work around it.
A saved search with the “Run Unrestricted” option enabled can expose your entire database to any user who has access to the search! This is scary and hardly what you want. Apply the workaround below to tackle the problem.
Before proceeding, I’ll like to acknowledge the following NetSuite Reddit community members for bringing this issue to light: User “NShoneyhamilton” identified the problem, and the aptly named user “SmartSeat” discovered and shared the workaround. All I do here is to present the information in a manner that is more accessible to the average reader.
The Problem: Unexpected Elevated Privileges
Let’s explore the problem using an example. Tim has recently moved to the Purchasing department. In his former role as A/P Analyst, he was able to see all Purchase Orders (POs) from all vendors. However, he’s just created a saved search from his new Purchaser role, and he only sees POs from vendors in the same subsidiary as his – Asoville B.V.
He reaches out to Edet, the NetSuite Admin at Asoville Inc. She confirms that the behavior is as expected since his “ASO Purchaser” role is restricted to his subsidiary. This, as you may recall from Part 1, is one of the restriction capabilities built into NetSuite’s access model.
To address the issue, Edet creates a PO saved search with the “Run Unrestricted” option checked. When Tim runs that search, he can now see POs from all vendors regardless of their subsidiaries. All looks good so far. However, Tim is not quite the average user and likes to poke around. He’s also not extremely happy that his new role is more restricted than the previous role. As he pokes around, he discovers that, although he’s not able to edit the PO search shared by Edet, he’s able to change the criteria via the “Return to Criteria” button. This grants him unintended access to any transaction he likes including those he normally cannot see via his role!
That’s interesting and puzzling at the same time. Tim doesn’t expect he should be able to see A/R transactions like Sales Orders and Invoices but he’s able to with this modified search. As a sanity check, he creates a new “all transactions” search from his Purchaser role, and, indeed, he cannot see those transactions via a normal search.
Tim suspects that the “Run Unrestricted” option remains applied when he modifies the original search’s criteria thereby giving him admin access to the entire database. And, unfortunately, Tim is right!
Tim feels like he’s just gotten superpowers. Being a sneaky guy, he decides not to share this discovery with anyone. With this secret loophole, he’ll now be able to access all transactions in the database as well as the associated G/L account data. Finally, he can check the numbers the CFO presents (he’s always felt they were off but had no way of proving it). The possibilities for mischief seem limitless.
Edet, on the other hand, carries on with her business as usual, not knowing that she’s inadvertently created a backdoor that Tim has no issues exploiting. Although Edet is a capable NetSuite Administrator with several years of experience, she’s fallen into a loophole caused by a poor implementation in NetSuite. “Security by design” is easier said than done and this is an example where that principle is not being upheld with potentially disastrous consequences as a result.
In case the problem is still not crystal clear to you, let me spell it out:
The “Run Unrestricted” option does not only grant users unrestricted access to the specific search to which it is applied; instead, it grants them privileged access to ALL data of that particular search type!
Essentially, each time you enable the run unrestricted option, you’re basically giving your users full (view) access to the entire database for that record type. You give them the “keys to the kingdom” to explore as they deem fit while you think you’ve confined them to a secure room. While they cannot save the modified search, your users are still able to execute it ad-hoc with different criteria and access any data they want. This is because the “Run Unrestricted” option stays enabled on their modified search. You clearly do not want that so let’s see how you can easily prevent it.
The workaround involves creating a dummy transaction field with restricted access as illustrated above. The data type of this field is immaterial. However, I use a checkbox for reasons that will become clearer shortly.
The key point is to make sure the
Default Access Level of this field is set to “None” and the
Default Setting for Search/Reporting is set to “Run”. Obviously, you also want to make sure you do not expose the custom field on any entry form as it should not be manipulated.
Next, grant only the Administrator, full access to this custom field. Finally, add this custom field as a criterion to all searches that are configured to “Run Unrestricted”. With this field as part of the search criteria, NetSuite will prevent non-Admin roles from being able to access and modify the search criteria. This achieves the desired effect of locking down the search.
Note that since checkbox fields default to false, the condition “Can Search Unrestricted = False” will not exclude any transactions. Semantically, it also captures what we’re trying to achieve, namely prevent users of a “Run Unrestricted” search from performing other unrestricted searches with different criteria. But get it right: It is not the value of this field but simply its presence as a search criterium that makes the solution work. So setting “Can Search Unrestricted = True or False” will work perfectly fine too. The key point is the access levels specified for this custom field. Refer to SuiteAnswers (Answer Id: 10096)[I]NetSuite (March 4, 2011). Restricting Access to Custom Fields. Available at https://netsuite.custhelp.com/app/answers/detail/a_id/10096 [Accessed October 16, 2020] to learn more about custom field permissions and access.If you have several saved searches with "Run Unrestricted" enabled in your NetSuite environment, it is a strong indication of a bad roles and permissions structure. Review your access model right now and address the root cause… Click To Tweet
This is a pretty creative workaround. It does require modifying all searches that run unrestricted but you shouldn’t have too many of these anyway so the effort should be minimal. On a separate note, if you have several saved searches with “Run Unrestricted” enabled in your NetSuite environment, it is a strong indication of a bad roles and permissions structure. Review your access model right now and address the root cause instead of granting users elevated access, possibly with undesirable side effects!
Tip: You can easily find all these searches by creating a Saved Search of Saved Searches that have this option enabled. Do that right now and save yourself further embarrassment!
Demanding Higher Standards
Apparently, this issue was reported to NetSuite back in 2009. Surprisingly, it got categorized as an Enhancement (#160618) instead of a Defect. In my option, that’s a gross misjudgment! More worrisome is the fact that, over 11 years later, it is still open. If you have access to SuiteIdeas, take a moment to vote for this “enhancement” here. Maybe, NetSuite will give it some attention when there are enough votes. (Although, from other longstanding “ideas” in SuiteIdeas, I’m afraid it doesn’t quite work that way.)
It has taken hours of research and a 3-part series to bring you these insights. I hope you find them useful. More importantly, I hope NetSuite is listening and pays more attention to these sorts of issues going forward. It’s a huge and complex platform so there will be bugs and poor design choices from time to time. However, once pointed out, the team should promptly address them instead of leaving them on a pile of “ideas” for eons.
I’m not extremely delighted to produce such articles. (I’d rather talk about fun stuff, new features, and best practices.) Nevertheless, I am committed to helping the NetSuite community (in this particular case, NetSuite Administrators and finance teams) stay on top of their game and raise the standards.
Now that you know, you have no excuse. Spread the word, share you thoughts in the comments section, and be sure to subscribe to get notified of NetSuite Insights as they get published. If you have NetSuite insights of your own to share, be sure to reach out and we’ll help you get them refined and published.
Other Stories in This Series
|↑I||NetSuite (March 4, 2011). Restricting Access to Custom Fields. Available at https://netsuite.custhelp.com/app/answers/detail/a_id/10096 [Accessed October 16, 2020]|