逻辑漏洞（精讲）

1. 逻辑漏洞基础

1.1 逻辑漏洞介绍

逻辑漏洞就是基于开发⼈员设计程序的时候，逻辑不严谨，导致攻击者可以修改、绕过或者中断整个程序，让程序按照开发⼈员的预料之外去执⾏。

2. 类型

2.1 身份验证漏洞

2.1.1 未限制爆破

使用场景：在用户登录的时候，没有对用户身份等进行再次验证，只有对登录用户名和密码进行验证，没有第三方例如图片验证码、手机短信验证码等的验证

破解策略：首先对用户名爆破，获取到一个用户之后，其次对该用户的密码进行爆破，这是较为常见的常见，使用到的工具是burpsuite

2.1.2 限制ip爆破

使用场景:在防护措施中，有一条策略是，在短时间内有来次某条ip的大量访问，尝试进行登录，会被识别是攻击行为，会对ip进行封锁，导致该ip不能使用

破解策略:使用ip代理池，写个脚本，调用git(分布式控制系统)开源的代理接口，利用不同的ip对其访问.

2.1.3 限制密码错误爆破

场景：在有些登录页面，我们太久忘记登录忘记密码了，输入几次密码错误之后，会提示还有几次登录尝试，这是因为，后台管理对于安全考虑，会限制账号的登录次数，如果超出限制次数，账号会被锁定，需要管理员解封或者过一定时间才会解锁

破解策略：这种限制只是对一个账号的限制，只对一个账户进行登录次数的限制，我们可以换个账号进行爆破，返回使用弱口令反过来爆破账户方式。只要账户足够多，总存在弱口令的账户。使用工具也是burpsuite

2.1.4 多字段爆破

场景：有些网址在验证身份时候，不止需要验证账号与密码，还有其他的参数，例如token，这因为后台用于验证身份时候，不仅仅是对账号秘密验证，还加上了一层验证，常见的例如token，token的值是根据你的身份信息、摘要身份信息等生成的身份验证码，token是唯一的，经过加密了，是有时效的，使用一次之后，就失效。

破解策略：burpsuite的Intruder模块

2.1.5 限制登录次数频率爆破

场景：在登录时候，在一定时间内，不管密码正确还是不正确，都会对登录次数进行限制，例如10分钟之内，只允许登录10次，不然就对账户进行封锁。

策略：可以采用延时爆破的方法，在burpsuite中可以设置爆破的时间

2.1.6 session固定攻击

场景：session常用在结束后，当我们在一个页面中登录完之后，不管是关闭网站，还是进入网站的其他页面，都是还是识别登录状态，这就是session的功能。当用户在访问服务器时，服务器会为该用户创建一个Session，并分配一个唯一的Session ID，在后续的请求中，服务器可以根据这个Session ID来识别客户端。

破解：在请求登录时候，url会带有一个session,登录成功之后会将登录成功的信息绑定到这 个session中，可以发送带有session的URL给相关工作人员诱导其登录，相当于获取了其身份信息

2.1.7 cookie欺骗漏洞

场景：cookie和session一样，都是用来识别用户信息的，不同的是cookie是存储在客户端（用户），而session是存储在服务器中，

策略：cookie的值只是简单编码，进行抓包获取到cookie值之后，修改lsLogin值为1可以判定为用户已经登录

2.2 验证码方面的漏洞

2.2.1 验证码复用

场景：在登录的时候，还需要另一侧验证，例如短信验证，图片验证，这里的验证码复用，是指在登录失败的时候，任然可以使用上一次的验证码

策略：通过brupsuite抓包，输入对的验证码后，反复发送查看回包，如果没有改变，就是该漏洞，这时候有跟没有验证码都一样

2.2.2 验证码绕过

场景：在设计验证的时候，有一种是把验证码传入后端之后，后端会返回一个状态码，告诉前端是否是通过

策略：利用bp，进行抓包，然后发到重发器中，对状态码的值进行修改，有些网址的正确状态码是y或者yes

2.2.3 客户端验证码

场景：验证码是前端编写，参数没有传入后端进行验证，可以查看代码，看看登录按钮没有js方法，如果看到验证是通过前端验证，就可以确定。或者写入错误的验证码，通过bp抓包，如果抓不到包，而且是弹出错误，就是前端验证

