安全建设-攻防思路及实践（一）

原文链接：https://mp.weixin.qq.com/s/mnHGLZ_e3tWkxCL-DPAAvQ

背景

以前挖国内src时的一个套路：

通过"寻找管理后台 + 寻找api接口 + burp验证api接口"来找未授权api

找到未授权api后，根据api功能就能造成不同危害：

比如利用"重置密码接口"来重置管理员密码，然后登陆后台

比如利用"查数据接口"获取数据

个人觉得这个套路比较好用，原因在于：

没有攻击payload，waf、nids等安全设备比较难检测（虽然可能按照访问404频率和比例等特征封禁）

"管理后台对外开放"和"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还原前端项目-浏览器插件这种工具还原前端项目，代码阅读性更好一些。接着对前端项目做代码审计，有可能在前端代码中看到 啥token、啥功能比较特殊的api接口（比如上传文件）。

怎么使用burpsuite验证api接口？

将找到的api接口放到burpsuite批量验证，根据 响应状态码、响应长度、响应内容 来判断是否有未授权的api接口。

测试过程中可以变换请求方法：GET、POST、PUT

确认存在未授权接口后，再人工从前端js中找参数值利用。

成果

[评级高危-顺丰某系统后台API接口未做认证导致用户信息泄漏]

[评级高危-顺丰某系统未授权导致获取后台管理权限，可查看大量订单信息]

[评级高危-字节某业务线后端接口未授权访问]

[评级中危-腾讯广告后台接口未认证]

[评级低危-后台API接口存在未授权访问(可增删改数据)]

安全管理与技术

对于"管理后台对外开放"和"api接口未授权访问"这两类风险，在企业安全建设中是怎么防范的呢？

怎么减少"管理后台对外"安全风险？

根据个人有限的经验来总结，管理上包括如下手段：

* 公司发布安全红线：禁止后台开放到公网访问
* 安全意识的宣导

技术上包括如下手段：

* 统一认证登陆
* 周期性对资产做扫描，识别"管理后台"
* 从流量层面识别"管理后台"

业务上包括如下手段：

* 后台访问白名单限制
* 后台登陆多因素认证MFA（短信二次认证、rsa token等）

比如能看到的，滴滴很多后台管理业务都接入了统一认证登陆，对于我来说就比较难进一步测试。

不过上面的手段都并不一定管用，各种手段自身也有设计缺陷、安全漏洞等。

比如我前公司的统一认证平台 统一认证登陆出现过一个设计上的漏洞。

正常的业务场景是：它支持钉钉登陆，员工在web页面输入邮箱后，钉钉app会收到一个确认登陆链接。员工点击确认链接后，web端就会验证通过，进入到后台系统。

有白帽子收集一些部分员工邮箱，就在web页面填收集到的邮箱。结果有部分员工点击了钉钉上收到的"确认登陆链接"消息，帮助"攻击者"进到了后台系统。

另外还听我同事给我分享的案例，他遇到某些有多因子认证的系统时，加x-forwarded-for请求头伪造内网ip就绕过去了，原因是面向内部的系统去掉了"多因子认证"。

至于安全意识的宣导、安全红线到底有多大作用，这感觉更不好衡量。

怎么减少"api接口未授权访问"安全风险？

根据个人有限的经验来总结，技术上包括以下手段：

* 依赖开发人员的代码安全质量
* 零信任架构的实施

零信任应用的两个场景包括了 用户访问服务 和 服务之间互相访问 时的认证鉴权，而"用户登陆后台访问数据"恰好就是"用户访问服务"这个场景。

总结

验证了这个老套路在国内还是能挖到洞的。

站在攻击方的角度来看，现有每一步的安全策略可以优化，比如可以详细调研一下后台系统的分类，比如为什么开源的cms后台和前台经常是在一个域名下，而企业里的后台系统为什么经常是单独的访问方式？

整个流程或许也可以优化到完全依赖工具产出报警，就像 一种针对Webpack等前端打包工具构建的网站的自动化测试思路（附开源项目）一样。虽然没有用过这个项目，但是看文章介绍感觉有不少实战上的细节和经验。