API治理杂谈 | 总第213周

A1：这个如果只压给安全来做一定做不好，安全甚至应该是需求方而不是执行方，不过可以提供一些卡点。听说快手基本做完了。

A2：效果咋样？感觉互联网做0-1还行，但严谨度差很多。从国家红蓝对抗成绩看，除了极少数互联网大厂，基本都是很快就出局了。

A3：我们当时做的还是可以的，效果很明显。红蓝对抗跟API安全概念断层还是比较严重，不能一概而论。

Q：自研还是厂商产品呢？用什么样的技术路线？

A4：全自研的，API存量+增量，应用风险+数据风险，而且API做好的话，其实类似于资产，对很多上层的工作是有帮助的。

Q：是流量镜像做分析吗？跟soc这边没有关联吧？

A5：是做了镜像分析的。SOC算是统一运营管理平台，数据分析也会在里面，作为一部分。

A6：我poc了几家厂商的方案，还没买。用流量镜像旁路先做。

A7：1、先收日志；

2、先处理cookie为空的接口，参数和响应通过关键字去识别；

3、处理带敏感数据有cookie的接口。

如果内部有团队对系统做分级分类的话，还可以参考系统级别。根据我们这边的经验，通常来说一个权限有问题的api往往是整个应用都存在问题。

Q：感觉基于鉴权角度的API分析？

A8：对，主要是处理未授权和权限问题。涉及敏感数据的api通过模型监控，对象存储里的文档也做敏感数据监控。

Q：通过接口慢慢爬数据那种有监控吗？

A9：慢速这种也有。

Q：有些接口带了cookie或token但是后端并没有验证cookie或token，这种是通过去token重放识别未授权吗？

A10：对，可以重放，还要注意token应当是有时效，还要拿历史token重放，token交叉重放，验证是否可以水平越权。

Q：怎么定义敏感数据，带关键字吗？

A11：内部有其它团队专门梳理了互联网系统使用到的数据级别。我们已经有数据字段分类分级，系统权限分级。

Q：api资产这块有个小疑问，是会过滤掉静态资产，还是只关注比如json类。可以理解为带特定内容或者格式的匹配吧？

A12：专注内容，比如个人信息，商户信息这种。

A13：API安全我认为应该是两个维度，一个是定标准规范，放入SDL流程中卡点，另外一个维度就是日常风险监测和应急响应类的。

关于提到API的资产来源通过流量镜像，这个是纯乙方思维（他们比较难接触到甲方内部应用系统开发等流程），我这边还会通过WAF中的API请求列表和系统开发流程中的自动化测试平台中去获取补充。

Q：请问你们用生产流量拿到的接口数据去重放有没考虑可能导致业务逻辑错误，比如重复下单重复扣款等。

A14：支付类的接口，都是密文，我们不管的。如果这类接口不能幂等，也可以算是有风险的。

A15：我们会解密再篡改再加密，因为是自家公司的安全测试，所以可以假设默认黑客脱壳了加固，然后让开发团队提供未加固的app包，审计代码写frida脚本自动解密和加密。这样测下来逻辑漏洞比如越权漏洞还挺多的。

当然这类有污染风险的测试，要在测试环境做。若遇到测试环境共用的情况，建议做好沟通，比如让他们提前备份镜像再测。

A16：测试环境最好方法就是拿swagger列表收集API了，若在API资产收集那层直接就做重放，感觉风险有点大，比如token或cookie一旦出了问题是对用户造成影响。

A17：重放都有问题可以好好地挑战开发团队了。举个例子，就好像用户电脑或者手机网络不好，浏览器的机制也会在特定的时候不断重试，与其用户发现风险，不如自家人发现风险。

平时就在测试环境做好重放测试，生产环境如果真的必须，那就拿自己的账号做测试，安全部门嘛，总要承担一点麻烦。做个匹配，收集到的数据包匹配一下是否自己账号的。不稳的工作就小范围做，匹配自己的拿小部分账号弄。匹配不了的就写个脚本，所有经过自己设备的流量都添加一个特殊的http header，自己给自己造一个匹配量。

A18：我们的出发点有点不同，我开始想的也不是从安全测试角度，从流量层收集API接口，是可以同时直接req去做未授权，但风险也是有的。还有从流量层收集API资产，归并也有点麻烦，像GET的接口，现在最后个id都表示资源，不知道那些产品能不能归并到最上一层。