前言

上篇文章的发布引起了很多读者的浏览，有很多读者也催更希望读到续集，作者也收获到读者的鼓励，说明这条路线对大家有帮助，是有意义的。所以，今天作者将继续阐述在审计Java代码时的思路。

概述

上篇文章所讲的SQL注入和中间件漏洞的审计，其实在大多数的情况下SQL注入是不会存在的，两方面原因。1.SQL注入存在的历史太过悠久，以至于人尽皆知。2.大多数Java开发在入职面试时，考官都会将这个细节当作问题抛给开发者。所以要是靠这个漏洞，那大黑阔们估计是要饿死的。今天带来的是越权漏洞的审计，这个漏洞能拿下百分之八十的JavaWeb代码。

越权漏洞的前世今生

越权漏洞分为垂直越权和水平越权，在大多数场景中都存在水平越权，所以先跟读者讲述水平越权。

大多数功能当中，删除功能一向是水平越权的“重灾区”。开发在实现删除功能时，前端将id号传给后台，后台将此id的数据进行删除。这么想确实没什么问题，但是问题出就出在删除上。原因在于，当后台拿到id时不去判断当前id是否属于登录用户，直接将id数据进行删除，这就导致了越权漏洞的产生。

下面上代码

这一套删除执行链中，并没有对前端传来的id进行任何操作，直接进行删除。熟不知，在前端向后台传送id的过程中，id值被篡改修改成其他用户下存在的记录id，将其他用户的记录进行删除，这就造成了水平越权的产生。

水平越权往往被定性为低危漏洞，这里作者就要替越权发声了，从某种角度来讲，如果渗透者发现了一个这样的越权漏洞，完全可以编写一个脚本。脚本的内容为循环请求这样的接口，参数id为从1依次递增。后台执行这样的删除操作，可想而知，典型的删库。

FREEBUF平台爸爸，某处存在此水平越权。发生地点不透露，但足以说明存在率(多有得罪)。

看到这里，想必很多读者有知道了一个“获得银手镯”的方法，作者建议遇到这种漏洞自己创建一个用户进行测试即可，切勿使用这种方式扩大“战果”。此假设只是从角度的问题证明越权的危害性。

防御：这么大的漏洞为什么这么多Java开发者不去修复，存在率竟如此之高？如果读者是一名开发那么仔细阅读下文（提醒）

原因有二：1.是后端开发者完全想不到在前端向后端传值时会被篡改没太过依赖前端。（所有的前端传参必须零信任）2.如果后端拿到前端参数的id，再去查询此id是否属于当前用户，意味着还需要走一条sql，无疑是对数据库性能的又一次损耗，对开发成本的又一次增加。解铃还须系铃人，问题产生的关键就在于id，所以作者建议在生成id时不要采用从1开始依次递增的方法，采用雪花算法生成id。下面上代码

这样的id有什么好处？当渗透者暴力猜解数据库进行删库操作时，此id无法被猜解，因为数据量太过庞大，此处不在赘述雪花算法。但是，此方法只能在某种程度上解决这样的问题，如果渗透者真的头铁硬试，我们毫无办法。（抬一手，留口饭吃）。

下面讲垂直越权，垂直越权完全依靠前端页面显示作为用户点击的限制，挖掘此处漏洞渗透者必须拥有高权限账号，还有一个低权限账号。使用低权限账号调用高权限才有的接口进行测试。

讲到这里，作者觉得这个漏洞大家不必挖掘，因为能产生这种漏洞不是开发者技术和逻辑的问题。完全是开发者懒的问题，懒到不想写代码。而且垂直越权大多数开发者选用Apache Shiro和springSecurity框架进行权限判定。渗透者可以更关注shiro的两个漏洞在垂直越权上。

这种漏洞除了开发者态度有问题基本不可能发生，如果渗透者发现过此类型的洞可以将开发者定性为“菜鸡”，并且拉出去“砍死一百次”。

结尾

讲到这里，关于JavaWeb审计的不需要代码基础的洞讲完了，接下来的文章当中讲述JavaWeb中的逻辑漏洞，这个区域才是Java漏洞的真正聚集地。但是意味着读者需要一定的Java功底才能继续跟进，如果读者想继续学习Java审计这一系列，请跟我一起学习Java开发吧~，我是小杨，感谢大家阅读关注。