简介
垂直越权是一种非常常见且非常严重的权限漏洞，具体表现就是，低权限的用户可以不受控制的访问高权限用户的资源。
方案一
基于资源限定的角色来进行垂直越权控制（如:shiro）
在controller类上增加注解@RequiresPermissions()，表示哪些角色可以访问当前这个资源
示例: 拥有admin,leader角色权限的可以访问这个接口
@RestController
@RequiresPermissions("admin,leader")
public class AuthTest {
@GetMapping(value = "/user")
public String getUser(){
return "zhang";
}
在controller类方法上增加注解@RequiresPermissions()
示例: 拥有admin,leader角色权限的可以访问这个接口
@RestController
public class AuthTest {
@RequiresPermissions("admin,leader")
@GetMapping(value = "/user")
public String getUser(){
return "zhang";
}
总结：这种方案优点是，实现起来非常简单，便于后续的维护，我们只需对新增的URL添加对应的允许访问的角色即可。但是缺点也非常的明显。
- 对于角色很多的系统，我们不得不在注解上加上很多允许的角色，会显得很冗长
- 对于角色不固定的系统，无法控制
- 如果后续新增了一个角色，那么就需要更改所有的允许访问的URL，挨个增加角色信息，费时费力，还容易遗漏
- 系统运行期间无法做到灵活调配不同角色允许访问的URL，必须修改代码重新部署。
方案二
基于资源和角色的配置关系进行垂直越权控制
@RestController
public class AuthTest {
@GetMapping(value = "/user")
public String getUser(){
return "zhang";
}
增加拦截器
@Configuration
public class AuthConfig implements WebMvcConfigurer {
@Autowired
private ResourceUrlAuthInterceptor resourceCodeBasedAuthInterceptor;
@Override
public void addInterceptors(InterceptorRegistry registry) {
registry.addInterceptor(resourceCodeBasedAuthInterceptor);
}
}
拦截器越权控制
@Component
public class ResourceUrlAuthInterceptor implements HandlerInterceptor {
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler){
String requestUrl = request.getRequestURI();
String requestMethod = request.getMethod();
checkRolePermission(requestUrl,requestMethod);
return true;
}
/**
* 校验权限
* @param requestUrl
* @param requestMethod
*/
private void checkRolePermission(String requestUrl,String requestMethod) {
//获取当前用户的resource
ShiroUser user = ShiroSession.getSessionUser();
List<ShiroResourceUrl> resourceUrlList = user.getResourceUrlList();
if (CollectionUtils.isEmpty(resourceUrlList)) throw new UnauthorizedException();
//匹配已有权限
for (String patten:resourceUrlList.stream().map(ShiroResourceUrl::getRequestUrl).collect(Collectors.toList())) if (UrlPattenUtils.checkUrl(patten, requestUrl)) return;
throw new UnauthorizedException();
}
//校验url
public static boolean checkUrl(String patten, String path) {
PatternMatcher matcher = new AntPathMatcher();
return matcher.matches(patten, path);
}
}
总结：这种方式只需要增加一个拦截器，拦截器中只要访问的地址包含在用户所允许的resourceUrl中，那么当前用户就可以访问。
表设计:
- user ，存储用户信息
- uid
- user_name
- role , 用户角色
- uid
- role_name
- role_user 用户角色关系，一个用户多个角色
- uid
- user_uid
- role_uid
- resource 资源信息
- uid
- reource_url
- role_resource 角色资源关系，一个角色多个资源
- uid
- role_uid
- resource_uid
- resource_url 资源访问url，可以多个
- uid
- resource_uid
- request_url
我们获取到用户的角色和角色对应的资源和资源对应的访问url就可以去做判断了
所以我们只需要维护在数据库中resource_uid和request_url就可以了
这种方案的优势:
- 不需要在代码中标注，完全不需要改动代码
- 只关心资源所对应的url权限即可
- 服务运行期间也可以维护