策略：随便输入账号和密码，第一次输入正确的验证码，之后利用bp对其抓包，把包放入重发器中，可以发现，不管怎么更改验证码，甚至删除验证码，都是报用户和密码方面的错误

2.3 忘记密码

2.3.1 验证次数不限制

场景：忘记密码几乎是所有的网址都存在的功能，当用户忘记自己密码时候，选择忘记密码找回密码，一般是通过手机短信验证，或者邮箱验证。用户输入验证码之后，服务器会将正确的验证码与其对对比，正确就进入下一个操作，如果错误就再次进行操作

2.3.2 前端绕过验证

场景：在验证过程中，服务器可能是返回正确的验证码，然后跟输入的验证码进行匹配

策略：可以按F12进入开发者模式，监听jsom数据（这是响应信息），一般传输的数据加密方法是base64算法，可以对其解密，这样就可以直接获得正确的验证码，进行绕过。

2.3.3 设置新密码时候更改其他人密码

场景：在通过验证号码之后一些列正确操作之后，最后一步是更改密码，这里也存在漏洞，如果在最开始的时候利用bp进行抓包，而且在输入正确的信息，到了最后一步，进行输入新密码。在此时，在bp的数据包中，把用户名更换成其他已经存在的用户，看看会不会通过。因为我们之前输入正确的信息，得到了正确的数据包，在最后一步输入新的密码，如果不再进行二次验证，是可以通过的。也就是可以更改其他人的密码

2.3.4 服务器端存在的漏洞

场景：在重置密码的时候，可能是有用户名这选项的，只不过是灰色，是不能修改的。这不能修改的功能是通过前端的js实现。

漏洞：如果用户点修修改之后，用bp对其抓包，发现在处输数据的参数中，有用户名字段，而且还没有二次验证，那么把抓到的包，利用重发器修改用户名字段，改成其他的用户，进行发送，就会照成随意对其他用户密码进行修改。

2.4 注册区域

2.4.1 注册未验证

场景：在有些网址上，在注册用户的时候，是没有通过邮箱，或者手机号验证身份这一功能

漏洞：如果利用bp、脚本等工具，就行大批量注册，一直注册，不断的给数据库存储信息，会照成注册轰炸，数据库可能会存储内存不足，从而崩溃，这也属于dos应用层攻击

2.4.2 个人信息伪造

场景：在注册的时候，对身份证等信息进行错误填写，随意的不按照规则输入，尝试进行注册，看是错误的信息是否出现注册成功的情况。

漏洞:如果伪造的信息能够注册成功，那么对注册进行绕过

2.4.3 前端验证审核绕过

场景：在注册信息验证这一功能业务，是在服务器实现的，有可能服务器的响应是发送一些状态码给前端，前端通过状态码进行判断是否同意注册。

漏洞：对其抓包，修改状态码，就可以对其绕过。

2.4 权限类

水平越权：权限是同级别的，但是是给不同的对象使用。例如：一般不同的用户只有对自己信息修改的权限，如果出现用户A能对用户B的信息进行修改，这就是水平越权

垂直越权：从低权限到高权限的翻越。例如普通用户到了超级用户

交叉越权：水平越权与垂直越权的集合

2.5 其他类型

2.5.1 条件竞争

场景：两个或多个并发进程按照不同的顺序访问共享资源，从而导致不可预见的行为或错误。例如，当两个线程尝试同时写入同一个文件时，如果它们没有正确地同步，可能会导致文件的内容出现不一致的情况

2.5.2 订单金额任意修改

场景：在一些中小型的的购物网站，可能存在这个漏洞，在电商系统或支付系统中，支付的金额是前端编写，在提交的时候抓包，抓到的数据包可能可以进行随意更改

2.5.3 接口无限制枚举

场景：在扫描一个api端口时候，不断的尝试爆破猜测猜出资源，这是没有对验证或者防护带来的结果

2.5.4 支付漏洞

场景：在支付时候，通过抓包，修改篡改价格、数量、状态、接口、用户名等参数，使得小钱购买到商品，甚至是0元购买商品，这样的漏洞就是支付漏洞

2.5.5 越权支付

场景：例如用他人的钱支付自己的东西，这就是一直越权支付，在支付的时候，修改特殊的参数，例如id、用户名等