常见的业务逻辑漏洞-整合篇

笔者前言：
作为一个地地道道的安服仔，每日的工作就是渗透测试，在测试的过程中累积了很多的经验，看到了各种各样奇葩的漏洞，于是乎便有了这样的一篇文章。以下文章均由本人测试发现并打码，侵删

什么是业务逻辑漏洞

业务逻辑漏洞就是指攻击者利用业务/功能上的设计缺陷,获取敏感信息或破坏业务的完整性。一般出现在密码修改、越权访问、密码找回、交易支付金额等功能处。 逻辑漏洞的破坏方式并非是向程序添加破坏内容,而是利用逻辑处理不严密或代码问题或固有不足，进行漏洞利用的一个方式。

既然提到了完整性，相信大家在漏洞挖掘的时候经常会看到三个关键字，他们分别是保密性、完整性和可用性，那么他们又是什么，他们又代表哪些特性呢？

信息安全工程师应该知道的事情

机密性是确保信息仅被合法用户访问，而不泄露给非授权用户、实体或过程，或供其利用的特性

完整性是指所有资源只能有授权方或以授权的方式进行修改，及信息未授权不能改变的特性

可用性是指所有资源在适当的时候可以由授权方询问，即信息可被授权实体访问并按需求使用的特性

越权漏洞

漏洞描述及测试方法：
这类漏洞是指应用在检查授权（Authorization）时存在缺陷，使得攻击者在获得低权限用户帐后后，可以利用一些方式绕过权限检查，访问或者操作到原本无权访问的高权限功能。在实际的代码安全审查中，这类漏洞往往很难通过工具进行自动化检测，因此在实际应用中危害很大。这里就是说，漏扫是扫不出越权漏洞的，甚至说漏扫工具是扫不到业务逻辑漏洞的。
这里是传送门->>>https://blog.csdn.net/weixin_48421613/article/details/111117004.

修复方式：
对用户操作进行权限校验，防止通过修改参数进入未授权页面及进行非法操作，建议在服务端对请求的数据和当前用户身份做校验检查。

垂直越权

漏洞描述及测试方法：
在这里以我个人的理解来讲述，什么是垂直越权？垂直越权并非是低权限用户访问高权限用户的用户资源，这种说法是笼统的。我反而认为，垂直越权应该是：
任意用户访问到不属于自己的功能，注意，这里不说资源，而是功能。通俗来讲，就是用户A拥有一个功能，那就是访问日志，假设他是一个日志管理员，他除了访问日志功能没有其他功能。用户B是一名访客管理员，他有一个功能，访问来访的用户。此时用户A可以访问用户B的访客通讯录，那么此时就是典型的垂直越权。
而垂直越权不仅仅是get型，同样也有Post型，而get型的仅仅需要知道接口的uri地址即可访问，这类漏洞通常危害极大，且利用简单；而post型的垂直越权大多是接口的某个功能，比如说访问通讯录有一个新增访客功能按钮，而访客通讯录做了权限校验但是新增访客按钮并没有做，这个时候也是一样会形成垂直越权的漏洞，区别就是里面的参数是不太好构造的，相对而言利用起来会复杂一些，但是并不能否认其危害性。

案例如下：
此次为大家带来的案例是一个预约小程序，这个小程序只有两种用户，管理员用户以及访客用户。管理员用户拥有查看访客通讯录、新增访客功能；而访客用户则是啥功能都没得，仅能查看自己
而此次垂直越权则是由于未做权限校验导致普通访客用户直接访问访客通讯录接口uri地址即可成功查看到


很显然，访客用户是没有任何功能的，此时利用访客用户的手机去访问漏洞uri接口，成功查看访客数据内容

垂直越权测试方式式不难的，post方式就直接修改cookie这类的唯一验证身份的标识就可以，get型的直接访问漏洞页面即可，具体测试方式在以前的文章里有详细的介绍，请大家移步即可

水平越权

漏洞描述及测试方法：
水平越权，攻击者能执行与自己同级别的其他用户执行的操作，即尝试访问与它拥有相同权限的用户资源，即水平越权

这类说法也是不太负责任的，因为有时候普通用户与管理员用户很显然是不同级别的，但是二者都有一个查看公告的功能，只不过管理员能查看更多的公告，而普通用户只能查看自己的公告，此时若是普通用户成功的越权访问到管理员才能看到的公告信息，那么此时难道就是垂直越权了?我想不是吧

所以我觉得，应该说是，攻击者能执行与自己相同用户功能的数据内容，即尝试访问与他有相同功能的用户的资源，即水平越权。

这里的危害要相对于垂直越权危害更高，因为他的利用方式 更加的简单，毕竟你不需要执行任何的猜测目录数据的步骤，直接使用本功能的数据包，进行某一段数据的修改或许就可以访问到其他用户的用户资源。

