API接口安全实战指南：从探测分类到手工测试常见漏洞

在数字化时代，API 已成为数据交互的绝对核心，但也带来了日益严峻的安全挑战。在日常的渗透测试或安全评估中，我们经常会遇到各式各样的接口文档或接口地址。本文旨在梳理和总结 API 层面常见的攻击面，提供从探测识别到工具、手工测试的实用思路。笔者在此领域也是不断学习中，如有疏漏，欢迎在技术社区交流指正。

0x01 API 主要分类

了解目标使用的 API 类型，是进行有效安全测试的第一步。

SOAP - WSDL

SOAP（简单对象访问协议）是一种用于在分布式环境中交换结构化信息的协议。它定义了信息传递的格式和编码规则，常用于连接 Web 服务与客户端，是一种跨平台、跨语言的通信协议，其消息格式为 XML。

FOFA 探测语法：?wsdl

如上图所示，展示 SOAP 接口文档的页面，其 URL 后缀通常为 .asmx。在 .asmx 后添加 ?wsdl 参数，通常会以 XML 格式返回完整的接口描述文档（WSDL）。

OpenAPI - Swagger

OpenAPI 规范（OAS）是一种用于描述 RESTful API 的标准格式。而 Swagger 是一套围绕 OpenAPI 规范构建的开源工具集，可以帮助设计、构建、文档化和使用 API。我们常说的 “Swagger 文档” 就是基于 OpenAPI 规范生成的。

FOFA 探测语法：Swagger-UI

RESTful

REST（表述性状态传递）是一种 Web 服务架构风格，它是一种设计理念而非具体协议。RESTful API 通常具有清晰的资源定位和标准的 HTTP 方法，其版本号常出现在路径中，如 /v1/api。

0x02 如何判断网站使用的接口类型

识别 WSDL/SOAP 接口

方法一：观察 URL 特征
当站点交互时，请求 URL 以 .asmx 结尾，这很可能是一个 SOAP 服务端点。

方法二：端口服务推测
在同一 IP 的不同端口上，如果发现类似下图的简易服务列表页面，也可能指向 WSDL 接口。

识别 Swagger 接口

方法一：检查网络资源
在浏览器开发者工具的 Network（网络）选项卡中，查看加载的 JS 或发起的请求，寻找对 swagger.json、swagger-ui 等关键词的调用。

方法二：目录扫描探测
通过目录扫描工具，尝试访问以下常见路径，如果返回 Swagger UI 或 JSON 文档，则证明存在。

/swagger
/api/swagger
/swagger/ui
/api/swagger/ui
/swagger-ui.html
/api/swagger-ui.html
/user/swagger-ui.html
/libs/swaggerui
/api/swaggerui
/swagger-resources/configuration/ui
/swagger-resources/configuration/security

0x03 利用工具进行 API 安全测试

WSDL 接口测试工具

使用 SoapUI 或 ReadyAPI 等专业工具可以高效地对 SOAP 服务进行安全测试。

选择 “New Security Test” -> “API Definition”，输入 WSDL 文件的 URL 地址。

在下一步中，选择需要执行的扫描类型，例如 SQL 注入、XML 外部实体等漏洞检测。

配置完成后，工具便会开始自动化的安全测试。

Swagger 接口测试工具

对于 Swagger 接口，有一些自动化测试脚本可供选择，例如：

• https://github.com/lijiejie/swagger-exp
• https://github.com/jayus0821/swagger-hack

以 swagger-hack 为例，它能够自动爬取并测试 Swagger 文档中的所有 API 接口。使用非常简单，直接在命令行中指定 Swagger JSON 文件的 URL 即可。

python3 swagger-hack2.0.py -u http://x.x.x.x:8080/swagger/v1/swagger.json

APIKit Burp Suite 插件使用

APIKit 是一款基于 BurpSuite Java API 开发的强大插件。它能够主动或被动地扫描发现应用中泄露的 API 文档（如 Swagger、WSDL），并将这些文档解析成 Burp Suite 中的请求数据包，极大方便了后续的安全/渗透测试工作。下图展示了其支持的 API 类型探测能力：

下载地址：https://github.com/API-Security/APIKit

安装非常简单，在 Burp Suite 的 Extender 选项卡中，添加该 jar 文件即可。

安装成功后，在 APIKit 标签页中有两个关键选项：

1. Auto request sending: 对发现的 API 端点进行自动化鉴权测试，快速发现未授权访问漏洞。
2. Send with cookie: 生成请求时保留当前会话的 Cookie，用于带认证状态的测试。

重要提醒：“Auto request sending” 功能需谨慎使用。它会自动对所有发现的 API 路径进行请求，可能对生产业务造成影响，务必在授权测试范围内使用。

启用被动扫描后，当流量经过 Burp，APIKit 会自动识别并解析 API 文档。

如上图，插件不仅发现了接口，还自动生成了测试参数。我们可以直接将请求发送到 Repeater 模块进行手动深入测试。

0x04 手工测试 API 漏洞实战

以下是在手工测试 API 时，需要重点关注的几个维度及其常见的攻击手法：

Method：请求方法
 攻击方式：PUT, DELETE, MOVE 等非常用方法
 效果：上传恶意文件、删除资源等
URL：唯一资源定位符
 攻击方式：路径遍历、猜测隐藏端点、开放重定向
 效果：未授权访问、信息泄露
