Insecure Apex code plagues many Salesforce deployments
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.
