PHP安全：防止越权和权限控制

gclome

原文链接:PHP安全：防止越权和权限控制
在各种系统漏洞中，越权问题是对研发人员最大的考验之一，处理好越权问题既需要研发人员拥有扎实的研发能力，又需要研发人员有高度的安全意识，能周全考虑在各种业务场景中授予不同的用户以不同的功能权限和可见数据权限范围。


1、什么是越权访问

越权访问（Broken Access Control，BAC）分为垂直越权访问和水平越权访问，如图1所示。
​
图1  越权图示

垂直越权是指不同用户级别之间的越权操作。如有两个用户角色分别是普通用户和管理员，普通用户拥有查看和购买产品的权限，管理员拥有发布商品和删除商品权限，由于没有做好角色之间的权限控制，导致普通用户可以对商品进行发布和删除，跨角色操作了不属于本角色的操作和数据访问。

水平越权是指相同级别用户之间的越权操作。如处于同一级别的用户A和用户B，拥有相同的权限等级，他们能各自获取自己的私有数据（数据A和数据B），但如果系统只验证了能访问数据的角色，而没有对数据进行细分或者校验，导致用户A能访问到用户B的数据（数据B），那么用户A访问数据B的这种行为就叫作水平越权访问。

在功能页面或者接口中，如果身份认证或授权功能不完善，对数据库进行增、删、改、查的限制不严格，就很容易产生越权漏洞。

应用程序在功能对用户可见之前，应该验证功能级别的访问权限和数据级别的访问权限。并且需要在每个功能或数据被访问时在服务器端执行相同的访问控制检查。如果请求没有被验证或者验证失效，攻击者就能够伪造请求以在未经允许的情况下访问某些功能或数据。

攻击者通过水平越权访问其他正常用户的信息，用户数据泄露给攻击者，间接地给用户和企业带来损失。垂直越权的危害比较大，直接允许攻击者访问未经授权的功能，轻者可查看未授权系统数据，重则可能导致整个系统被攻击者控制或者导致系统瘫痪。

2、造成越权的原因

通常情况下，研发一个项目的功能时，流程是登录→提交请求→验证权限→数据查询→返回结果。如果“验证权限”环节存在缺陷，那么便会导致越权。例如，一种常见的存在越权的情形是研发人员安全意识不足，认为通过登录即可验证用户的身份，而对用户登录之后的操作不进行进一步的权限验证，进而导致越权问题。

（1）通过隐藏菜单实现访问控制

仅通过隐藏菜单实现访问控制。例如，使用管理员身份登录后可以看到后台管理页面的菜单，但是以普通用户登录则看不到该菜单。在这种情况下，研发人员认为普通用户不知道或者很难猜到后台管理页面的URL，因此可以实现对管理功能的保护。这其实是一种错误观点，因为攻击者完全有可能通过其他方式（如HTML/js源码分析、暴力猜解URL、利用其他漏洞等）得到后台管理URL。

（2）敏感数据存储不当造成的越权

有些研发人员缺乏安全意识，将用户信息，例如用户ID、电话、角色标示等，保存在Cookie或者URL中作为鉴别权限的依据，每次请求访问服务器从URL或Cookie中读取用户信息来判定用户是否登录，再从Cookie或URL中拿到相应的数据ID去数据库中查询详细数据。由于恶意攻击者可直接对Cookie或URL进行更改，误导业务程序，从而越权获取其他用户或者角色的数据，并且可以进行角色切换直接以受害用户的身份下达任何系统指令。

（3）静态资源未进行访问限制

用户访问动态页面时会执行相应的访问控制检查，以确定用户是否拥有执行相关操作所需的权限。但是，用户仍然会提交对静态资源的访问请求，如下载网站中的Word、Excel、PDF文档等。这些文档都是完全静态的资源，其内容直接由资源服务器返回，并不在项目服务器上运行。因此，静态资源自身并不能执行任何检查以确认用户的访问权限。如果这些静态资源没有得到有效的保护，则任何知晓URL命名规则的人都可以越权访问这些静态资源。

（4）数据归属未进行绑定校验

