Salesforce is known as ‘the most secure SaaS platform’. While this is true initially, Salesforce can be open to attacks when it’s developed by writing custom code, adding integrations, or changing configurations.
An attack surface is the sum of different points where a malicious user can enter data in order to extract other, business-sensitive data. To avoid putting your organization at risk, it’s important to know about these common vulnerabilities to data in Salesforce, and how you can take care of them.
The three risks I’ll be discussing in this post are:
- Authorization Bypass
- Stored Cross-site Scripting
- SOQL Injection
I’ll outline what dangers these risks cause, explain how to prevent each one, and let you know about a software tool that can help you pinpoint and resolve them.
Authorization Bypass
Authorization, or access control, is one of the most important security controls in multi-user environments. If set-up correctly, each role in the system will only be able to use and view the resources or functions which were intended for them.
However, implementing these various authorization schemas can leave your application susceptible to hackers and vulnerabilities if not done correctly.
Authorization weaknesses are commonly introduced:
- When a single-user application is transformed into a multi-user environment
- If the developer has a lack of understanding of how the platform operates and what access controls are available
- If the developer isn’t aware of inputs a hacker can manipulate (cookies, headers, etc.)
As a Salesforce user, it’s important to know the specifics of how authorization works on the platform, and how a hacker could navigate around it to access your data.
The common misunderstanding is that Authorization checks do not need to be performed when CRUD (Create Read Update Delete) function are called in Apex classes. The server-side code of Apex class and SOQL statements have complete access; therefore, it is the responsibility of the developers to perform the necessary checks before using any of the following CRUD functions in Apex:
Select in SOQL
update();
delete();
insert();
A typical attack on an Authorization Bypass vulnerability requires a malicious user to submit a request for an object Id a user does not have access to. For example, let’s say the controller associated with the following page doesn’t enforce authorization:
http://na23.salesforce.com/apex/vulnerablepage
This page takes an Id parameter, then displays sensitive information based on the Id. As the controller fails to implement authorization, a malicious user can supply a valid Id and gain access to the sensitive information:
http://na23.salesforce.com/apex/vulnerablepage?Id=00Q5000001E0ZHB
The above request will be processed and lead to a data breach.
Stored Cross-site Scripting (XSS)
The most dangerous form of Cross-site Scripting (XSS) is stored XSS. Unlike other forms of cross-site scripting, this type does not require a malicious link to be exploited.Instead, it can hide on any page of a web application which gathers input from a user and stores it for future use. If a user inputs malicious data, it will not be filtered correctly into the system. As a consequence, the input is able to blend into the website and run in the browser with the same permissions as the web application.
Once exploited, stored XSS can conduct the following browser-based attacks:
- Hijacking another user’s browser
- Saving confidential information viewed by different users
- Defacement of the application
- Port scanning of internal hosts
To check for stored cross-site scripting, do black box testing. This method of testing looks at the functionality of an application without digging into the internal structures or workings. It’s efficient for large segments of code does not require code access, and can provide a separation between the users’ and developers’ perspectives.
Things to examine when black box testing:
- Input forms: identify all the places where user input is stored into the backend and displayed by the application.
HTML code: analyze code where input is stored and understand how it’s positioned in regards to the page.
SOQL Injection
SQL (Structured Query Language) enables an application to store and retrieve information from a database. SOQL (Salesforce Object Query Language), a bare bones version of SQL, is what Salesforce uses to interact with data.
Now that responsive applications enable users to supply input and retrieve database information, Salesforce organizations are at risk to SOQL injection.
SOQL injection is when a hacker uses characters in an input form to modify the resulting query. These characters have special meaning to SOQL, and would not be used by a typical user.
Why are SOQL injections common?
Salesforce developers sometimes fail to set-up user input validation methods. Without these, the platform puts complete trust in the integrity of its users and their input.
To prevent SOQL injection, it’s important to utilize the following:
- Static queries with bind variables
- String.escapeSingleQuotes()
- Type casting
- Replacing characters
For more information on what these methods are and how to implement them, check out the Salesforce Trailhead on preventing SOQL injection in your code.
Summary
In summary, authorization bypass, stored cross-site scripting and SOQL injection are all common risks to your Salesforce data. Prevent them by first understanding the fundamentals of how each risk occur. Then, make sure you are using security best practices. These include lower level steps such as utilizing static queries with bind variables, and higher level steps such as regularly scanning your Salesforce instance with a SaaS security scanner.
How S4 – SaaS Security Scanner for Salesforce can help
At DigitSec, Inc., we developed a SaaS security scanner for Salesforce called S4. S4 identifies vulnerabilities in APEX code developed using the Force.com development environment. It is a 100% native Force.com application and uses a combination of static code analysis and runtime testing to uncover threats and weaknesses in your Salesforce instance.
If you are concerned about risks to data in your Salesforce org, S4 can help by:
- rapidly identifying Authorization Bypass vulnerabilities.
- using its robust runtime fuzzing engine to detect XSS vulnerabilities (both stored and reflected).
With one click, S4 enables companies to pull up an application security report with detailed findings. Each finding is prioritized based on the risk and impact to your data and provides a clear guidance on how to secure your Salesforce instance.
To learn more about the vulnerability coverage offered by S4, check out this datasheet, or run the freemium version of our product in a staging or test environment.
Comments: