api渗透测试项目

去年秋天，渗试项我接了一个电商平台的透测API渗透测试。客户把Swagger文档甩过来，渗试项三百多个接口，透测认证方式写着OAuth 2.0。渗试项扫了一遍，透测发现一个查订单详情的渗试项接口，URL里带order_id参数。透测改成别的渗试项用户ID，返回403。透测看起来没问题。渗试项

但我不死心。透测把请求方法从GET换成POST，渗试项参数挪到body里，透测居然返回了完整订单数据。渗试项同一个接口，换了个姿势就绕过了权限校验。这种低级错误在真实项目里出现的频率，比很多人想象的高得多。

接口文档本身就是攻击面

很多人做API测试，拿到文档就开始跑扫描器。我习惯先花半小时把文档完整读一遍。不是看接口功能，是看参数命名规律、版本号、废弃接口标记。

那个电商项目里，文档中有个/api/v1/user/export被标记为deprecated，但实际还能调通。参数是user_ids，逗号分隔。我传了1,2,3，返回三个用户的手机号和收货地址。没有权限校验，没有频率限制。废弃接口往往是安全维护的死角，开发觉得没人用了，运维忘了下线，测试也忽略了。

文档里的example值也值得看。有次看到某个接口的示例token是Bearer test123，试了一下，居然在测试环境有效。生产环境虽然换了密钥，但测试环境的数据库和生产的结构完全一致，拿到测试环境的注入点，等于拿到了生产环境的攻击地图。

参数污染和类型混淆

REST API通常用JSON传参。但很多框架对参数类型的处理很宽松。一个user_id字段，文档写的是integer，你传字符串"1' OR '1'='1"，有的ORM直接拼接SQL，有的框架会做类型转换后继续执行。

更隐蔽的是参数重复。比如{ "role":"user","role":"admin"}，不同语言解析JSON时行为不一样。Python的json.loads取最后一个，Java的Jackson默认也取最后一个，但有些框架取第一个。如果权限校验取第一个值，业务逻辑取最后一个值，就产生了越权。

我遇到过最离谱的是一个金融接口，amount参数传负数，居然能通过校验。转账-100元，等于从对方账户扣钱。这种逻辑漏洞扫描器根本扫不出来，得靠手工构造异常值。

认证绕过不止是改token

JWT是重灾区。很多人只测alg:none，但实际场景更复杂。有个项目用JWT做认证，密钥是硬编码的secret。我用hashcat跑了三秒就出来了。拿到密钥后，可以伪造任意用户的token，包括管理员。

还有种情况是token校验不严。接口只检查token是否存在，不检查是否过期。我拿一个三个月前抓的包，token早过期了，但接口依然返回200。开发说“我们前端会处理过期”，但攻击者不走前端。

OAuth流程里的redirect_uri也是突破口。如果校验不严，可以改成自己的服务器，窃取授权码。有个社交平台的API，redirect_uri只校验了域名前缀，我注册https://api.example.com.evil.com就绕过了。

速率限制形同虚设

大部分API的速率限制只针对IP。我用代理池轮换IP，一分钟发了五千次验证码请求。短信费用客户自己承担。更搞笑的是，有的接口限制是基于X-Forwarded-For头，而这个头是客户端可控的。每次请求改一下，限制就没了。

还有一种情况是限制只加在网关层，内部服务之间调用不限制。如果你能拿到内网的一个SSRF漏洞，通过内部服务调API，速率限制完全失效。

测试完别忘了清理

有次测试一个CMS的API，我在文章里插了XSS payload。测试完忘了删，客户运营第二天发文章，payload触发了，后台管理员cookie被发到我的服务器。虽然是测试环境，但客户还是发了邮件问怎么回事。后来我养成了习惯，每个注入点都记下来，测试结束逐条清理。

API渗透测试和Web渗透最大的区别是：Web页面有UI，你能看到返回了什么。API返回的是JSON，有时候一个200 OK背后，数据已经泄露了。得盯着响应体看，别只看状态码。

本文地址：http://www.79wt.cn/news/1071c9299800.html