ARTICLE / 安全

新型API架构与云原生Web攻防实战

Updated
Reading time
4 min

在云计算与前后端彻底分离的时代，Web 安全的战场已经从传统的 HTML 表单与关系型数据库，转移到了 RESTful API、GraphQL 以及云原生的基础设施上。 许多传统渗透手段（如 SQL 注入、文件上传）在这些新架构前收效甚微。红队需要转变思维，将目光投向 API 的逻辑缺陷以及云环境的元数据（Metadata）窃取。

本文将探讨如何在新一代 API 架构与云环境中撕开防线。

1. GraphQL 深度漏洞挖掘

GraphQL 允许客户端精确指定其需要的数据结构，解决了 REST API 的数据冗余问题。但其极高的灵活性，也带来了巨大的攻击面。

1.1 内省查询 (Introspection) 滥用

GraphQL 提供了一个极为“贴心”的功能：内省查询。它允许客户端向服务器查询整个 API 的 Schema（数据模型）。 如果开发者未在生产环境中禁用内省，红队只需发送如下查询，即可获取所有的数据结构、接口名称以及潜在的敏感内部字段：

query {
  __schema {
    types {
      name
      fields {
        name
        type { name }
      }
    }
  }
}

1.2 信息泄露与图越权 (Graph IDOR)

由于 GraphQL 将对象关联成图，攻击者可以通过遍历图结构来绕过直接的越权校验。 例如，无法直接查询 user(id: 1) { password }，但可以通过文章节点的作者关系进行越权窃取：

query {
  article(id: 100) {
    title
    author {
      id
      email
      passwordHash
    }
  }
}

如果后端的鉴权逻辑仅在顶层的 article 节点做了控制，而忘记限制嵌套子查询中的 author 敏感字段，就会导致严重的数据泄露。

1.3 嵌套查询引发的拒绝服务 (DoS)

GraphQL 允许无限制的嵌套查询。如果后端没有限制查询深度（Query Depth）或复杂度，攻击者可以构造深度循环嵌套的 Payload，耗尽服务器的 CPU 与内存：

query {
  author(id: 1) {
    posts {
      author {
        posts {
          author {
            # 无限循环嵌套...
            name
          }
        }
      }
    }
  }
}

2. REST API 安全缺陷突破

除了前文提到的批量分配（Mass Assignment）漏洞，REST API 还面临着版本失控与限流绕过的风险。

2.1 影子 API 与废弃版本探测

开发团队在迭代 API（如升级到 /api/v2/）时，往往会忘记下线旧版本的接口。 这些 /api/v1/ 甚至 /api/v0/ 或 /api/beta/ 的接口，可能仍连接着生产数据库，但却缺乏现代 WAF 的保护或最新的权限校验。 实战思路：使用工具（如 Kiterunner）对目标域名的 API 端点进行大规模爆破，寻找隐藏的 Swagger UI（如 /swagger-ui.html、/v2/api-docs），往往能发现未授权访问的内部接口。

2.2 绕过 API 限流机制 (Rate Limiting Bypass)

为了防止暴力破解，API 通常会基于 IP 进行速率限制。 绕过技巧：通过在 HTTP 头中伪造来源 IP，欺骗后端的限流组件（如 Redis）：

  • X-Forwarded-For: 127.0.0.1 (每次请求变换 IP)
  • X-Real-IP: 192.168.1.x
  • 在参数末尾附加空字符或改变参数类型（从 String 变为 Array），绕过业务层的限制逻辑。

3. 云原生攻防：打穿元数据服务 (IMDS)

当目标应用部署在 AWS、阿里云、腾讯云等公有云环境中时，一个小小的 SSRF 漏洞，其危害将被放大无数倍。

3.1 窃取实例元数据 (Instance Metadata)

所有的主流云厂商都在虚拟机实例中提供了一个固定的内部 IP（169.254.169.254），用于供实例自身查询配置信息、IAM 角色凭证等。 如果在云主机上发现了一个能够发起 GET 请求的 SSRF 漏洞，红队可以直接读取元数据：

# AWS IMDSv1 窃取临时安全凭证 (Access Key, Secret Key, Token)
http://169.254.169.254/latest/meta-data/iam/security-credentials/admin-role

3.2 突破 AWS IMDSv2 的防护

为了防御上述攻击，AWS 推出了 IMDSv2。它强制要求获取元数据时，必须先发送一个 PUT 请求获取 Token，并在后续的 GET 请求中通过 HTTP 头（X-aws-ec2-metadata-token）携带该 Token。 突破思路： 如果仅仅是一个普通的 GET SSRF 漏洞，确实无法突破 IMDSv2。但如果发现的是一个存在 CRLF 注入的 SSRF 或者 命令执行漏洞，就可以伪造完整的 PUT 请求或直接在宿主机内执行 curl，拿到凭证。

3.3 接管云上基础设施

通过上述元数据窃取拿到的 AccessKey，红队可以使用云厂商的 CLI 工具（如 aws-cli、aliyun-cli）直接在本地进行配置。

  • 接管 OSS/S3 存储桶：读取敏感数据或篡改静态页面。
  • 接管云数据库 (RDS)。
  • 如果获取到的 IAM 角色权限足够大，甚至可以向云主机的启动脚本（UserData）中注入反弹 Shell 的指令，实现对整个云端 VPC 的彻底降维打击。

4. 总结

在 API 驱动与云原生的架构下，攻防的焦点正在向上层业务逻辑和底层云服务权限转移。GraphQL 的图遍历越权、REST API 的未授权调用，以及云端 169.254.169.254 的致命一击，都表明了未来的 Web 渗透，不仅需要懂代码，更需要懂架构的演进与云基础设施的运行法则。

RELATED SIGNALS

继续探索