During one of security audits of a web application, I uncovered an interesting vulnerability: the exposure of an endpoint that allows users to perform arbitrary Salesforce Object Query Language (SOQL) queries. Such functionality, when available to unauthorized users or misconfigured, poses significant security risk, especially if Row-Level Security (RLS) permissions are not properly set. In this article I will analyze technical aspects of this vulnerability, the potential risks, and steps to mitigate such issues.
Understanding the Vulnerability
Salesforce Object Query Language (SOQL) is a query language designed to interact with Salesforce databases. It allows users to extract specific data from Salesforce objects, similar to SQL in traditional databases. However, the ability to perform unrestricted SOQL queries is not something typically granted to end users. When this capability is exposed, it opens up the possibility for attackers to execute complex queries and exfiltrate data from the database.
In the tested application, an endpoint that provided unrestricted access to perform SOQL queries was identified. This functionality is typically reserved for system administrators or specific internal processes, not for general users. As with traditional SQL, Salesforce apps are expected to receive only desired values (parameters) from users, sanitize them, and pack into a full query. Such behavior becomes particularly dangerous if the application’s RLS permissions are not configured correctly.
A Real-World Example
To better understand how this vulnerability can be exploited, consider the scenario that took place during the audit:
- First, the following request was spotted within application traffic:
There are two interesting properties of this request. One is the presence of a plain SOQL query:
The other detail that caught my attention is that destPath parameter takes a relative URL as its value, with the SOQL query:
In response the server returns details of the given object:
Interestingly, an attempt to query the API directly (not through the destPath param), i.e. through an URL like $HOSTNAME/services/data/v61.0/query?q= returns 401 Unauthorized error. This is a REST API endpoint that should not be available to regular users and is disabled in organization’s settings, yet one can reach it through the request above.
But that’s just one table (object) from the database. How do we extract more data?
- One of the standard Salesforce API actions is:
This is triggered on the /aura endpoint during regular web app usage, revealing custom object names used by the application. Throughout my browsing I’ve gathered a number of such requests and responses, each containing objects’ names. How do we extract them all from Burp now? Well, you can try Burp’s Search menu and parse that, or you can just:
Note that the regex looks for strings that end with __c – this is characteristic for custom Salesforce entities. This way more than 3000 names were obtained:
These were one more time passed to the Aura’s getObjectInfo endpoint through Burp Intruder in order to enumerate even more names – some names were only revealed within attributes of complete objects.
- Once object names were identified, the following HTTP request was sent to the vulnerable endpoint:
This response includes all of the information about the object, such as the ID, creation dates, and all the other business-specific details. If an attacker had continued querying different objects or fields, they could have gradually extracted a significant amount of confidential information.
How to protect your application?
First, it’s important to restrict access to the query functionality. Only authorized users, such as administrators, should have the ability to execute SOQL queries. Regular users should never be allowed to run full queries on their own, as this could open the door to perform malicious actions.
Another critical thing is to enforce strong Row-Level Security (RLS) and object-level security. This ensures that users only have access to the data they are permitted to see. Proper configuration of these permissions within is essential to prevent unauthorized access to sensitive information.
In addition to limiting who can run queries, it’s a good idea to restrict the types of inputs users can provide. Rather than allowing users to create arbitrary queries, consider providing predefined filters or search options.
Finally, monitoring and logging query activity is crucial. By keeping a close eye on how users are interacting with the query system, you can detect unusual or malicious behavior early on. If someone is making excessive requests or trying to access restricted data, these actions can be flagged and investigated before any real damage occurs.
Conclusion
Exposing SOQL query functionality in an application without proper restrictions poses significant security risks. While SOQL is a powerful tool for interacting with Salesforce databases, unrestricted access can lead to severe data breaches. Organizations must take proactive steps to ensure that query access is properly limited, RLS permissions are correctly configured, and query activity is carefully monitored to prevent exploitation. By addressing these risks early, businesses can protect themselves from potentially costly security incidents.