当用户使用系统时，如果只进行了权限校验而未对数据归属进行校验，例如一个购物网站，只对登录进行了校验，用户使用账号登录系统，就可以查看自己的订单，未对订单的归属进行校验，攻击者随意注册账号，成功登录系统，可以通过遍历订单ID查看不属于自己的订单。

PHP项目研发尽量使用单入口模式，使用单入口可以使项目权限得到统一管理，在入口处对每个请求的URL进行权限控制，区分每个URL的访问权限。在读取数据时要确定当前用户是否有数据的使用权限。

3、RBAC控制模型

RBAC（Role-Based Access Control），即基于角色的访问控制，支持公认的安全原则：最小特权原则、责任分离原则和数据抽象原则。将权限问题转换为who、what、how的问题，who、what、how构成了访问权限三元组。

who：定义用户和角色。
what：定义可以访问的资源对象。
how：定义访问形式——增、删、改、查。

1）最小特权原则得到支持，是因为在RBAC模型中可以通过限制分配给角色权限的多少和大小来实现，分配给予某用户对应的角色的权限只要不超过该用户完成其任务的需要即可。

2）责任分离原则的实现，是因为在RBAC模型中可以通过在完成敏感任务过程中分配两个责任上互相约束的两个角色来实现，例如在清查账目时，只需要设置财务管理员和会计两个角色参加即可。

3）数据抽象原则是借助于抽象许可权这样的概念实现的，而不是使用操作系统提供的读、写、执行等具体的许可权。但RBAC并不强迫实现这些原则，安全管理员可以允许配置RBAC模型使它不支持这些原则。因此，RBAC支持数据抽象的程度与RAC模型的实现细节有关。

图2所示为一种RBAC的实现方式。RBAC支持数据抽象的程度与RBAC模型的实现细节有关。
​
图2  RBAC模块关系

通过用户、用户组、角色、权限相互的关联，最终决定用户所拥有的对资源的操权限，如图3所示。
​
图3  用户拥有的对资源的操作权限

4、系统鉴权

在遵循RBAC的基础上还不能很好地防止越权，还要对功能和数据进行访问鉴权，例如登录认证、接口访问鉴权、数据访问鉴权，鉴权的同时还要做好鉴权失败的频次限制。服务器接收请求，一定要明确这个请求来自哪个用户，请求访问哪个接口、哪些数据，对接口和数据有没有访问权限。

禁止使用用户直接提交的参数进行数据查询返回敏感数据，例如使用OrderId查询订单详情、Phone、Uid查询用户信息等。应该使用身份鉴权信息与提交的参数鉴定关联性，如果属于用户的信息再进行返回。

根据Facebook公司2018年9月28日透露的消息，由一个隐私功能“View As”爆出多个漏洞。该功能的作用是让用户能够以其他用户的视角来查看自己的页面，明确自己在设置了相关的隐私设置后，他人到底还能否在自己的页面上看到那些自己希望隐藏的信息。攻击者正是发现了该功能中的多个漏洞，利用漏洞可生成并获取任意用户的“登录令牌”，并利用这个“令牌”获取登录权限，进入“已登录”的状态，最终获取用户的全部账户数据和权限，受影响的用户可能达到9000万。Facebook紧急要求9000万用户在他们的所有设备重新输入账户密码进行登录，其中已有5000万用户受到该漏洞影响，还有4000万用户可能受到过该漏洞影响。Facebook公司进一步确认，这些用户使用Facebook账户登录的第三方网站也可能受到影响，包括Spotify、Tinder和Instagram。

由于数据泄露事件频发，从2018年6月起，短短3个月的时间，Facebook公司股价下跌了近25%，市值蒸发近1500亿美元。此次数据泄露事件使得Facebook公司股价再次下跌超过3%。由此可见数据泄露事件对上市公司带来的沉重打击。

5、系统隔离

为了提高安全性，进行内外网分离也是一种不错的选择。通常情况下，系统的管理平台或高级功能只允许通过内网进行访问，可以通过配置Nginx、Apache或者通过防火墙来实现。

如果条件允许，建议将管理平台和用户使用的平台部署在不同的服务器上，同时设置管理平台服务器只允许通过内网或者堡垒机进行访问，避免普通用户接触到管理平台，这样可以提供系统整体的安全性，避免暴露在外网环境下遭受攻击。