大家好，又见面了，我是你们的朋友全栈君。

目录

逻辑漏洞简介

逻辑漏洞分类

逻辑漏洞重要性

越权漏洞

概念

分类

产生原因

修复建议

密码重置漏洞

概念

成因

密码找回漏洞

修复建议

验证码漏洞

漏洞概念：

漏洞成因：

漏洞分类：

支付漏洞

原理

分类

防御

投票积分抽奖漏洞

利用方法

防御方法

---

逻辑漏洞简介

逻辑漏洞就是指攻击者利用业务/功能上的设计缺陷，获取敏感信息或破坏业务的完整性。一般出现在密码修改、越权访问、密码找回、交易支付金额等功能处。

逻辑漏洞的破坏方式并非是向程序添加破坏内容，而是利用逻辑处理不严密或代码问题或固有不足。操作上并不影响程序运行，在逻辑上是顺利执行的。

这种漏洞一般的防护手段或设备无法阻止，因为走的都是合法流量。也没有防护标准。

逻辑漏洞分类

越权漏洞 密码修改 密码找回 验证码漏洞 支付漏洞 短信轰炸 投票/积分/抽奖

逻辑漏洞重要性

常见的OWASP漏洞，通过漏洞扫描工具，大多支持自动化或者半自动化扫描出来；并且传统的安全防御设备和措施收效甚微；

但逻辑漏洞属于和系统自身功能和逻辑有关系的漏洞，每一家的漏洞出现可能存在一定的独特性，很难复制或者通过规则通过脚本扫描，因此逻辑漏洞大多需要配合代码审计和手动测试才可发现相关漏洞，也是工具无法完全替代人所作的一类漏洞；

越权漏洞

概念

越权访问（Broken Access Control，简称BAC）是Web应用程序中一种常见的漏洞，由于其存在范围广、危害大，被OWASP列为Web应用十大安全隐患的第二名。

该漏洞是指应用在检查授权时存在纰漏，使得攻击者在获得低权限用户账户后，利用一些方式绕过权限检查，访问或者操作其他用户或者更高权限。越权漏洞的成因主要是因为开发人员在对数据进行增、删、改、查询时对客户端请求的数据过分相信而遗漏了权限的判定，一旦权限验证不充分，就易致越权漏洞。

其中越权访问分为： 水平越权 垂直越权

分类

水平越权：相同级别（权限）的用户或者同一角色中不同的用户之间，可以越权访问、修改或者删除其他用户信息的非法操作。如果出现此漏洞，可能会造成大批量数据的 泄露，严重的甚至会造成用户信息被恶意篡改。

水平越权：指攻击者尝试访问与他拥有相同权限的用户资源。例如，用户A和用户B属于同一角色，拥有相同的权限等级，他们能获取自己的私有数据（数据A和数据B），但如果系统只验证了能访问数据的角色，而没有对数据做细分或者校验，导致用户A能访问到用户B的数据（数据B），那么用户A访问数据B的这种行为就叫做水平越权访问

垂直越权 ：就是不同级别之间的用户或不同角色之间用户的越权，比如普通用户可以执行管理员才能执行的功能。

垂直越权：由于后台应用没有做权限控制，或仅仅在菜单、按钮上做了权限控制，导致恶意用户只要猜测其他管理页面的URL或者敏感的参数信息，就可以访问或控制其他角色拥有的数据或页面，达到权限提升的目的。

产生原因

水平越权和垂直越权的定义不一样，但漏洞原理是一样的，都是账户体系上在判断权限时不严格导致存在绕过漏洞，这一类的绕过通常发生在cookie验证不严、简单判断用户提交的参数，归根结底，都是因为这些参数是在客户端提交，服务端未严格校验。

1.通过隐藏URL

实现控制访问有些程序的管理员的管理页面只有管理员才显示，普通用户看不到，利用 URL 实现访问控制，但URL 泄露或被恶意攻击者猜到后，这会导致越权攻击。

2.直接对象引用

这种通过修改一下参数就可以产生水平越权，例如查看用户信息页面 URL 后加上自己的 id 便可查看，当修改为他人的 ID 号时会返回他人的信息，便产生了水平越权。

3.多阶段功能

