29、数据泄露与漏洞赏金：API 安全的实战洞察

数据泄露与漏洞赏金：API 安全的实战洞察

1. API 数据泄露案例

USPS 数据暴露事件凸显了 API 作为攻击向量常被忽视，以及使用正确工具和技术对其进行测试的紧迫性。下面以 T-Mobile API 泄露事件为例进行说明。

• 事件概述 ：2018 年 8 月，T-Mobile 官网发布公告，称其网络安全团队“发现并阻止了对某些信息的未授权访问”，同时通过短信提醒 230 万客户其数据已泄露。攻击者通过针对 T-Mobile 的一个 API，获取了客户的姓名、电话号码、电子邮件、出生日期、账户号码和账单邮政编码。
• 潜在漏洞分析 ：早在一年前，YouTube 用户“moim”就发现并披露了一个可能与此次泄露漏洞类似的 API 漏洞。在名为“T-Mobile Info Disclosure Exploit”的视频中，“moim”展示了如何利用 T-Mobile Web Services Gateway API。该漏洞允许用户使用单个授权令牌，然后在 URL 中添加任何用户的电话号码来访问数据。以下是请求返回数据的示例：

implicitPermissions:
0:
  user:
    IAMEmail:
      "rafae1530116@yahoo.com"
    userid:
      "U-eb71e893-9cf5-40db-a638-8d7f5a5d20f0"
    lines:
      0:
        accountStatus: "A"
        ban:
          "958100286"
        customerType: "GMP_NM_P"
        givenName: "Rafael"
        insi:
          "310260755959157"
        isLineGrantable: "true"
        msison:
          "19152538993"
        permissionType: "inherited"
      1:
        accountStatus: "A"
        ban:
          "958100286"
        customerType: "GMP_NM_P"
        givenName: "Rafael"
        imsi:
          "310260755959157"
        isLineGrantable: "false"
        msisdn:
          "19152538993"
        permissionType: "linked"

从这个端点可以看出，存在 BOLA（Broken Object Level Authorization）漏洞。因为如果可以使用 msisdn 参数搜索自己的信息，那么也可以用它搜索其他电话号码的信息，而电话号码通常是可预测且公开的。在利用视频中，“moim”从 Pastebin 的一次信息曝光攻击中获取了一个随机的 T-Mobile 电话号码，并成功获取了该客户的信息。

如果在 API 测试中发现此类问题，建议与提供商合作，获取带有不同电话号码的额外测试账户，以避免在测试过程中暴露实际客户数据。利用这些发现，描述真实攻击对客户端环境可能造成的影响，特别是如果攻击者暴力破解电话号码并泄露大量客户数据的情况。

2. 漏洞赏金案例

漏洞赏金计划不仅奖励黑客发现并报告可能被犯罪分子利用的弱点，其报告也是 API 黑客技术学习的绝佳资源。以下是几个不同的漏洞赏金案例。

漏洞猎人	赏金	发现漏洞情况
Ace Candelario	$2,000	他通过调查目标的 JavaScript 源文件，搜索 api 、 secret 和 key 等可能表示泄露秘密的术语，发现了用于 BambooHR 人力资源软件的 API 密钥。该密钥是 Base64 编码的，示例代码如下：

function loadBambooHRUsers() {
  var uri = 'https://api.bamboohr.co.uk/api/gateway.php/example/v1/employees/directory';
  return $http.get(uri, { headers: {'Authorization': 'Basic VXNlcm5hbWU6UGFzc3dvcmQ='}});
}

攻击者可以将此 API 密钥作为自己的参数在 API 请求中使用，或者对 Base64 编码的密钥进行解码。例如：

hAPIhacker@Kali:~$ echo 'VXNlcm5hbWU6UGFzc3dvcmQ=' | base64 -d
Username:Password

