公司项目重构-Web安全-访问控制

如时间有限，可直接阅读防范手段一节。

一、背景介绍

今年开始公司准备对项目做部分重构，其中安全性问题首当其冲，除了已知的问题外，还需要发散思维，尽可能找出更多的潜在问题。期间发现一本非常好的书《白帽子讲Web安全》，感谢吴翰清大佬，读完本书让我对web安全有了更深刻的理解，强烈推荐大家阅读。

我打算记录下整个安全性重构的过程，相关知识点大部分会摘抄自《白帽子讲Web安全》，因为总结的很到位了，最后记录下公司内采用的防范手段（敏感信息不会书写）。

二、基础概念

权限控制（或者说访问控制）抽象地说：就是某个主体（subject）对某个客体（object）需要实施某种操作（operation），而系统对这种操作的限制就是权限控制

在Web应用中，根据访问客体的不同，常见的访问控制可以分为：

• 基于URL的访问控制
• 基于方法的访问控制
• 基于数据的访问控制

根据控制方式的不同，又可以分为：

• 垂直权限管理
• 水平权限管理

基于URL和基于方法的访问控制都是很好实现的，主流框架Spring Security和Shiro都提供了解决方案，这两种访问控制方式我们称为”垂直权限管理“，不同角色的权限有高低之分，高权限角色可以访问低权限的资源，反之则不行。

基于数据的访问控制，我们称为”水平权限管理“，针对同一角色的用户，也需要控制他们只能访问属于自己的私有数据，需要将数据与用户绑定。避免在数据上的访问越权。

三、安全风险

未做访问控制的漏洞
在正常情况下，管理员后台的页面应该只有管理员才能访问，但有些系统并未对用户的访问进行控制，导致任意用户只要能构造出正确的URL，就可以访问这些页面。有些系统采用的做法是在页面上隐藏入口，但是把需要保护的页面”隐藏“起来，并不是安全的解决方案。

攻击者会使用一部包含许多后台路径的字典进行扫描，比如大部分后台管理的路径都包含admin。除了攻击者，内部员工也可能会造成风险，因为他们知道哪些URL是没做权限控制的。

用户对数据越权访问的隐患
id通常是记录的唯一标识，那么在URL上修改参数ID的值是否能访问其他记录呢，通过递增或递减id是否可以遍历出库里的所有信息呢？

假如个人信息页面的路径为：user/info?id=234524，如果后台程序是接收id参数到库里检索的，并且没有判断该记录是否属于本人，那么是可以看到其他用户信息的。

四、防范手段

1、使用安全框架（重要）

访问控制实际上是建立用户与权限之间的对应关系，现在广泛使用的是”基于角色的访问控制（Role-Based Access Control）“，简称RBAC。

RBAC大概流程：系统中会定义不同权限（资源的标识，常用是访问URL），角色绑定不同的权限集合，所有用户都会被分配不同的角色（可多个）。在验证权限时，只需要验证用户所属的角色或其角色所具备的权限。

Spring Security和Shiro安全框架都是不错的选择，后面我会增加Shiro相关的文章。

2、后台对数据范围做判断（重要）

目前的安全框架，只能做到不同角色之间的权限控制，而水平权限管理的问题没有好的解决方案，因为相对于垂直权限管理来说，水平权限问题出在同一角色上，系统只验证了能访问数据的角色，既没有对角色内的用户做细分，也没有对数据的子集做细分，因此缺乏一个用户到数据之间的对应关系。

比如用户A和用户B都属于同一角色，但是用户A和用户B各自拥有一些私有的数据（比如个人信息），在正常情况下，他们应该只能访问自己的私有数据。但是在RBAC这种”基于角色的访问控制“模型下，系统只会验证他们是否具备指定角色，而不会判断数据属于谁，因此就会发生越权访问。

但是很遗憾，对于数据的访问控制，通常与业务结合很紧密，有些可能需要控制有些可能不需要，所以很难统一做控制。

书中提到了建议方案：一个简单的数据访问权限，可以使用”用户组（Group）“的概念，比如一个用户组的数据只属于该组内的成员，只有同一用户组的成员才能对这些数据操作。

当然了，还需要开发人员做好基本的安全校验，比如查询自身数据时，尽量从session中获取用户id，而不是页面传入；并且查询或操作数据前，先判断是否为本人创建的数据（看业务要求）。

3、避免传输数据库自增ID（建议）

自增id的数据会非常好猜测，递增或递减即可。为此我们需要避免直接使用单表的自增Id作为参数来回传输，可以采⽤其他策略生成ID:

• UUID，⽅便简单，但不利于检索
• IdWorker，⼀种ID生成算法
• 其他⽅方案：如时间戳+随机数、分布式数据库⾃增ID等

另外，我们在与第三⽅对接数据时，可以采取加密id的⽅式，或使⽤其他⾮敏感数据，⽐如⽤户名、部⻔编码等可公开且不重复的字段。

暂时就写到这里，如有变化，会及时更新的。如有错误，请大家及时提出。
再次感谢吴翰清大佬！