web逻辑漏洞,怎么挖逻辑漏洞

笔者前言：

作为一个地道的安服仔，每天的工作就是渗透测试，在测试过程中积累了很多经验，看到了各种各样的怪圈，才有了这样的文章。 以下文章均在本人测试中发现，编号，入侵删除

业务逻辑漏洞业务逻辑漏洞是指攻击者利用业务/功能设计缺陷获取敏感信息或破坏业务完整性。 多体现在密码修改、越权访问、密码回收、交易支付金额等功能上。 逻辑漏洞破坏方式不是在程序中追加破坏内容，而是利用逻辑处理不严密、代码问题或固有不足来利用漏洞的方式。

既然提到了完整性，我想在挖掘漏洞的时候经常能看到三个关键词。 他们分别是机密性、完整性和可用性。 那么，他们是什么？ 他们表现出了什么样的特性呢？

信息安全工程师应该知道的机密性是一种防止信息只被合法用户访问，不会泄露给未经授权的用户、实体或进程，也不会被他们利用的特性

完整性是指所有资源只能通过批准者或授权的方式进行修改，且在信息未经批准后无法更改的特征

可用性是指所有资源均可按需咨询被许可方，即信息可由授权实体访问并按需使用的特征

越权干预漏洞描述及测试方法：

此类漏洞是指APP应用程序在检查身份验证时存在缺陷，攻击者获得低权限用户帐户后，通过多种方式绕过权限检查，访问或操作本来无法访问的高权限功能在实际的代码安全审查中，这种漏洞往往很难通过工具进行自动检测，因此在实际应用中危害很大。 这里甚至说，遗漏清扫是无法清扫越权的漏洞，清扫工具是无法清扫业务逻辑漏洞的。

此处为传送门- https://blog.csdn.net/weixin _ 48421613/article/details/11117004。

修复方式

执行用户交互权限检查，并更改参数以防止访问非法页面或执行非法操作。 建议检查服务器端请求的数据和当前用户id。

越权漏洞描述及测试方法：

在这里以我个人的理解来说，什么是垂直越权？ 垂直越权不是指低权限用户访问高权限用户的用户资源。 这是一般的说法。 我倒认为垂直越权应该如下。

任何用户都可以访问不属于自己的功能。 请注意，这里不是资源，而是功能。 通俗地说，用户a具有访问日志这一功能。 即使他是日志管理员，除了访问日志功能以外也没有其他功能。 用户b是来宾管理员，具有访问受访用户的功能。 此时，用户a可以访问用户b的客户地址簿，但此时是典型的垂直越权。

垂直越权不仅是get型，同样也有Post型，但get型只需知道接口的uri地址就可以访问。 这种漏洞通常危害大，利用简单。 另一方面，post型的垂直越权大多是接口的功能。 例如，可以使用“新建来宾”功能按钮访问通讯簿，但在来宾通讯簿中，“检查权限”并未使用“新建来宾”按钮。 此时也同样成为垂直越权的漏洞。 不同的是内部参数不太结构化，利用相对复杂，但不能否定其危险性。

案例如下。

这次给大家带来的情况是预约小程序，这个小程序只有两种用户，管理员用户和来宾用户。 管理员用户具有查看来宾通讯簿和添加来宾的功能；来宾用户没有任何功能，只能看到自己

由于没有进行权限检查，因此一般来宾用户直接访问来宾地址簿接口uri地址时，可以正常显示此次垂直越权

显然来宾用户没有任何功能，使用来宾用户的手机访问漏洞uri界面，成功看到了来宾数据的内容

越权测试方式并不难。 post方式直接修改COOKIE等唯一认证id的标记即可。 直接进入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认证存在缺陷，可越权登录他人账户。登录的过程中拦截数据请求，尝试修改COOKIE、uid等明显的参数

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

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

发送数据包，功能出来了

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

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

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

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

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

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

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

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

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

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

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

案例：

点击退出登录按钮

此时已退回至登录页面

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

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

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

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

案例：

新增访客示例

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

发送数次，皆成功

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

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