记一次郁闷的水平越权漏洞修复

前言：

公司最近频繁接受信安考验，好多功能受到攻击，两年前开发的功能也被揪出来当做高危漏洞，记录一下解决的办法，提醒自己不要犯相同的错误。

正文：

什么是越权？

越权就是用户访问到了不应该能访问到的资源。一般分为两类，水平越权和垂直越权。

水平越权一般发生在普通用户之间，用户A可以通过直接调用接口的方式访问到了用户B的信息。垂直越权在管理员中常见，低权限的管理员通过URL或者接口直接调用到了高权限用户才能使用的功能。

我负责的模块出现的是水平越权问题，用户可以通过遍历参数的方式获取到其他用户的信息。两年前我开发这个辅助功能的时候就没什么人用，这个项目也不是很重要，当时都没有越权访问的概念。一年前领导提示要做一些限制， 我又嫌改旧代码太恶心没改，现在项目关键了起来，天天被各种测试，我的功能就有好多坑。真是不听老人言，吃亏在眼前，墨菲定律威力真的巨大。所以发现有坑一定要改，要不然很容易突然天降大锅。

解决水平越权问题的思路：在查询时把结果中的关键参数都用用户的身份信息加密返回，前端用加密过的参数encryptedParam和没加密的参数param一起调用后端接口；在后端把参数param按照规定的方式再次加密获取一个dftEncryptedParam，比较encryptedParam和dftEncryptedParam是否相等，如果相等表示验证成功。

注意使用的身份信息不能是http请求的输入参数，需要从session中进行获取。

解决垂直越权问题的思路：为所有的管理员指定角色，同时为每一个角色都指定权限代码。超级管理员的权限代码可能是m.*，而用户信息管理员的权限代码是m.user，将用户的角色和权限信息都放入session中保存。对每个需要权限才能访问的功能都指定好权限代码列表。例如管理员A拥有超级管理员的权限，而管理员B只拥有用户信息管理的权限。假如管理员B想要通过输入URL或者直接调用请求进入到产品信息管理的界面，在实现功能前拦截请求，判断session中当前用户的权限信息是否与接口中指定的权限列表匹配，如果匹配才继续执行。

虽然有以上思路，但是在网站上直接暴露了接口的路径和参数还是很不安全，很容易被攻击。是否可以将前端发出的请求全部加密，由Nginx解密后再路由到后端。

很简单的思路，全当记录啦。