LinkWeChat 是基于企业微信的开源 SCRM 系统,文中漏洞均已修复,下载最新版即可
https://gitee.com/LinkWeChat/link-wechat
前置条件:
程序提供了接口 @GetMapping("/wxLogin"),可以通过微信登录,登录后可以操作后台功能,即使你不是内部员工,只要你关注了公众号就可以登录并操作后台功能,造成越权。
com.linkwechat.web.controller.system.SysLoginController#wxLogin
该程序多个模块,其中 linkwe-gateway 作为网关会被映射到公网,所有的请求都会经过这个网关,再由网关进行转发请求。
身份校验会通过 AuthFilter,使用了 JWT Token + uuid + redis 进行身份验证。
com.linkwechat.gateway.filter.AuthFilter#filter
其中linkwe-gateway.yml 中设置了 */auth/*\\ 不做身份验证
提供了接口,可以进行微信登录
com.linkwechat.web.controller.system.SysLoginController#wxLogin
最后会创建 Token
com.linkwechat.web.service.SysLoginService#wxLogin
调用 refreshToken 刷新 Token
com.linkwechat.framework.service.TokenService#createToken(com.linkwechat.common.core.domain.model.WxLoginUser)
在这里就会存储 redis 缓存,通过 isLogin 的判断
需要设置好公众号配置,如果没有公众号的,可以 申请微信公众平台接口测试账号
程序提供了接口 wxRedirect 可以获取到微信授权的连接
/auth/wxRedirect?redirectUrl=https://....
注意这里的 redirectUrl 参数,需要在后台设置好域名,这里我设置的跳转到官网,因为我自己没有域名
请求接口获取地址
打开连接之后就授权就会跳转到 redirectUrl 指定的连接中,并携带参数 code
跳转后复制链接,就可以看到连接上的参数 code
http://demo.linkwechat.net/?code=001ZNf000QO5aP1I7S200cdEYB1ZNf03&state=linkwechat#/authRedirect
拿到 code 之后就可以调用 wxLogin 进行登录了
往后的请求带上请求头 Authorization 设置未 Token 就可以了
提交漏洞后,项目的负责人很快作出反应,对这个问题进行了修复,我大致看了一下 提交记录,在修复微信token可以访问基础服务 的代码变更中
多看一眼就爆炸了,发现不对劲,增加了判断 Token 中的 loginType 字段,来区分拦截 公众号粉丝登录授权 。
在 gateway 的 AuthFilter 中,是从 Token 载体中的 login_type 字段获取的。
com/linkwechat/gateway/filter/AuthFilter.java
而 JWT Token 的密钥是固定的,这就导致了,可以控制 login_type 字段
修改成 LinkWeChatAPI
使用修改后的 Token 访问,成功绕过
而我给出的修复方案也很简单:使用随机的 密钥 ,确保每次启动都不一样。
程序使用了 mybatis,并在 SysDeptMapper 配置了 ${} 参数导致 SQL 注入漏洞,该漏洞为 update 型注入
在 SysDeptMapper 中配置了 ${ancestors} 参数
/linkwe-auth/..../src/main/resources/mapper/system/SysDeptMapper.xml
该参数的类型为 String
该接口在 SysDeptController#edit 中使用
com.linkwechat.web.controller.system.SysDeptController#edit
这里会根据传入的 newParentDept 获取信的父级部门,然后拼接旧的部门,这样会覆盖掉请求中的 ancestors 参数,所以我们的请求中父级已经要让他获取的值为空,不让他覆盖掉 ancestors
然后我们需要让他进入判断调用 updateParentDeptStatus 才能触发 SQL ,这里的 DEPT_NORMAL = 0
{
"deptId": 1,
"parentId": 999,
"ancestors": "if(1, sleep(1), 0)",
"deptName": "24rewr",
"deptEnName": "3",
"orderNum": "4",
"phone": "5",
"email": "1@q.com",
"status": "0",
"parentName": "parentName"
}
结果为 False 时,就没有阻塞。
在 修改部门 的逻辑中增加了操作操作权限的校验
此时就算还存在越权的问题,也无法访问 修改部门 的接口了
但其他的接口似乎没有加上权限校验
针对于 Mapper.xml 也修复了问题
12 篇文章
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!