Since 2010, Onapsis Research Labs has focused on continuously analyzing and investigating developments in mission-critical applications to discover and identify new vulnerabilities. To date, they have discovered over 800 zero-day vulnerabilities, and multiple CERT critical alerts have resulted from their novel research.
Previously, the team exclusively focused on SAP and Oracle on-premise systems. However, as enterprise business-critical applications have added cloud offerings, and organizations turn towards native SaaS applications to run their business, the Onapsis Research Labs have broadened their research and investigations to include vulnerabilities in many of these applications, such as Salesforce.
The Salesforce Winter ‘21 patch for Aura should remediate the security risk that allowed any authenticated user the ability to use web services exposed with the @auraenabled decorator. However, Onapsis Research Labs has some security concerns that we found within Aura that we’ll be covering in this blog post. Our concern focuses on using @auraenabled decorator in combination with the ‘without sharing’ annotation. To quote the Salesforce documentation about this annotation: “Use the without sharing keywords when declaring a class to ensure that the sharing rules for the current user are not enforced.”
What Is Aura?
The Client-Side Controller receives the message when the search action is executed in the form of “events” and sends the information to the server. It has no direct access to Salesforce’s information or database, it runs in the client (i.e., a web browser). It builds the corresponding HTTP requests with the information provided by the user and sends them to another resource: the Server-Side Controller.
The Server-Side Controller is not part of the Aura component. Technically, it is an Apex class, a template to create objects used by external resources, just like a web service. It is created using @auraenabled annotation methodology.
‘Without Sharing’ Annotation Vulnerability
Now that we have explained Aura, let’s outline the security vulnerability we found using @auraenabled in combination with the ‘without sharing’ annotation.
For example, consider a created Salesforce user with a profile that does not have access to the Contact default object. In other words, this user should not have access to Contacts in Salesforce. Meaning, if the user puts a name in the contact search box and executes the function, no contacts will be returned. The Server-Side Controller will not allow the contacts to be seen by the user, since the user doesn’t have the right to see Contacts.
However, despite this user’s profile, if the ‘without sharing’ keyword is added to the Server-Side Controller, when the user executes this search, contacts will be returned. This result is concerning because it means that even if the user has no privileges to access Contacts, because the “without sharing” keyword is in place, they are shared anyway. There is no authorization check to validate whether the user should have this access, it is just enabled.
The “without sharing” keyword is a dangerous modifier that should be used with extreme care, since it enables any user to access functions, despite their authorizations. Complicated issues could arise when adding this tag to any Apex class, but if some method of this class is decorated with @auraenabled, even greater security issues may arise. Salesforce has developed the Aura enabled scanner with this in mind.
The Aura Enabled Scanner
The AuraEnabledScanner helps developers and administrators list all classes inside an organization which have at least one method using @auraenabled. In addition, it highlights those classes which should not be easily accessible and allows configuration of who should access them with an easy-to-use interface.
Despite the method to fix this vulnerability, configuring all of these authorizations, especially in production organizations, is a challenging task. An organization may have dozens, even hundreds of methods decorated with @auraenabled. This results in an incredibly complex process setting up which users should have access to which classes, and making sure all users and classes are included in the analysis.
It is important to note that misconfigurations and vulnerabilities can potentially happen when administrators are building allow list configurations under the pressure of time in order to fix a security issue. Sometimes, administrators and developers lack the time to properly set correct values and may default to adding everything just to get it up and running. It is critical to implement this remediation with care.
To learn more about Onapsis and Salesforce, read our blog or watch our on-demand webinar about cybersecurity and compliance for Salesforce.