多阶段功能是一个功能有多个阶段的实现。例如修改密码，可能第一步是验证用户身份信息，号码验证码类的。 当验证成功后，跳到第二步，输入新密码，很多程序会在这一步不再验证用户身份，导致恶意攻击者抓包直接修改密码。

4.静态文件

很多网站的下载功能，一些被下载的静态文件，例如 pdf、word、xls 等，可能只有付费用户或会员可下载，但当这些文件的 URL 地址泄露后，导致任何人可下载，如果知道 URL 命名规则，则会便利服务器的收费文档进行批量下载。

5.平台配置错误

一些程序会通过控件来限制用户的访问，例如后台地址，普通用户不属于管理员组，则不能访问。但当配置平台或配置控件错误时，就会出现越权访问。

修复建议

1、前后端同时对用户输入信息进行校验，双重验证机制

2、 执行关键操作前必须验证用户身份，验证用户是否具备操作数据的权限

3、特别敏感操作可以让用户再次输入密码或其他的验证信息。

4、可以从用户的加密认证 cookie 中获取当前用户 id，防止攻击者对其修改。 或在 session、cookie 中加入不可预测、不可猜解的 user 信息。

5、直接对象引用的加密资源ID，防止攻击者枚举ID，敏感数据特殊化处理

6、永远不要相信来自用户的输入，对于可控参数进行严格的检查与过滤

密码重置漏洞

概念

什么是密码重置？

顾名思义，就是修改掉原来的密码；密码重置的途径有哪些？

1、一个网站，一般我们可以登录进入个人中心，直接修改密码；

2、当我们忘记密码是还可以使用系统自带的密码找回功能进行密码修改；

什么是密码重置漏洞？

密码重置这个功能本身没有问题，但如过对密码重置功能的验证机制不够完善就形成了漏洞；

成因

一、基于修改密码的

如果后台没有对旧密码进行验证，就直接让输入新密码

1、第一种方式，如果存在CSRF漏洞，我们就可以利用一波;

2、如果存在越权漏洞，就可以直接修改其他人的密码;

3、点击修改后抓包测试，观察数据库包有没有验证类似cookie随机数，如果没有的话，可以尝试修改用户名、手机号或者uid来尝试重置其他密码;

如果后台是通过向注册手机或者注册邮箱来重置密码的，关于验证码的漏洞我们都可以尝试，这种方式的前提是你已经通过某种方式进入到了对方的个人中心，所以意义不太大.

二、基于找回密码的

一般情况下当我们点击找回密码的时候都是通过验证手机号或者验证邮箱，这就又变成了验

证码的问题;

\1.验证码发送后前端返回

\2. 未限制验证码次数导致验证码爆破

\3. 验证码有规律或可控

\4. 验证码被放在返回包中

\5. 输入验证码后通过修改响应包的状态来重置密码

\6. 验证码为空（原理就是后台未考虑验证码为空的情况，直接就是如果存在，然后下面仅 判断了存在的情况）绕过或者万能验证码

\7. 拦截数据包，发送验证码时可以向多个手机号发送验证码，这个时候就可以添加个云短信，直接接受验证码完成修改等等

密码找回漏洞

密码找回是出现逻辑漏洞问题最多的一个功能，因为它的交互流程最多，目前找回密码的方式比较常见的有邮箱验证码、手机验证码以及密保问题，

1.输入用户名/邮箱/收机阶段

交互过程：即输入要重置的账号信息，点击确定时，大部分应用会直接从数据库中读取用户邮箱和手机信息，并且发送验证码，还有部分程序在输入用户名后，会提示使用手机还是邮箱找回密码。

在提交的时候可以直接抓包修改手机或者邮箱参数，这时如果后端没有做验证，原本发送给账号A的验证码就会发送到被我们篡改的手机或者邮箱上，利用接收到的验证码即可重置密码。

2.填写验证码和新密码阶段

填写验证码和新密码就意味着我们已经拿到了验证码或者重置密码的URL，这里存在的

主要问题有：

（1）验证凭证较简单，可以暴力破解。

目前大多数手机短信重置密码的验证码都是4位或者6位数字，如果提交验证码的地方没有对这个验证码进行错误次数限制，则会存在可以爆破的问题，这是目前最常见的一种找回密码漏洞利用方式。

