web安全-逻辑漏洞梳理与总结（详细介绍）

1. 任意密码修改漏洞

1.1 验证码可爆破

1.表现:验证码四位，服务端未对验证时间次数进行限制(出现次数比较多的地方)

2.表现:验证码六位，但是不过期，并且没有对验证的次数进行限制

3.表现:验证码可以发送多次，而且每次都不会过期

利用:使用burp的爆破模块即可，或者自己编写脚本

修复:使用六位验证码，限制验证码认证次数

特例:对ip进行了验证次数的限制，利用ip轮换进行爆破

1.2 验证码凭证回传

验证凭证回传:重置密码时，凭证为发送到手机上的验证码，但是通过拦截发送验证码请求对应的Response包时，发现验证码在Response包中

重点:注意是凭证，有时候可能返回包里面凭证可能在cookie里面或者也有可能在其他地方

特例:dedecms任意密码重置

解决方案:修改包的返回规则

1.3 验证码未绑定用户

输入手机号和验证码进行重置密码的时候，仅对验证码是否正确进行了判断，未对该验证码是否与手机号匹配做验证。

表现:任意账号都能够接收到验证码并能够使用A手机的验证码，B可以拿来用

修复:

1.在服务器进行有效验证，手机号和验证码在服务器进行唯一性绑定验证。

2.在服务端限制验证码发送周期，设置时效，限制次数

1.4 本地验证绕过

原理：关键校验逻辑放在客户端（如JS校验验证码），攻击者篡改本地代码绕过校验。

危害：直接跳过验证步骤修改密码。

防御：关键逻辑需服务端校验，客户端仅做辅助验证。

1.5 跳过验证码步骤

成因:对修改密码的步骤，没有做校验，导致可以输入最终修改密码的网址，直接跳转到该页面，然后输入新密码达到重置密码的目的。

测试:首先使用自己的账号走一次流程，获取每个步骤的页面链接，然后记录输入新密码的对应链接。重置他人用户时，获取验证码后，直接进入输入新密码对应链接到新密码的界面，输入密码重置成功

1.6 Token可预测

token可预测:使用邮件接受重置密码的链接时，一般都会带有一个token用于判断链接是否被修改过。如果token可以预测，那么攻击者可以通过构造链接来重置任意的用户密码。

表现:

1.基于时间戳生成的Token

2.基于递增序号生成的token

3.基于关键字段生成的token

4.token有规律

1.7 同时向多个账户发送凭证

同时向多个账户发送凭证:将发送验证码的包截获，修改字段添加多个账户，再发包。

发现所写的有效字段均发送了凭证。

1.8 接收端可篡改

接收端可篡改:重置密码时，凭证会发送到手机上，通过替换手机号，可以使用自己的手机号接受验证码。

还有一种情况比较特殊，也是手机接受验证码，但是重置密码的整个流程中并没有输入过手机号之类的，说明后台程序很可能是通过用户名来查询的电话号码。

整个重置流程中，一般第一步是绑定用户名的地方，但是如果后面几个流程中还会发送用户名这个参数(这个时候发送的参数可能是单独用于在数据库中查询手机号的，同时说明这个地方可能存在sql注入)，可以修改尝试一下。

1.9 万能验证码

万能验证码：这是可遇不可求的奇葩场景，某些开发在未上线前为了方便测试加了888888、000000这样的万能验证码但是上线后没去删除测试的内容导致被恶意利用。

2. 任意用户登录漏洞

原理：身份认证逻辑缺陷，如：

• 登录接口未验证用户权限，输入任意账号+密码即可登录。

• Session伪造或Token未绑定用户身份。

危害：直接登录他人账户，窃取数据或权限。

防御：强制身份认证（如密码、多因素认证）、校验Session与用户绑定关系。

3. 短信轰炸漏洞

原理：短信接口无限调用，无频率限制或人机校验（如验证码）。

危害：攻击者利用脚本频繁发送短信，骚扰用户或消耗企业资源。

防御：限制单手机号/IP的发送频率（如1次/分钟）、增加图形验证码。

简单bypass思路

1.尝试在moblie参数后面加%20即空格

2.尝试在mobile后面加字母等

3.尝试对参数进行多次叠加

4.利用调用接口绕过短信&邮箱轰炸限制

5.修改Cookie值绕过短信&邮箱轰炸限制

6.修改IP绕过短信&邮箱轰炸限制

7.利用大小写绕过邮箱轰炸限制

8.修改返回值绕过短信&邮箱轰炸限制

4. URL跳转漏洞

原理：未校验跳转目标域名，攻击者构造恶意链接（如https://victim.com/redirect?url=evil.com）。

危害：钓鱼攻击，诱导用户访问恶意网站。

防御：限制跳转域名白名单、拒绝用户可控跳转参数。

url跳转有时候会做一些限制绕过bypass

5. 越权漏洞

类型：

• 水平越权：访问同权限其他用户的数据（如修改URL中的用户ID查看他人订单）。

• 垂直越权：低权限用户执行高权限操作（如普通用户调用管理员接口）。

防御：服务端校验用户权限、资源归属，避免依赖前端参数。

6. 支付逻辑漏洞

1.修改购买数量

在进行支付订单的时候，可以修改物品的数量来进行操作，可以通过支付件的价格购买多件，或者修改成负数进行增加资金

2.修改支付价格

利用:抓包修改价格参数的内容，在支付当中，购买商品一般分为三步骤:订购、确认信息、付款，在这三个步骤中都有可能存在漏洞金额可以尝试修改小额或者修改负数

3.修改支付对应的商品

通过修改商品对应的id号，可以用低价购买高价格的商品

4.修改支付的状态

没有对支付状态的值跟实际订单支付状态进行校验，导致点击支付时抓包修改决定支付或未支付的参数为支付状态的值从而达到支付成功。

5.修改附属优惠/状态

1.修改优惠券金额

2.修改积分金额

3.无限制试用

4.修改优惠价

比如一些商品有优惠价，优惠多少多少，那么在支付时抓包，修改这个优惠价就可造成支付问题的产生

6.测试数据包未删除

开发在进行测试的时候有一些测试数据未删除，导致用户可以购买测试数据，或者领取测试的优惠券

其他类型

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

重复支付:类似试用卷，你试用完成或者主动取消试用时，试用卷会返回到账户当中

最大额支付:在设置的时候，商城的支付金额有上限，当输入9999999999999类似的一个超大数的时候，可能会存在溢出，或者直接变为0

条件竞争:同时发包获取优惠卷等，可以绕过限制的次数

7. 条件竞争漏洞

原理：并发请求触发非原子操作（如余额校验与扣款非原子性），导致逻辑错误。

案例：同时发起多次充值请求，绕过余额不足限制。

防御：使用数据库事务、锁机制、分布式锁确保操作原子性。