Security researchers warn that many organizations have instances of insecure Apex code in their Salesforce deployments which open serious vulnerabilities that put their data and business workflows at risk. Researchers from security firm Varonis reported finding high and critical severity vulnerabilities in the Apex code used by multiple Fortune 500 companies and government agencies, but warn that similar insecure practices are likely common inside organizations of all sizes and from all industries.
“If exploited, the vulnerabilities can lead to data leakage, data corruption, and damage to business functions in Salesforce,” the researchers said in a report. “That’s why keeping track of Apex classes and their properties, who can execute them, and how they’re used is vital.”
Insufficiently restricted Apex classes can lead to flaws
Apex is an object-oriented programming language whose syntax is similar to Java that developers can use to execute flow and control statements on Salesforce servers together to calls via the Salesforce API. Apex allows users to customize their Salesforce instances by adding additional business logic to system events, including button clicks, related record updates and Visualforce pages.
According to Salesforce’s documentation, Apex code can make data manipulation language (DML) calls, make Salesforce Object Query Language (SOQL) and Salesforce Object Search Language (SOSL) queries to return lists of sObject records, perform bulk processing of multiple records at the same time, be used to build custom public API calls from stored Apex methods, and much more.
“An Apex class is a template or blueprint used to create Apex objects,” the Varonis researchers said. “Classes include other classes, user-defined methods, variables, exception types, and static initialization code.”
This makes Apex classes a powerful tool for developers, but also very important to carefully review their capabilities and restrict who can access them. Apex code can run in two modes: “without sharing,” where the Apex code ignores the user’s permissions and can access any record and commit changes, and “with sharing” where the code respects the user’s record-level permissions but ignores object-level and field-level permissions.
Apex classes configured to run in “without sharing” mode are sometimes required to implement important functionality, but they can become a serious risk, especially when they’re made available to guests or external users. Some of the most common types of issues that can derive from Apex classes are insecure direct object references (IDOR), which can allow an attacker to read, manipulate or delete full tables of data they shouldn’t otherwise have access to, or SOQL injection; and SOSL injection where the code has flaws that allows attackers to manipulate the queries made by the class to exfiltrate data or change the intended process flow.
“Vulnerabilities and misconfigurations can have dire consequences,” the Varonis researchers said. “Many of the discovered vulnerabilities were assigned high and critical severity by the security teams at the affected organizations.”
While the researchers haven’t described each vulnerability in detail, their report includes a proof-of-concept example where an attacker with guest access abuses an over-permissive class to access a secret value from a custom field in other users’ records.
How to mitigate Apex vulnerabilities
The Varonis researchers encourage organizations to review who can call the different Apex classes used in their instances and their capabilities, especially classes that run in “without sharing” mode. This can be done manually by going through each class, but it’s a time-consuming process.
“To determine who can call an Apex class, you must check both Profiles and Permission Sets (as of Winter, if you click ‘Security’ while reviewing the Apex class itself, you will only see Profiles, which is not enough to determine who can call an Apex class),” the researchers warn. The proper way to do it is to first go into the User section and then Profiles and then check the “Enabled Apex Class Access” within each Profile. Then for each entry in the Enabled Apex Class Access, the administrator must scroll to the Apps section and click on the Apex Class Access option to see the rights.
Furthermore, to check if an Apex class is configured to run “without sharing,” its source code can be reviewed, as the string “without sharing” will be in one of the first lines of the class declaration.
The Varonis report also includes best practices on how to secure Apex code to avoid insecure input that can lead to SOQL or SOSL injection. Based on the shared responsibility model, its Salesforce customers and not Salesforce who are responsible for the security of their Apex code. “A comprehensive security strategy should verify that Apex classes have been reviewed by security specialists, not only Salesforce developers and admins,” the researchers said. “This is usually the case for code that is part of an AppExchange package, but it’s not always true for other non-AppExchange codes. This especially applies to in-house code, which is often neglected.”