水平越权的常见解决方法

场景模拟

  • 场景一

    只允许资源的所有者才能对资源进行操作(CRUD)。比如,jack在某博客平台写了一篇私密文章,只有自己可以对这篇文章进行增删查改的操作;

  • 场景二

    允许指定个人或者角色也能对资源进行操作。比如,jack邀请他的好朋友mason对文章进行查看和修改;

方案一

最简单和最直接的就是,在web层接收到操作请求后,在执行这个操作前,对请求的合法性进行校验。比如,查询当前需要操作的资源是否归属当前session中的已登录用户;或者查询当前需要操作的资源是否是允许操作的其它用户。

String loginUser = session.get("username");
// 增加水平越权校验
if(!checkAuthority(loginUser,articleId)){
  return false;
}
// 执行正常的操作
// 当前登录者是否是资源的所有者
private Boolean checkAuthority(String loginUser, String articleId){
  String articleOwner = articleService.getOwner(articleId);
  return Objects.equals(loginUser, articleOwner);
}
// 当前登录者是否有操作权限
private Boolean checkAuthority(String loginUser, String articleId){
  int count = articleService.getLegalUser(loginUser, articleId);
  return count > 0 ? Boolean.TRUE : Boolean.FALSE;
}

这种方案的优点是实现简单,逻辑清晰;但是缺点也很明显,需要对每一个请求都加上这种操作,很是繁琐,而且多了一次数据库查询,效率肯定有所下降;

方案二

我们可以直接将登录者的信息传递到SQL层面进行校验,比如场景一我们可以在原SQL最后加上一句来限制资源的操作。

select * from artile where article_id = #{articleId}
and author = #{loginUser}

如果是场景二的话,我们需要多关联一张表。

select * from artile a join author_guest g on a.author = g.author where article_id = #{articleId}
and g.guest = #{loginUser}

其中author_guest存放的是作者邀请的朋友之间的关系映射表。

这种方案的优点是没有增加额外的Java代码,没有增加额外的数据库查询,比较简洁优雅;但是缺点是需要改动SQL,增加了SQL的复杂性,而且有时一个SQL是供多块逻辑共用的,A模块需要鉴权,B模块不需要鉴权,那就要重新写一份相同的SQL或者在SQL上加分支了,那SQL会变得更难以理解和维护。

除此之外,好像还没法区分没有数据没有权限两种操作异常情况,只能给前端反馈操作异常的提示,不是很友好。

参考文章

  • 水平权限漏洞的修复方案

你可能感兴趣的:(水平越权的常见解决方法)