一次真实的口渗教训。去年测试某金融App，口渗登录接口返回的口渗token里直接带着用户手机号。更离谱的口渗是，修改手机号接口只校验token，口渗不校验旧手机号——意味着只要拿到任意用户的口渗token，就能把他的口渗号换成你的。这不算高深漏洞，口渗但暴露了api设计里最原始的口渗信任问题：开发默认“能调接口的人都是自己人”。

api渗透和传统web渗透完全是口渗两码事。传统打的口渗是页面，你看到输入框、口渗URL参数、口渗cookie。口渗api呢？口渗你面对的是纯数据流，没有页面给你点，没有表单给你填。攻击面全在请求结构里——路径、方法、请求头、body体。很多测试者拿着扫描器扫半天，扫出一堆低危漏洞，却忽略了api最致命的逻辑缺陷。比如越权，这是api渗透里出现频率最高的洞。水平越权：A用户能查B用户的订单。垂直越权：普通用户能调管理员接口。我见过最蠢的案例，某个后台管理接口，路径是/admin/getUserList，开发觉得没人知道就万事大吉。结果前端打包的js里，这个路径写得明明白白。

别小看HTTP方法。GET改成PUT，往往能绕过权限校验。某电商平台，商品上架接口是POST，但改成PUT后直接跳过审核流程——因为网关只对POST方法做了鉴权。还有Content-Type的坑，把application/json改成text/xml，某些解析器会直接忽略签名校验。这些细节，不抓包根本发现不了。

api的认证机制更是重灾区。JWT令牌经常是HS256算法，密钥硬编码在代码里。你拿个弱口令字典去跑，跑出来直接伪造token。OAuth2.0的redirect_uri不校验，能窃取授权码。更常见的是session固定攻击——登录前发你个sessionId，登录后sessionId不变，攻击者提前把sessionId塞给受害者，等受害者登录成功，攻击者直接拿着这个id冒充。

参数污染也值得留意。api网关和业务服务器对参数解析不一致，导致校验绕过。典型案例如：网关取第一个id参数做权限校验，业务服务器取最后一个id参数执行查询。你提交?id=100&id=1，网关校验100有权限，实际查的是1的数据。这种双解析漏洞，在Java和Python混合架构的系统里特别常见。

别忽略api的调试信息。很多开发环境没关swagger文档，直接暴露所有接口定义。更蠢的是，某些生产环境还开着actuator端点，/env、/heapdump直接泄露数据库密码。我测试过一个物流系统，heapdump文件下载下来，用jhat分析，直接找到阿里云accessKey。

真正有效的api渗透，得从业务逻辑入手。先理清整个系统的数据流：谁调用谁，传什么参数，返回什么结果。然后针对每个接口问三个问题：这个接口能访问哪些数据？这些数据属于谁？我能通过修改参数访问不属于我的数据吗？

最后说个反直觉的点——api渗透里，最危险的不是复杂漏洞，而是那些看起来“正常”的请求。比如分页参数page=1改成page=2，如果返回了别人的数据，恭喜你，水平越权。这种漏洞，自动化工具永远扫不出来，只有人肉一条条测。所以，别迷信扫描器，沉下心，一个个接口慢慢试。