Misconfigured Custom Salesforce Apps Expose Corporate Data – Source: www.darkreading.com

Source: Peach Shutterstock via Shutterstock

A new security advisory warns Salesforce users with customized instances to check for common programming errors and misconfigurations that can expose their sales data.

At the heart of the problem is the Apex programming language, a Java-like tool that allows companies to add functionality to their Salesforce instances and developers to create apps for the Salesforce AppExchange marketplace. Simple errors and misconfigurations while using the tool, however, can result in vulnerabilities that undermine security of corporate Salesforce applications, security experts at data security firm Varonis say. 

Varonis researchers discovered that multiple government organizations and companies had customized or added on features to their Salesforce Apex code that leaked data, allowed data corruption, or allowed an attacker to disrupt business functions. The at-risk data included sensitive information such as phone numbers, home addresses, and SSNs, but also credentials, such as usernames and passwords, says Nitay Bachrach, senior security researcher at Varonis, who conducted the assessment. 

“In some cases, the exploitation was very tricky and required techniques we developed in-house, and in others, it was a simple oversight — the guest user was just able to execute code for no reason, and that leaked sensitive data,” he says. “Under the shared responsibility model, users can choose to write code, but they’re also responsible for making sure it is secure. Salesforce is not responsible for Apex code … uploaded by the users to their Salesforce instances.”

Salesforce Accounts and “Lax” Permissions

Varonis is the latest security firm to warn of common misconfigurations in Salesforce sites and applications, which often have run with lax permissions. The combination of the lack of security review of custom Apex code used in internal Salesforce instances and other components such as Lightning Communities has led to vulnerable sites and cloud applications, SaaS security firm AppOmni stated in a research paper in 2021.

In 2023, security researcher Charan Akiri, now at Reddit, discovered that Salesforce Apex misconfigurations allowed data to be accessed on more than 100 websites belonging to government agencies and large companies, such as banks and hospitals. 

The problem is likely widespread because the platform makes it easy to exceed permissions, says Brian Soby, chief technology officer and co-founder of AppOmni, who worked in product security at Salesforce for more than five years.

“By default, Apex can access any data and it doesn’t matter if the calling user is allowed to access that data,” he says. “So you can have a very limited user call into a VisualForce page or an Apex … and they could ask [for] data that they can’t get themselves, all because the Apex is running with heightened permissions.”

Apex Configuration Dangers

At the heart of the Apex issues is whether a developer designates an Apex class as “with sharing” or “without sharing.” Confusingly, the “without sharing” designation is the more dangerous of the two, allowing the Apex code to ignore the user’s permission, change any record, and commit those changes, Varonis stated in its advisory. 

“Apex classes that run ‘without sharing’ — ignoring the user’s permissions — are a powerful and important capability often required for proper functionality,” the advisory stated. “However, with great power comes great responsibility. This mode increases risk and should be used carefully, especially when assigned to guest or external users.”

When “without sharing” is set, the service is vulnerable to insecure direct object references (IDOR) — often referred to as Broken Object Level Authorization (BOLA) flaws. In 2023, the Open Worldwide Application Security Project (OWASP) released an updated top-10 list of API security issues that listed IDOR as the top risk for APIs. The “without sharing” attribute also allows more traditional flaws, such as database injection attacks, through the Apex code.

While Salesforce did not directly comment on the Varonis research, the company did stress that security is a top issue. In August 2023, the company released the top-20 issues that it discovered through its security scans of Apex apps published to its AppExchange marketplace. Sharing violations ranked No. 3 on the list.

“Nothing is more important to us than the security of customer data,” a Salesforce spokesperson said in a statement provided to Dark Reading. “In addition to our secure coding guidelines, which walk customers through common security issues Salesforce has identified while auditing applications built on or integrated with the Lightning Platform, we offer [several] services” for securing applications and data, the spokesperson said.

How to Protect Your Salesforce App

Varonis recommends that Salesforce developers avoid the “without sharing” configuration when possible, to check all user-supplied inputs, and take care when allowing guest users and external users any access to Apex classes.

Conducting a security assessment of all custom and third-party Apex software is critical, says Varonis’s Bachrach.

“We recommend securing all Apex classes, but would prioritize those that can be run by guest users, followed by those that can be run by external actors such as customers or partners,” he says. “Organizations need to follow best practices but also to keep track of access. They should keep the principle of least privilege in mind while writing the code, and while managing access to the Apex classes.”

Companies need to make sure that their developers are trained in how to securely create and manage Salesforce applications and instances, and enforce good security behavior, says AppOmni’s Soby. He has seen companies send links to specific pages that require no special permissions, giving them — theoretically — a launching pad for attacks.

“Salesforce didn’t set it up this way by default — this is the customer absolutely shooting themselves in the foot, because either they didn’t know what they were doing, or they didn’t understand the ramifications of what is, fairly, a very complicated configuration process,” he says. “Or they’re like, ‘We’re just gonna take the shortcut, and maybe nobody will notice,’ and then meanwhile, some script kitty runs code that they found on GitHub and sucks down your whole sales forecast.”