Params：请求参数
 攻击方式：参数污染、越权ID遍历、重放攻击
 效果：水平/垂直越权、业务逻辑绕过
Authorization：认证方式
 攻击方式：Token伪造、JWT篡改、签名绕过
 效果：身份冒用、未授权访问
Headers：请求消息头
 攻击方式：修改 Host, Referer, Content-Type, X-Forwarded-For 等
 效果：绕过身份认证、IP限制、WAF规则
Body：消息体
 攻击方式：SQL注入、XML外部实体注入、JSON注入、反序列化
 效果：数据泄露、远程代码执行、权限提升

搭建 vAPI 靶场环境

为了演示手工测试方法，我们使用 vAPI（Vulnerable Adversely Programmed Interface）靶场，它模拟了 OWASP API Top 10 中的多种漏洞场景。

靶场安装：

# 前提：已安装 Docker 和 Docker Compose
git clone https://github.com/roottusk/vapi.git
cd vapi/

默认配置下，vAPI 会绑定主机的 80（HTTP）、3306（MySQL）、8001（PHPMyAdmin）端口。我们可以通过修改 docker-compose.yml 文件来调整端口映射。

修改后启动靶场：

docker-compose up -d

访问主机 IP，看到如下页面代表安装成功。

配置 Postman：
vAPI 提供了专门的 Postman Collection 文件以便测试。
导入 URL：https://raw.githubusercontent.com/roottusk/vapi/master/postman/vAPI.postman_collection.json

导入后，需要将 Collection 变量 {{host}} 的值修改为你的靶机 IP 地址。

发送一个测试请求（如 Create User），收到正常响应即表示环境配置完成。

漏洞场景一：水平越权（IDOR）

打开 API1 的 Collection，这里模拟了水平越权场景。

1. Create User：创建一个新用户，传入用户名、姓名、课程、密码。
   
2. Get User：获取指定用户信息。需要在 Headers 中设置 Authorization-Token，其值为 base64_encode(用户名:密码)。使用上一步创建的用户ID（例如6），可以查看到该用户信息。
   

漏洞利用：
关键在于，只要拥有任意一个有效的 Authorization-Token，即可通过修改 userid 参数来获取其他用户的数据。尝试将ID改为1，成功返回了管理员或其他用户的敏感信息（包含flag），这便是一个典型的水平越权漏洞。

漏洞场景二：验证码枚举（OTP Brute Force）

API4 模拟了因缺少速率限制而导致的暴力破解漏洞。

1. Mobile Login：输入手机号，后端声称会发送一个4位数的 OTP（一次性密码）到该手机。
   
2. Verify OTP：验证收到的4位数字OTP。
   

漏洞利用：
由于接口没有对错误尝试次数和频率进行限制，我们可以暴力枚举4位数的OTP（0000-9999）。将 Verify OTP 的请求发送到 Burp Intruder。

设置 Payload 类型为 Numbers，范围从 0000 到 9999，格式为4位整数。

开始攻击，通过对比响应长度或状态码，可以发现成功的 OTP（返回200状态码及不同的响应内容）。

使用爆破得到的正确 OTP 进行验证，获得一个 key，将其用于后续的 Get Details 请求，即可获取 flag。

漏洞场景三：垂直越权（功能权限缺陷）

API5 模拟了因接口权限分离不严导致的垂直越权。开发者可能为普通用户和管理员分离了不同的数据查询接口（如 /user/{id} 和 /users），但忽略了后者也需要进行管理员权限校验。

1. 创建一个普通用户。
   
2. 使用该普通用户的凭证，可以正常访问自己的信息（/user/2）。
   

漏洞利用：
直接使用同一个普通用户的凭证，去请求本应只有管理员才能访问的 “Get All Users” 接口（/users），成功返回了所有用户数据，包括管理员的敏感信息（flag）。

漏洞场景四：SQL 注入

API8 只提供了登录和获取秘密信息两个接口。

漏洞利用：
在登录接口的 username 参数尝试经典的 SQL 注入 payload，例如 admin' or 1=1#，成功绕过登录验证，获取到了有效的 authkey。

使用这个 authkey 作为 Authorization-Token 去访问 /user/secret 接口，成功获取到 flag。

漏洞场景五：多版本 API 暴露（防绕过）

API9 是一个需要用户名和4位数字PIN码的登录接口。

初步测试：
直接对 v2 接口的 pin 码进行爆破，发现存在防爆破机制，连续错误多次后返回 500 错误。

漏洞利用：
尝试访问旧版本 v1 的接口（将 URL 中的 /v2/ 改为 /v1/）。对 v1 接口进行爆破，发现其没有防爆破机制，成功爆破出 PIN 码为 1655。

使用正确的凭证登录 v1 接口后，成功获取到包含 flag 的账户信息。

这个案例提醒我们，在安全测试中，不要忽略旧版本 API 的存在，它们可能缺少在新版本中已修复的安全控制措施。

0x05 总结与参考

API 安全测试是一个系统性的过程，需要结合自动化工具的效率与手工测试的深度。从信息收集（识别 API 类型）开始，到利用工具进行初步扫描，再到针对业务逻辑、认证授权、输入验证等层面的手工深入测试，每一步都至关重要。

希望这篇结合实战的指南能为你提供清晰的 API 安全测试思路。在实践中不断积累经验，是提升安全测试能力的关键。欢迎在 云栈社区 与其他安全爱好者一起交流探讨更多技术细节。