This article discusses the most common findings from a sample of over 35 security assessments of Salesforce customer deployments conducted by NCC Group. The assessments covered a mixture of configuration and code review based on our customers’ use of the Salesforce platform, not of Salesforce itself. The findings were sorted into broad categories, of which the most common are reviewed below.
Deviation From Salesforce Baseline Standard
This finding derives from the Health Check administration page, which compares a range of configuration settings (37 at the time of writing) against Salesforce’s own ‘Baseline Standard’. The Health Check warns if any value is out of line with this standard, with a severity based on both the nature of the affected setting and how far the configured value deviates from the standard. Since some of the baseline values are not the defaults found in a fresh Salesforce instance, it is unsurprising that deviations from the standard are common. Be aware that the ‘Standard Value’ quoted on the Health Check page doesn’t always capture the full range of values that meet baseline compliance according to the documented standard [1]. For example, the setting ‘User passwords expire in’ is shown as compliant with a configured value of ‘90 days’, even though the Standard Value quoted alongside is ‘30 days’. This is because the baseline standard for this setting is actually 30, 60 or 90 days.
Deviation From Security Best Practice
The Baseline Standard cannot cover everything. This category was used to cover misconfigurations that fall outside the standard, and incorporates Salesforce’s own guidelines [2] as well as general security best practice that could be applied to a Salesforce context. These findings were relatively simple in nature – or at least did not warrant a separate category. Examples include:
- Large number of System Administrators
- Wildcard certificates installed
- ‘My Domain’ not configured (this feature allows you to “create your own subdomain for your Salesforce org to better manage login and authentication” [3])
Authentication Issues
Many organisations delegate authentication to an external identity provider as part of a single sign-on (SSO) solution, meaning that the password policy for Salesforce users is also delegated. However, some accounts will still reside within Salesforce, in which case SSO is not used: the account holder authenticates with Salesforce directly. These accounts tend to be highly privileged so they should not be overlooked. Even if SSO authentication includes a second factor, the accounts that reside within Salesforce may not. Therefore, whether SSO is enabled or not, strong authentication policies for all Salesforce accounts is an important consideration. (The Baseline Standard includes several settings concerned with passwords but this issue warrants its own category.)
Each organisation will have its own take on what a secure password policy is – and that isn’t the subject of this article [4]. A noteworthy implementation point, though, is that “until you set the Password Policies on a Profile or click save on a profile (both standard and custom), the Organization-Wide Password Policies apply to its Users” [5]. This means this it is possible, perhaps unwittingly, to sever the inheritance of password settings from the top-level Organization policy. When this happens, a change made to the top-level policy will not be automatically propagated to all users.
Update 01/10/2020 – NCC Group’s tool SFPolDevChk can help to get quick visibility of any deviations in this area.
File Handling
The principal risk in this category is from the deliberate or accidental upload of a malicious file that is later downloaded by another Salesforce user. Salesforce makes it very clear that uploaded files “are not scanned for malicious content” [6]. Third-party solutions exist, but the decision to adopt one is clearly dependent on many factors. In one of the assessments reviewed for this article, it was notable that misconfigurations in a third-party solution weakened the effective security that it provided. That aside, it is important to remember that anti-virus should be seen as a defence-in-depth measure, not a silver bullet.
Insecure Code
One of the most powerful aspects of Salesforce is the ability to extend it with custom code. But with great power comes great responsibility. To allow developers the freedom they need, the Salesforce platform cannot wrap everything they do in a secure bubble. For example, a developer may assume that SOQL (Salesforce Object Query Language) statements, which are used to query the data store, always run in the context of the logged-in user, meaning that only data the user is allowed to access will be returned. That is not the case [7]. Equally, combining user input into a SOQL query requires deliberate action on the part of the developer to ensure it is done safely. Although the SOQL language is more restricted than classic SQL, vulnerabilities in this area could lead to unauthorised access to data, and could also affect data integrity if the results of SOQL queries are used in subsequent create, update or delete operations.
Unhandled Security Alerts
Salesforce releases security updates with a grace period so that customers can consider their effects and test them within a Sandbox to check for side effects before applying each update in their production environment. These notifications are collected in the ‘Security Alerts’ page. Alerts that are either overdue or have not been handled within a reasonable timeframe could reveal a potential lack of attention towards patch management. But it’s important not to over-state the risk here. The status of each alert (Required, Recommended or Info Only) does not relate to the severity of the issue being fixed but the potential for breaking changes. In addition, items that are overdue do not necessarily point to a missing patch: the patch might well have been applied, but it’s just that the recommended actions have not been completed (or at least acknowledged).
Critical Updates Pending
There’s some potential overlap between ‘Security Alerts’ and ‘Critical Updates’, which is a separate administration page that is broader in terms of the updates it covers. Salesforce will forcibly activate an update after its ‘Auto-Activation Date’ – exactly when is their choice, but in principle it won’t be before that date. If a Critical Update is not activated, it does not mean that a security patch is missing because this page covers functional updates too. As far as security updates are concerned, presumably the Auto-Activation Date is chosen to balance the impact of the vulnerability with the potential for breaking changes. So while outstanding security updates may be found, it is reasonable to assume that Salesforce would take quick and forcible action to patch any significant vulnerabilities.
A sensible impact assessment can only be made by reviewing the details of each individual update, but this can lack context without knowledge of the particular organisation. Add to that the broader viewpoint that, faced with multiple systems and components each with their own patching demands, some degree of prioritisation must be exercised. Nevertheless, a number of inactivated Critical Updates whose grace periods have expired, or are close to expiry, could show a potential lack of attention towards patch management.
Broken Access Controls
This article closes with the category of broken access controls, otherwise known as unauthorised access (distinct from unauthenticated access). Salesforce provides a number of ways to configure users’ access to data. An example is ‘sharing’, which governs record-level access. For example, having granted a user general access to Contacts, sharing controls which Contacts that user can view and edit. These controls are at risk from custom application code running in a privileged context because the user’s sharing permissions are ignored (Salesforce notes that code “without a sharing declaration is insecure by default” [8]). Because access controls can be broken through insecure configuration as well as code, it was considered a category in its own right. An example of the former would be excessive assignment of privileges like ‘View All Data’ and ‘Modify All Data’.
Qualifying this issue is heavily reliant on understanding the logical access needed by users to fulfil business processes, from which point instances of excessive access can be identified. A further consideration is bulk access. For example, while a sales user may be allowed to view and edit any Contact, it may be undesirable if that user can easily see the key details of all Contacts in a readily exportable format. Effective access controls in this area limit the overall risk from account compromise or malicious insiders. The contents of the ‘Public Reports’ folder is an area that could warrant review in this category.
Conclusion
Like Microsoft Active Directory and Group Policy, a Salesforce deployment must be carefully planned and managed to reduce the risk of unnecessary complexity compromising security. The addition of custom objects and code increases the potential for errors that expose vulnerabilities. This article only scratches the surface of Salesforce security but hopefully it has been a useful introduction to the topic.
Jerome Smith @exploresecurity
Thanks to Tanner Prynn @tannerprynn for reviewing this article
[1] https://help.salesforce.com/articleView?id=security_health_check_score.htm type=5
[2] For example, https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/overview_security.htm
[3] https://help.salesforce.com/articleView?id=domain_name_overview.htm type=0
[4] But if you want a modern view, start with https://www.ncsc.gov.uk/collection/passwords/updating-your-approach. In addition, however strict a password policy is and whether it’s applied inside or outside of Salesforce, enabling multi-factor authentication mitigates the risk from users choosing passwords that meet the technical policy but yet are still weak (Password1!).
[5] https://help.salesforce.com/articleView?id=000338935 type=1 mode=1
[6] https://developer.salesforce.com/docs/atlas.en-us.secure_coding_guide.meta/secure_coding_guide/secure_coding_platform_securityFAQs.htm > ‘File Upload’
[7] https://trailhead.salesforce.com/en/content/learn/modules/data-leak-prevention/learn-how-authorization-works-in-force-com-apps
[8] https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_keywords_sharing.htm