Candelario 还尝试使用这些凭证访问 HR 网站的敏感员工数据，并使用员工数据的屏幕截图作为证明。这种暴露的 API 密钥是身份验证漏洞的一个例子。 |
| Omkar Bhagwat | $440 | 通过目录枚举，他发现了位于 academy.target.com/api/docs 的 API 及其文档。作为未认证用户，他能够找到与用户和管理员管理相关的 API 端点。当他向 /ping 端点发送 GET 请求时，发现 API 无需任何授权令牌即可响应。在测试其他端点时，他收到包含“authorization parameters are missing”错误的 API 响应，随后发现许多请求使用了暴露的授权 Bearer 令牌。通过将该令牌添加到请求头中，他能够编辑用户账户并执行管理功能。此事件涉及 API 文档泄露敏感信息、身份验证漏洞和 BFLA（Broken Function Level Authorization）漏洞。 |
| Sam Curry | $4,000 | 在参与星巴克的漏洞赏金计划时，他发现并披露了一个漏洞，避免了近 1 亿条星巴克客户个人身份信息（PII）记录的泄露。据估算，如此规模的 PII 数据泄露可能使星巴克面临巨额损失。Curry 首先注意到星巴克礼品卡购买过程中向 /bff/proxy 端点发送的包含敏感信息的 API 请求。他尝试探测 /bff/proxy/orchestra 端点，但无法将用户输入传递到内部 API，而 /bff/proxy/user:id 端点允许用户输入通过代理。他通过使用 ..\ 进行目录遍历测试，最终发现了一个不同的错误消息“Bad Request”（错误代码 400）。利用 Burp Suite Intruder 暴力破解各种目录，他找到了一个 Microsoft Graph 实例，并查询该 API 证明可以访问内部客户数据库。他还通过添加查询参数 $count=true 得知数据库中有 99,356,059 条记录。此漏洞的发现得益于他对 API 响应的密切关注和在 Burp Suite 中过滤结果。 |
| Mayur Fartade | $30,000 | 2021 年，他在 Instagram 发现了一个严重的 BOLA 漏洞，允许他向位于 /api/v1/ads/graphql/ 的 GraphQL API 发送 POST 请求，查看其他用户的私人帖子、故事和卷轴。问题源于涉及用户媒体 ID 的请求缺乏授权安全控制。他使用的 POST 请求示例如下：

POST /api/v1/ads/graphql HTTP/1.1
Host: i.instagram.com
Parameters:
doc_id=[REDACTED]&query_params={"query_params":{"access_token":"","id":"[MEDIA_ID]"}}

通过针对 MEDIA_ID 参数并提供空的 access_token 值，他能够查看其他用户私人帖子的详细信息。 |

3. 学习经验总结

不同的案例为我们提供了以下学习经验：
- 通用经验
- 投入时间研究目标并发现 API。
- 始终留意凭证、秘密和密钥，并测试发现的内容的用途。
- 当对某个 Web 应用产生兴趣时，进行全面调查。
- 充分利用 API 文档中的信息。
- 结合发现的信息来发现新的漏洞。
- 特定经验
- 密切关注 API 响应之间的细微差异，使用工具如 Burp Suite Comparer 或仔细比较请求和响应，以识别 API 中的潜在弱点。
- 研究应用程序或 WAF 如何处理模糊测试和目录遍历技术。
- 利用规避技术绕过安全控制。
- 努力寻找 GraphQL 端点并应用相关技术，可能会获得丰厚回报。
- 当攻击首次失败时，结合规避技术再次尝试。
- 尝试使用不同的令牌绕过授权要求。

数据泄露与漏洞赏金：API 安全的实战洞察

4. API 安全测试流程总结

为了更好地保障 API 安全，我们可以总结出一套完整的测试流程，以下是详细步骤：
1. 测试方法确定 ：明确是采用黑盒、灰盒还是白盒测试方法。
2. 被动侦察
- 进行攻击面发现，全面了解 API 的暴露范围。
- 检查是否存在暴露的秘密信息。
3. 主动侦察
- 扫描开放端口和服务，了解系统的网络状况。
- 按照正常使用方式使用应用程序，观察其行为。
- 使用开发工具检查 Web 应用程序，分析其代码和请求。
- 搜索与 API 相关的目录，查找潜在的敏感信息。
- 发现 API 端点，确定测试的具体目标。
4. 端点分析
- 查找并审查 API 文档，了解 API 的功能和使用方法。
- 对 API 进行逆向工程，深入了解其实现细节。
- 按照正常使用方式使用 API，检查其响应是否符合预期。
- 分析响应内容，查找信息泄露、过度数据暴露和业务逻辑缺陷等问题。
5. 认证测试
- 进行基本的认证测试，验证认证机制的有效性。
- 攻击和操纵 API 令牌，检查令牌的安全性。
6. 模糊测试 ：对 API 的各种输入进行模糊测试，发现潜在的漏洞。
7. 授权测试
- 发现资源标识方法，了解系统如何识别和管理资源。
- 测试 BOLA 漏洞，检查是否存在对象级别的授权问题。
- 测试 BFLA 漏洞，检查是否存在功能级别的授权问题。
8. 批量赋值测试
- 发现请求中使用的标准参数，了解数据的传递方式。
- 测试批量赋值漏洞，检查是否存在数据过度赋值的问题。
9. 注入测试
- 发现接受用户输入的请求，确定可能存在注入风险的位置。
- 测试 XSS/XAS 漏洞，检查是否存在跨站脚本攻击的风险。
- 执行特定于数据库的攻击，检查数据库的安全性。
- 执行操作系统注入攻击，检查系统的安全性。
10. 速率限制测试
- 测试是否存在速率限制机制，防止暴力破解和滥用。
- 测试避免速率限制的方法，检查系统的抗攻击能力。
- 测试绕过速率限制的方法，发现潜在的漏洞。
11. 规避技术应用
- 在攻击中添加字符串终止符，绕过某些安全检查。
- 在攻击中添加大小写转换，规避一些简单的过滤机制。
- 对有效负载进行编码，隐藏攻击意图。
- 组合不同的规避技术，增加攻击的成功率。
- 对之前的所有攻击重复应用规避技术，确保测试的全面性。