（2）验证凭证算法简单，凭证可预测。

部分网站找回密码的Token是根据当前用户的“用户名+邮箱”或者时间戳进行一次MD5后生成，这就存在一定得预测性，利用自己写的算法去碰撞即可拿到争取到的重置密码凭证。

（3）验证凭证直接保存在源码里。

目前这种比较少，不过也存在一定比例，一种是在点击发送验证码的时候就可以直接在源码里看到给当前用手机或者邮箱发送过去的验证码，还有一种是在输入验证码的时候， 源码里面就直接保存了正确的验证码。

3.发送新密码阶段

凭证未绑定用户：我们在找回密码的时候，发送到邮箱的链接通常是如下这个样子：http://www.xxx.com/user.php?m=repwd&uid=用户ID&key=凭证密钥&email=邮箱

当请求这个链接的时候，后端程序根据uid和key对应上了从而判断这个找回密码的链接是否有效，但是在将新密码提交到服务器的时候，服务器端并没有判断当前这个key是否跟uid或者email匹配，而是直接修改掉了uid或者email指定的用户密码，这样我们只要拦截修改密码的请求包，将里面的用户参数修改成我们要篡改密码的用户账号即可。

修复建议

1.接收验证码的邮箱和手机号不可由用户控制，应该直接从数据库中读取出来。

2.加强验证凭证复杂度，防止被暴力破解。

3.限制验证凭证错误次数，单个用户在半个小时内验证码错误三次，半小时内禁止找回密码。

4.验证凭证设置失效时间。

5.验证凭证不要保存在页面。

6.输入用户邮箱或ID、手机号取验证凭证的地方需要设置验证码防止短信炸弹和批量找回等。

7.验证凭证跟用户名、用户ID、用户邮箱绑定，找回密码时验证当前凭证是否是当前用户的。

验证码漏洞

漏洞概念：

验证码机制主要用于用户身份识别，常见可分为图片验证码、数字验证码、滑动验证码、短信验证码、邮箱验证码等；

漏洞成因：

服务端未对验证时间、次数作出限制，存在爆破的可能性。验证码常用在批量注册，任意用户登录场景。

漏洞分类：

1、前端验证绕过

原理：前端验证码绕过一般是前端JavaScript脚本生成验证码，验证的工作在前端进行；

思路：直接删除相对应的部份的代码即可，要求能够大概看懂前端的代码；

2、后端验证码未刷新

原理：后端绕过情况1：后端代码在逻辑上存在问题，验证失败时，验证码不过期，可以继续做认证（也算作逻辑漏洞）；

思路：这类情况需要Burp抓包测试验证；

实战：东塔攻防世界-后端验证码绕过

3、TOKEN验证可提取

思路：利用burp工具，可以每次自动提取后台返回的token值，用于下一次的爆破使用；

支付漏洞

原理

支付漏洞，是一种很简单的逻辑漏洞，通过抓包简单修改数据包即可实现。

世界上的公司分为俩种，一种是还没被黑客攻击过的，另一种就是已经被 黑客 攻击过的。

所以企业也越来越重视网络安全这块，这样的支付漏洞就那么好找了…….

商户网站接入支付结果有两种方式，一种是通过浏览器进行跳转通知，一种是服务器端异步通知；

Ø 浏览器跳转

基于用户访问的浏览器，如果用户在银行页面支付成功后，直接关闭了页面，并未等待银行跳转到支付结果页面，那么商户网站就收不到支付结果的通知，导致支付结果难以处理。而且浏览器端数据很容易被篡改而降低安全性；

Ø 服务器端异步通知

该方式是支付公司服务器后台直接向用户指定的异步通知URL发送参数，采用POST或GET的方式。商户网站接收异部参数的URL对应的程序中，要对支付公司返回的支付结果进行签名验证，成功后进行支付逻辑处理，如验证金额、订单信息是否与发起支付时一致，验证正常则对订单进行状态处理或为用户进行网站内入账等；

分类

1.修改支付价格

