 |
025-85513261 13611587156（微信） |
以前挖国内src时的一个套路：通过"寻找管理后台 + 寻找api接口 + burp验证api接口"来找未授权api
找到未授权api后，根据api功能就能造成不同危害：
个人觉得这个套路比较好用，原因在于：
也有不好的地方，在于：
怎么找"管理后台"？
大概分三步：
* 第一步筛出可能的管理后台地址
* 第二步将首页截图保存成本地
* 第三步人工浏览截图
第一步筛选管理后台地址的策略包括：
* 域名中包含关键词，直接当作后台管理系统
* 30x跳转地址包含关键词
* 响应html中包含table标签（因为有可能后台管理首页就存在未授权访问，数据展示时会用到table标签）
* 判断页面是否是vue框架写的（因为很多开发喜欢选择用vue来做管理系统）
脚本代码：https://gist.github.com/leveryd/334b719e253261ffd0abfd161e499ae7
怎么找api接口？
从js文件文本中找，策略如下：
* 将js代码中字符串常量提取出来
* 字符串常量匹配 `/[\w\d\-./]+` 且不以 // 字符开头，认为是api路径
* 字符串常量匹配 `[\w\d\-]+/[\w\d\-./]+` 且不以 / 字符开头，认为是api路径
脚本代码：https://gist.github.com/leveryd/465d19610d5fcf99199beb9284cd6f8c
这种方式不需要前端存在sourcemap泄漏。
当然如果前端有sourcemap信息就更好，这样可以利用 利用sourcemap还原前端项目-浏览器插件[1] 这种工具还原前端项目，代码阅读性更好一些。接着对前端项目做代码审计，有可能在前端代码中看到 啥token、啥功能比较特殊的api接口（比如上传文件）。
怎么使用burpsuite验证api接口？
将找到的api接口放到burpsuite批量验证，根据 响应状态码、响应长度、响应内容 来判断是否有未授权的api接口。
测试过程中可以变换请求方法：GET、POST、PUT
确认存在未授权接口后，再人工从前端js中找参数值利用。
对于"管理后台对外开放"和"api接口未授权访问"这两类风险，在企业安全建设中是怎么防范的呢？
怎么减少"管理后台对外"安全风险？
根据个人有限的经验来总结，管理上包括如下手段：
* 公司发布安全红线：禁止后台开放到公网访问
* 安全意识的宣导
技术上包括如下手段：
* 统一认证登陆
* 周期性对资产做扫描，识别"管理后台"
* 从流量层面识别"管理后台"
业务上包括如下手段：
* 后台访问白名单限制
* 后台登陆多因素认证MFA（短信二次认证、rsa token等）
比如能看到的，滴滴很多后台管理业务都接入了统一认证登陆，对于我来说就比较难进一步测试。
不过上面的手段都并不一定管用，各种手段自身也有设计缺陷、安全漏洞等。
比如我前公司的统一认证平台 统一认证登陆[2] 出现过一个设计上的漏洞。
正常的业务场景是：它支持钉钉登陆，员工在web页面输入邮箱后，钉钉app会收到一个确认登陆链接。员工点击确认链接后，web端就会验证通过，进入到后台系统。
有白帽子收集一些部分员工邮箱，就在web页面填收集到的邮箱。结果有部分员工点击了钉钉上收到的"确认登陆链接"消息，帮助"攻击者"进到了后台系统。
另外还听我同事给我分享的案例，他遇到某些有多因子认证的系统时，加x-forwarded-for请求头伪造内网ip就绕过去了，原因是面向内部的系统去掉了"多因子认证"。
至于安全意识的宣导、安全红线到底有多大作用，这感觉更不好衡量。
怎么减少"api接口未授权访问"安全风险？
根据个人有限的经验来总结，技术上包括以下手段：
* 依赖开发人员的代码安全质量
* 零信任架构的实施
零信任应用的两个场景包括了 用户访问服务 和 服务之间互相访问 时的认证鉴权，而"用户登陆后台访问数据"恰好就是"用户访问服务"这个场景。
验证了这个老套路在国内还是能挖到洞的。
站在攻击方的角度来看，现有每一步的安全策略可以优化，比如可以详细调研一下后台系统的分类，比如为什么开源的cms后台和前台经常是在一个域名下，而企业里的后台系统为什么经常是单独的访问方式？
整个流程或许也可以优化到完全依赖工具产出报警，就像 一种针对Webpack等前端打包工具构建的网站的自动化测试思路（附开源项目）[3] 一样。虽然没有用过这个项目，但是看文章介绍感觉有不少实战上的细节和经验，推荐阅读