为了方便大家观看效果，这里以某一个学堂系统为案例。这个系统分为管理层、各个部门分层、各个公司分层，每一个用户访问的课程内容都是较其他用户不相同的。
也就是说，员工甲是来自营销部门的，那么他只能查看营销培训课程；员工乙是一名营销部门总经理或者是其他公司总经理，那么他不但可以查看到本部门普通员工的课程，也能查看到针对于公司高管的课程内容。

案例如下，这个页面是用户甲的课程

通过遍历他人的课程参数进行越权访问

这个参数构造复杂，此处仅为方便展示，因为按照测试案例，参数若是不可构造，构造复杂的也可以说是可证明安全的，这里给他算上是因为在其他管理接口存在垂直越权，可以遍历到课程的参数
所以说在大家测试过程中，若是遇到这种不可遍历的参数，那么是不应该算的，这里仅为大家带来测试的方式，实际上无论是get型还是Post型，水平越权造成的参数实际上只有那么一个而已，大家只要找出这个参数便可以了。

支付逻辑漏洞

漏洞描述及测试方法：
实际上这个情况常见的情况有：
负值反冲、正负值对冲、甚至是直接修改数量单价、总价等等。
负值反冲，就是说程序没有校验订单的取值范围，若是使用负值则可以进行支付逻辑利用；
正负值对冲，是指，通过修改订单的数量或者是单价、总价来达到少付钱的目的，但是你的值不能是负值

此次带来的案例，就是我在测试过程遇到的一个，部分课程需要加入购物车后充值购买，于是乎我将单价、总数进行更改，成功的达到了少付款的目的，一元购。

案例如下：
首先页面存在学时卡购买

加入购物车时，价格正常，此时不可以修改，否则会被拦截到

此时点击下一步，拦截数据包，数据如下

而后修改总价格

此时发送数据包，成功一元购

修复方式：
1.服务器端在生成交易订单时，商品的价格从数据库中取出，禁止使用客户端发送的商品价格。

2.服务器端在生成支付订单时，对支付订单中影响支付金额的所有因素（比如商品ID、商品数量、商品价格、订单编号等）进行签名，对客户端提交的支付订单进行校验。

短信炸弹

漏洞描述及测试方法：
是的，你没看错，短信炸弹严格意义上来讲也属于业务逻辑漏洞，诱发原因是没有进行时间戳等校验，此处与信息安全描述的重放攻击类似，在测试过程中，某接口存在发送手机验证码的功能，但是短信发送平台没有去识别该用户发送验证码的时间等，导致短时间内可以重复的发送大量的短信校验码，不但对系统资源进行了消耗，同时也对用户造成了恶劣的影响。

修复方式：
最简单的就是短信平台对同一手机号进行识别，一定时间内不允许继续发送验证短信请求，也就是所谓的一分钟内不允许继续请求

案例：
某平台查询信息时需要请求验证码进行身份校验

点击发送验证码时，使用burp进行拦截，同时放入至Intruder模块，重复发包10次

发送成功

未授权访问

漏洞描述及测试方法：
未授权访问漏洞，是在攻击者没有获取到登录权限或未授权的情况下，不需要输入密码，即可通过直接输入网站控制台主页面地址。

通俗的来讲，就是你本来需要登录才能实现的功能，你现在不需要登录就能看到，这类漏洞最容易测试，同时也最容易被忽略，测试方式只需要打开新的隐私浏览器进行访问，或使用burp进行数据包拦截，而后将所有的用户信息全部删掉，若是还能正常访问，那就是存在此漏洞

修复方式：
在系统中，加入用户身份认证机制或者tonken验证，防止可被直接通过连接就可访问到用户的功能进行操作

案例：

某路由器存在一处漏洞，此漏洞其实是路由器配置页面，只需要构造一条参数即可对该页面进行访问，而后直接便可以获取到该路由器登录页面的用户名以及密码。

此类漏洞不容易被察觉，此处说是未授权访问，不如说也是信息泄露
所以我按照信息泄露来了一波

用户名枚举

漏洞描述及测试方法：
这个没啥好说的，在登录的时候，输入不存在的用户名和错误的密码，若是提示“该用户并不存在”，则证明该漏洞存在。
我遇到的一个奇葩预约系统，对用户校验的时候显示校验用户的身份和访客的身份，若是访客存在密码错误，便提示“该访客密码错误”，说实话，挺low的

修复方式：
统一所有的提示信息为“用户名或密码错误”

案例如下：

验证码问题

这里玩法就比较多了，验证码这里你可以说是图形验证码，你也可以说是短信验证码。

验证码不失效

漏洞描述及测试方法：
这里说的是图形验证码使用过一次未立即失效引起的问题，在我遇到的案例中，都是那种验证码使用后依然可以继续使用，这里测试建议抓包之后，直接在不放包的情况下放入之burp的Intruder模块进行暴力破解测试

修复方式：
使用过一次验证码后，立即注销即可

案例：

短信验证码可预测

漏洞描述及测试方法：
这里的短信验证码可预测，是指的在发送短信验证码的同时，拦截数据包请求，而后进行发包，会看到返回的手机验证码，或在发送请求短信的时候，即将发送至手机里的验证码出现在请求数据吧内，这两种情况我都遇到过。

