唉！SM4加密也挡不住垂直越权？这坑我替你们踩过了
兄弟们，今天咱们不聊那些虚头八脑的理论，就说说我上周在项目里撞见的那个“灵异事件”——SM4加密加持的后台，居然被一个实习生用浏览器F12就捅穿了垂直越权漏洞，这事儿到现在想起来，我后背还一阵发凉,真的！
事情是这样的，我们有个内部管理系统，安全部门为了“固若金汤”，特意给所有接口的参数都套上了SM4加密，我当时心里还美滋滋地想：“喲，国密算法都上了，这回总该稳如老狗了吧？”结果，现实直接给我一记响亮的耳光,打得我眼冒金星啊！
咱们先说说这个垂直越权是啥玩意儿。 说白了，就是低权限用户（比如普通员工）能通过某种技术手段，干高权限用户（比如管理员）才能干的活儿，比如你明明只能看自己的工资条，结果通过改个参数，就能看到CEO的年薪，嘿，这酸爽,谁试谁知道！
而SM4加密呢，它确实是个好东西，分组对称加密，密钥长度128位，破解难度巨高，可问题出在哪儿呢？就出在我们程序员对加密的“迷之自信”上，我们当时想的是：“看，我参数都加密了，你还能拿我咋地？改一个字节你都解不开！” 这种心态，现在回头看,简直就跟掩耳盗铃没啥区别啊！
我是怎么发现的呢？那天下午，我正调试一个“导出用户列表”的功能，因为数据敏感，后端特意校验了请求里的角色字段（RoleID），但这个RoleID是经过SM4加密后放在Cookie里的，按照常理，我没法伪造更高级别的RoleID,因为我没有密钥嘛。
可是，我灵机一动啊！我干嘛非要折腾那个加密的Cookie呢？我直接看接口的响应包不就行了？我悄悄用普通账号A发起请求，抓包一看，好家伙！虽然我发出去的请求是加密的，可服务器返回的“数据总条数”和“当前页码”这些分页信息，居然他娘的是明文！而且更绝的是,接口竟然没有强制校验当前登录用户与查询数据范围的关联性。
那，垂直越权的机会就来了！我压根不需要破解SM4加密，我只需要把接口里的page=1改成page=2，把action=export改成action=delete试试……结果你猜怎么着？虽然数据字段还锁着，但我居然能用普通账号调用了管理员的导出全部用户接口，而且碰巧那个接口为了性能，对“当前操作人身份”的校验是写在数据库查询逻辑里的，而非入口拦截，我不用解密，只是通过并行调用更高权限的接口，再配合一个低权限的合法签名……哎哟喂,数据哗啦啦就全出来了！
那一刻，我真是哭笑不得，心里头有一万只羊驼狂奔而过啊。SM4加密就像是一把坚固的防盗门，你把它焊死在参数校验上，结果人家小偷根本不走门，直接从窗户上撬开一块玻璃就钻进去了——垂直越权的本质，是逻辑层面的信任边界破裂,跟你门上用的锁是铜的还是铁的关系真不大！
咱们得唠明白，SM4加密解决的是“传输安全”和“数据防篡改”问题，它保证的是“链路里没人能看到我的密钥”以及“正常情况下你改不懂密文”，但垂直越权属于业务逻辑漏洞，它考验的是“服务端是否对每一个请求都进行了充分的身份与授权校验”,这两个完全不是一个维度的东西啊喂！
我后来复盘了一下，当时安全部门那帮老哥还跟我拍胸脯：“有了SM4，放心！” 我呸！他们完全没意识到，加密强不等于授权强，你想想，就算你把所有参数都加密成了一坨乱码，但只要服务器后台的逻辑是“用当前登录ID去查自己权限，然后直接返回已查询数据的全部关联接口”，那攻击者随便用一个合法账号，就能通过遍历接口或调整参数，去访问那些本不该他碰的接口，加密再牛，也防不住服务器自己“认贼作父”呀！
我想给各位在座的安全运维提个醒：千万别再把SM4加密当免死金牌了！它对付的是外部窃听和中间人攻击，但对付“内部用户故意越权”这种阳谋，它真的无能为力，咱们必须要做的是前后端双重校验，每一个接口，每一行数据，都得拿着当前会话的RoleID去数据库中比对,而不是只在入口处验一次签名就放行。
这次教训过后，我们团队做了两件事：第一，把所有敏感接口都加了“越权检测中间件”，每次请求都动态核查主体与客体之间的许可关系；第二，把SM4加密的密钥分成了“会话级动态密钥”，并且强制绑定用户角色，但这只是辅助，核心的还是那一句——权限判断只信服务端，不信客户端传参。
唉，说到最后，我还是有点心有余悸，这事儿要是被甲方爸爸知道了，估计得当场血压拉满，行了，不说了，我得再去检查一遍我们新上线的鉴权逻辑了，可不能再让SM4加密背这黑锅了！
各位朋友，如果你也想搞懂这些实战中的安全漏洞，或者想学习更多网络安全渗透与防御技巧，欢迎添加QQ：123456789（备注“安全学习”），咱们一起交流，别再踩我踩过的坑了！