支付三步曲——订购、下单、付款 •三个步骤当中的随便一个步骤进行修改价格测试，如果前面两步有验证机制，那么你可在最后一步付款时进行抓包尝试修改金额，如果没有在最后一步做好检验，那么问题就会存在，其修改的金额值你可以尝试小数目或者尝试负数。

2.修改订单数量

很简单，就是本来一笔订单5块钱，可以尝试把订单修改为负数

3.修改附属值(优惠券)

优惠劵主要用来打折或者抵扣现金，一般用优惠劵进行消费一般出现在第二个步骤当中：确认购买信息，在这个步骤页面当中，你可以选择相关优惠劵，然后直接修改金额大于或等于商品的价格就可以，或者直接修改其为负值进行尝试，最后进行支付，如果对这点没有加以验证，那么 问题就会产生，直接支付成功。

4.越权支付

例如：username=XXXXX，如果没有加以验证，其支付也是一次性支付没有要求输入密码什么的机制，那么就可以修改这个用户ID为其它用户ID，达到用其他用户的账号进行支付你的商品；

5.无限制试用

在支付的时候它URL后面的支付接口是3，而试用接口是4，那么此时你已经使用过了，复制下确认试用时的URL，修改后面的支付接口为3，那么此时就会调用购买支付接口，但是由于你本身这个产品就是试用的，其相应值绑定了这个试用商品，那么金额就肯定是0，那么最后点击支付，你就可以看到支付成功，试用成功，又重复试用了一次，然后他们的试用时间会累加在一起，这就导致了可无限制购买任何产品了。

6.修改支付接口

一些网站支持很多种支付，比如自家的支付工具，第三方的支付工具，然后每个支付接口值不一样，如果逻辑设计不当，当我随便选择一个点击支付时进行抓包，然后修改其支付接口为一个不存在的接口，如果没做好不存在接口相关处理，那么此时就会支付成功；

7.多重替换

首先去产生两个订单，这两个订单商品是不一样的，其价格不一样，如果服务端没有做好这相关的验证，那么在支付的过程当中抓包，修改其订单值为另一个订单值，最后支付，这时就可以用订单一的支付价格买到订单而的商品；

防御

Ø 后端检查每一项值，包括支付状态；

Ø 校验价格、数量参数，比如产品数量只能为正整数，并限制购买数量；

Ø 与第三方支付平台检查，实际支付的金额是否与订单金额一致；

Ø 支付参数进行MD5 加密、解密、数字签名及验证，这个可以有效的避免数据修改，重放攻击中的各种问题；

Ø 金额超过阈值，进行人工审核 ；

投票积分抽奖漏洞

投票和抽奖以及积分在很多促销活动或者推广手段上都经常用到，背后的奖品成本可能上数十万，如果这些奖品被恶意用户刷走了，不仅推广的效果没有，而且浪费了成本投入。

不管是投票、积分还是抽奖，都存在一个公共点：即单个用户次数存在限制，比如一场活动中一个用户只能抽奖一次。这样的限制也会存在很多绕过方式。

利用方法

1.cookie和POST请求正文绕过

有的应用将验证是否抽奖或者领取积分的判断值放置在cookie或者POST的请求正文里，服务器端获取到这个结果后判断是否还有机会抽奖，而这个数据我们是可以直接在数据包中修改的，所以就会产生绕过，比如cookie中isok=1代表已经抽奖，isok=0代表还没有抽奖， 而我们只要再点击抽奖，然后把isok的值改为0即可一直抽奖。

2.基于IP验证

做的比较弱的统计是直接基于IP验证，像访问量、推广获取积分等，这类要看程序获取IP的方式，如果是client-ip或者x_forword_for获取IP，则可以直接伪造IP绕过。

3.基于用户认证

也有一部分应用需要登陆以后才能抽奖或者投票，这类可以结合看看能不能批量注册，如果可以，则可以用程序实现批量登陆刷票，或者投票的时候POST包或者cookie里面的当前uid\ 用户名等是否可以随意修改绕过用户单次限制。

防御方法

从上面利用手段可以看到主要的三个点是IP、登录用户和cookie、分析出可用性较高的防御

手段如下：

Ø 机器识别码验证，每台机器都可以根据硬件信息生成唯一的识别码。

Ø 操作需要登陆，当前用户信息从session中读取。