修复方式：
不要将验证码返回即可

案例：

获取验证码的同时进行数据包拦截


与手机接受到的验证码对比，一毛一样

短信验证码绕过

漏洞描述及测试方法：
这里指的绕过其实就是特权号码，比如说0000 1111 这种的，或者输入任意的验证码，而后直接修改code返回值就可以，这个我没遇到过特权码绕过，遇到过登录的时候进行code返回值进行更改登陆成功的

修复方式：
删除特权码，不要仅仅对code返回值进行校验即可

短信验证码暴力破解

这里面是因为短信验证码过于短，只有四位，输入错误次数无限制，并且失效时间过长，且使用一次之后并不失效引起的。

大家都知道burp是有枚举模块的，若是短信验证码太短了那么枚举的方案就会很少，大大的加大了爆破成功的可能

修复方式：
限制输入错误的次数，错误五次需要重新获取；
尽可能是有六位验证码；
失效时间建议不要超过五分钟；
使用过一次立即失效

这里我遇到的案例，其实都遇到过，但是由于时间实在是过于久远，所以就不上图了，大家心领神会即可，毕竟没有什么测试难度

登录认证绕过

漏洞描述及测试方法：
通常存在于仅适用前端校验，可以通过关闭js特效或者是伪造responsed的code值进行绕过

修复建议：
不使用前端校验，严格校验用户的数据

案例：
输入任意用户名密码

点击登陆按钮同时使用抓包工具进行数据包拦截

修改code参数
登录成功

密码重置漏洞

漏洞描述及测试方法：
在得知他人的手机号码的时候，通过修改response返回值欺骗服务器进行重置密码

修复建议：
正确的校验验证码，不要使用前端校验

示例：
1.点击普通用户找回密码，输入用户名
2.修改返回数据值
3.完成第一次绕过，输入任意验证码，如法炮制
4.输入新的密码


5.输入用户名admin 密码 ******登录成功

SSO认证缺陷

漏洞描述及测试方法：
SSO认证存在缺陷，可越权登录他人账户。登录的过程中拦截数据请求，尝试修改cookie、uid等明显的参数

修复建议：
正确的配置用户的权限信息，不要使用简单的cookie或session

示例：
首先访问某达登录页面
此时用户为普通用户，登录后仅有一个功能
退出登录重新登陆，同时拦截数据包如下
尝试修改cookie为admin

发送数据包，功能出来了

空口令漏洞：

漏洞描述及测试方法：
找到网站登录页面，尝试输入用用户名，不使用密码直接进行登录。若是不使用密码直接登录则存在空口令

修复建议：判断输入密码是否为空，禁止空口令登录。

案例：
又又又是一次漏洞挖掘，还是某个神秘的路由器，在控制台页面明显是需要登录的

当我未使用密码的时候，点击登陆，神奇的发现，登录成功

由于CVND是没有空口令的，所以写了一个未授权访问

会话固定

漏洞描述及测试方法：
在用户进入登录页面，但还未登录时，就已经产生了一个session，用户输入信息，登录以后，session的id不会改变，也就是说没有建立新session，原来的session也没有被销毁）。攻击者事先访问系统并建立一个会话，诱使受害者使用此会话登录系统，然后攻击者再使用该会话访问系统即可登录受害者的账户

简而言之，就是说，当sessionid附着在url的get请求里，危害才会最大化，因为这样的话可以通过钓鱼链接的方式诱导用户去登录，而后利用此特性直接使用该生效的sessionid进行登录。

修复方式：
在用户提供的认证信息（例如用户名和密码）、相应的权限级别发生变化时，服务器端应重新生成SessionID，并强制失效之前的会话

案例：
时间太久，找不到了

会话重用

漏洞描述及测试方法：
用户退出系统后，服务器端Session未失效，攻击者可利用此Session向服务器继续发送服务请求。
最常见的其实就是你登录之后，点击注销后，此时页面退回至登录页面，使用浏览器自带的退回上一页功能，依然可以返回至注销前页面

修复方式：
用户退出系统后，服务器端应清空此用户的Session信息

案例：

点击退出登录按钮

此时已退回至登录页面

点击浏览器返回按钮，成功回退至注销前页面

重放攻击

漏洞描述及测试方法：
关键业务操作未作token或者唯一标识码，导致攻击者可以重复多次进行请求，导致恶意操作。如重复交易等问题。

这里测试方式便是，在请求的时候进行burp抓包，而后重复的发送数次，若是成功发送，则是存在此漏洞

修复方式：
服务端应用程序应检查客户端提交的数据的唯一性，如使用流水号、时间戳、token等，并将流水号、时间戳等进行签名。

案例：

新增访客示例

随意选中一个数据作为枚举点

发送数次，皆成功

返回验证，发现重放成功，成功批量注册数个用户

以上便是较为常见的业务逻辑漏洞了