以下是这个测试流程的 mermaid 流程图：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px

    A([开始]):::startend --> B(确定测试方法):::process
    B --> C(被动侦察):::process
    C --> C1(攻击面发现):::process
    C --> C2(检查暴露秘密):::process
    C1 --> D(主动侦察):::process
    C2 --> D
    D --> D1(扫描开放端口和服务):::process
    D --> D2(正常使用应用):::process
    D --> D3(使用开发工具检查):::process
    D --> D4(搜索 API 相关目录):::process
    D --> D5(发现 API 端点):::process
    D1 --> E(端点分析):::process
    D2 --> E
    D3 --> E
    D4 --> E
    D5 --> E
    E --> E1(查找并审查文档):::process
    E --> E2(逆向工程 API):::process
    E --> E3(正常使用 API):::process
    E --> E4(分析响应内容):::process
    E1 --> F(认证测试):::process
    E2 --> F
    E3 --> F
    E4 --> F
    F --> F1(基本认证测试):::process
    F --> F2(攻击和操纵令牌):::process
    F1 --> G(模糊测试):::process
    F2 --> G
    G --> H(授权测试):::process
    H --> H1(发现资源标识方法):::process
    H --> H2(测试 BOLA 漏洞):::process
    H --> H3(测试 BFLA 漏洞):::process
    H1 --> I(批量赋值测试):::process
    H2 --> I
    H3 --> I
    I --> I1(发现标准参数):::process
    I --> I2(测试批量赋值漏洞):::process
    I1 --> J(注入测试):::process
    I2 --> J
    J --> J1(发现接受输入请求):::process
    J --> J2(测试 XSS/XAS 漏洞):::process
    J --> J3(数据库特定攻击):::process
    J --> J4(操作系统注入攻击):::process
    J1 --> K(速率限制测试):::process
    J2 --> K
    J3 --> K
    J4 --> K
    K --> K1(测试速率限制存在性):::process
    K --> K2(测试避免速率限制方法):::process
    K --> K3(测试绕过速率限制方法):::process
    K1 --> L(规避技术应用):::process
    K2 --> L
    K3 --> L
    L --> L1(添加字符串终止符):::process
    L --> L2(添加大小写转换):::process
    L --> L3(编码有效负载):::process
    L --> L4(组合规避技术):::process
    L --> L5(重复应用规避技术):::process
    L1 --> M([结束]):::startend
    L2 --> M
    L3 --> M
    L4 --> M
    L5 --> M

5. 总结与建议

通过对多个 API 数据泄露和漏洞赏金案例的分析，我们可以看到 API 安全问题的严重性和复杂性。攻击者可以利用各种漏洞获取敏感信息，给企业带来巨大的损失。为了提高 API 安全性，我们可以采取以下措施：
- 积极参与漏洞赏金计划 ：鼓励安全研究人员发现并报告 API 中的漏洞，及时修复潜在的安全隐患。
- 关注 API 安全新闻 ：了解最新的 API 安全威胁和防护技术，及时调整安全策略。
- 持续提升技能 ：参与 CTF 竞赛、在线安全学院等活动，不断提升自己的 API 安全测试技能。

希望大家能够从这些案例中吸取经验教训，不断完善 API 安全测试方法，为保障网络安全贡献自己的力量。祝愿大家在 API 安全测试的道路上取得丰硕的成果，发现更多的关键漏洞，为互联网的安全稳定运行保驾护航。