Varonis Threat Labs 在 Apex（一种类似 Java 的编程语言，常用于定制 Salesforce 实例）中发现了高危和严重的漏洞和配置错误。
Varonis 研究人员在多家财富 500 强企业和政府机构中发现了这些 Apex 问题，并向受影响的组织报告了这些漏洞。
Varonis Threat Labs 警告说，这些风险并不局限于大型组织。由于许多 "现成的 "应用程序都使用 Apex 代码，因此许多行业的各种规模的组织都面临风险。
如果漏洞被利用，可能会导致 Salesforce 中的数据泄漏、数据损坏和业务功能受损。这就是为什么跟踪 Apex 类及其属性、谁可以执行它们以及如何使用它们至关重要的原因。
在责任共担模式下，Salesforce 客户而不是 Salesforce 对其实施的 Apex 代码的安全性负责。由于客户实施了 Apex，因此他们也必须修复易受攻击的 Apex 类、触发器或代码。
Apex 编程语言允许用户编写自己的代码和逻辑。它是用于定制 Salesforce 实例的最常用工具之一。开发人员使用这种强类型、面向对象的语言，结合对 Lightning Platform API 的调用，在 Salesforce Lightning Platform 服务器上执行流程和事务控制语句。
Apex使开发人员能够为大多数系统事件（包括按钮点击、相关记录更新和Visualforce页面）添加业务逻辑，使用的语法看起来像Java，操作起来像数据库存储过程。Apex 代码可以通过网络服务请求和对象上的触发器启动。
Apex 类是用于创建 Apex 对象的模板或蓝图。类包括其他类、用户定义的方法、变量、异常类型和静态初始化代码。
Apex 为 Salesforce 的许多功能提供了支持，也正是它使 Salesforce 变得如此强大和可定制，但这也可能导致漏洞。
Apex 漏洞
Apex 代码可以在两种不同的模式下运行：
"无共享"--这种模式意味着 Apex 代码忽略用户的权限；代码可以访问任何记录并提交更改。
"有共享"--这种模式意味着 Apex 代码尊重用户的记录级权限，但仍然忽略对象级和字段级权限。
可以 "不共享"（忽略用户权限）运行的 Apex 类是一种强大而重要的功能，通常是实现正常功能所必需的。然而，权力越大，责任越大。这种模式会增加风险，应谨慎使用，尤其是在分配给访客或外部用户时。
不共享 "模式最常见的两个风险是：
不安全的直接对象引用（IDOR）会允许用户读取甚至外泄他们本不应该访问的整表数据。这还可能导致数据完整性问题，因为用户可以篡改数据或删除属于其他用户的文件和记录。
Apex 代码可能存在漏洞，就像其他编程语言一样。这意味着有人可能会以非预期的方式使用代码，或提供特制输入以利用代码中的漏洞和错误。常见的例子包括 SOQL 注入和 SOSL 注入，这意味着攻击者可以操纵类运行的查询，改变流程并允许数据外渗。
漏洞和错误配置会带来可怕的后果。受影响组织的安全团队将许多已发现的漏洞定为高度严重和严重级别。
滥用易受攻击的 Apex 类
在本示例中，我们将演示如何使用存在漏洞的 Apex 类，在未经许可的情况下从用户记录中检索数据。为了安全地演示这些漏洞，VTL 根据他们遇到的真实 Apex 代码漏洞创建了一个 Salesforce 环境。
第一步是执行侦查。在这个示例中，我们将从用户字段中检索数据，我们将其命名为 "VerySecretFlag"，但它可能是电话号码、社会安全号或其他敏感数据。
正如我们之前的研究 "滥用配置错误的 Salesforce 社区进行侦察和数据窃取 "中所提到的，攻击者可以使用 aura 方法 "aura://RecordUiController/ACTION$getObjectInfo "来获取系统中用户的更多信息。
使用 aura 方法，攻击者可以从系统中获取用户元数据。
其中有一个名为 "VerySecretFlag__c "的自定义字段，但由于用户只能检索自己的数据，因此无法访问。尝试执行操作（例如查询字段 "CreatedBy.VerySecretFlag__c"）并不能返回其他用户的字段值。访客用户无法读取其他用户的 "VerySecretFlag "值。
Aura 调用不足以读取其他用户的数据值。
这意味着我们需要在没有权限的情况下读取一个值。如果我们提交一个表单来创建一个案例，我们可以看到它调用了 "apex://CaseCreationController/ACTION$createCaseR "方法。
自定义 Apex 类通过 "AuraEnabled "方法分配给访客用户，使其可以使用 Aura 调用。请注意，我们可以为希望存储过程返回的字段命名。
提交表单后，就会显示使用的是哪种 Apex 类。
有趣的是，除了 Apex 之外，包括 Aura 在内的任何其他方法都无法检索返回的案例。这意味着访客用户无法以其他方式访问该记录。这可能表明 Apex 类是在 "不共享 "的情况下运行的。要检索 "VerySecretFlag "的值，攻击者需要一个配置为不共享运行的类。
正如我们前面所观察到的，我们可以为要检索的字段命名。因此，如果我们想要秘密标志，我们可以指定字段 "CreatedBy.VerySecretFlag__c"。通过滥用超权限类以及我们可以指定字段来获取其他对象的字段这一事实，我们可以检索到 "VerySecrectFlag "的值。
攻击者可以通过命名要检索的字段并使用易受攻击的 Apex 类来检索有权限的数据。
缩小爆炸半径。
Apex 是 Salesforce 中至关重要的构建模块。要加强 Salesforce 实例的安全性，关键是要检查您拥有的不同 Apex 类，尤其是那些 "不共享 "运行的类。
虽然这个过程可以手动完成，但需要大量的时间和精力。
要确定谁可以调用 Apex 类，必须同时检查 "配置文件 "和 "权限集"（从 Winter 开始，如果在查看 Apex 类时单击 "安全性"，则只能看到 "配置文件"，这不足以确定谁可以调用 Apex 类）。要开始操作，请导航到当前应用程序的 Salesforce 设置。
然后，必须展开 "管理 "下的 "用户 "部分，并选择 "配置文件"。
这里就变得复杂了。首先，您必须点击列表中的每个配置文件，检查顶部 "已启用 Apex 类别访问权限 "部分中的内容，或向下滚动到配置文件中的 "已启用 Apex 类别访问权限 "来查看权限。
必须查看每个配置文件的 "已启用 Apex 课堂访问权限"。
然后，您需要检查每个条目的权限集，方法是逐个点击，然后向下滚动到 "应用程序 "部分，查找 "Apex 类别访问 "选项。查看分配给配置文件和权限集的用户，这将显示哪些用户可以访问这些 Apex 类。
Apex 类访问权限控制执行 Apex 类的权限。
单击 "Apex 类访问 "选项查看权限。
要查看 Apex 类是否配置为 "不共享 "运行，需要查看该类的源代码。查看类的声明（通常是第一行）。如果其中包含 "不共享 "字符串，则该类将忽略共享，并能访问所有记录。
必须单独编辑每个 Apex 类才能修复此漏洞。
这一过程需要大量人力。不过，Varonis 客户可以在相关态势下的 "态势 "页面中查看访问权限。您可以使用过滤器（例如，标题包含 "Apex"）或滚动直到找到 Apex 类。在 "受影响的资源 "下，你会看到访客用户可以执行的所有未共享运行的 Apex 类。你可以点击任何 Apex 类了解更多信息，例如可以执行该类的所有用户。
Varonis 客户可以通过事件监控轻松监控 Apex 的使用。
启用事件监控后，您可以查看哪些访客、社区和内部用户正在调用 Apex 方法，并删除不必要的权限。Varonis 还将事件监控集中起来，为全面覆盖 Salesforce 提供一站式服务。
最后，验证 Apex 类的创建是否安全。
Salesforce 引入了许多确保内部代码安全的方法，例如在 SOQL 查询中包含用户输入的安全方法。
请注意":queryName "语法--这可确保输入不会被用于注入 SOQL。避免不正确的编程模式，例如：
当无法使用 Salesforce 的安全输入功能时，例如，当用户需要选择要检索的字段时，必须对输入进行消毒。
此外，还可以考虑在查询中添加 "WITH SHARING_ENFORCED"，以执行对象和字段级别的权限。请注意，添加 "WITH SHARING_ENFORCED "只会影响 SELECT 子句，而不会影响 WHERE 子句。
以下函数不安全：
它容易受到 SOQL 注入的影响，而且没有执行安全性。
我们可以通过验证字段不包含非字母数字字符（或下划线），并在查询中添加 "WITH SECURITY_ENFORCED "来确保该函数的安全性，这样用户就只能查询他们有权访问的字段，而且只有在他们可以访问的情况下才能开始查询。
全面的安全策略应确保 Apex 类经过安全专家的审核，而不仅仅是 Salesforce 开发人员和管理员的审核。作为 AppExchange 软件包一部分的代码通常是这种情况，但其他非 AppExchange 代码并非总是如此。这尤其适用于经常被忽视的内部代码。
易受攻击的 Apex 类可能会导致数据泄漏和损坏。由于 Salesforce 客户对其实施的 Apex 代码的安全性负有最终责任，因此企业必须安全地管理 Apex 类及其属性、谁可以执行它们以及如何使用它们。
