逻辑漏洞常见模块场景
登录模块常见漏洞
弱口令
管理员账号：admin，密码：admin，或者使用万能账号：admin’ or ‘1’=’1（登录的sql注入）
登录密码可爆破
可以通过密码字典，不断请求，爆破出密码
登录验证码可爆破
系统在手机获取验证码的时候，没有对验证码的验证次数进行限制，或者是没有对验证码的有限时间进行限制，就会造成验证码爆破
手机验证码凭证返回
获取验证码的地方抓包，返回的响应包Cookie里面直接返回了验证码。有一些还有在登陆或者密码找回的时候会返回密码。当对一个手机号发送验证码之后，后端会给一个包含验证码的返回包，如果前端hide属性标签的隐藏有验证码，可通过F12查看
短信轰炸
未对发送验证码进行时间限制，导致可进行反复抓包重发验证码请求
验证码绕过
在某些密码找回，或者验证用户凭证的时候，会根据返回的状态码进行校验，假设验证码是正确的，返回的状态码为1，错为2，这里我们就可以通过抓取响应包，修改状态码为1，即可达到验证绕过
cookie伪造
通过修改 Cookie 中的某个参数来实现登录其他用户
-
使用一个账号登录，找一个可以证明身份的页面，例如首页的欢迎 xxx 或者是个人中心显示昵称的地方
-
刷新该页面拦截请求，观察 Cookie 中的字段和值，例如 userid=xxx，修改Cookie中的值，把 xxx 改成 admin
-
forword 放行，页面显示 admin 的信息，则存在此问题
Session会话固定攻击
-
攻击者通过某种手段重置目标用户的 Session id，然后监听用户会话状态 -
目标用户携带攻击者设定的Session id 登录站点 -
攻击者通过 Session id 获得合法会话
登录成功凭证可复用
当使用一个账号登录成功之后，抓取登录成功的请求凭证，再使用其他账号登录，并在登录过程中，利用之前登录成功的凭证，欺骗后端，导致登录成功
未授权访问他人账号
-
可直接修改用户id，平行越权访问其他用户账号
-
请求中的令牌 加密性弱 只使用了简单的url或者base64 只破解其他账号的令牌，通过抓包修改已知账号的令牌换上他人的令牌，即可访问他人的账号
URL跳转（重定向）漏洞
如果url中恶意链接，导致攻击者可向被攻击者发送这样一个网址，如果攻击者点击之后，攻击者将能够盗取被攻击者的信息，恶意软件的安装
注册模块常见漏洞
批量注册
批量注册的前提是：该页面处没有图形验证码或者图形验证码失效
注册页面虽然需要输入姓名和身份证号，但是并未对姓名和身份证号去做核对，输入任意的姓名和身份证号即可。
先用正确的信息注册，记住注册成功时服务器返回的数据，知道注册成功是返回什么，然后使用刚才的数据包遍历修改手机号，账号等参数发送，观察回复的数据包状态
注册覆盖（重复注册他人账号）
对于注册页面覆盖注册是指原来用一个手机号已经注册了账号，但是由于漏洞，导致可以再利用该手机号进行注册，并且会将之前注册的记录覆盖！
当我们用已经注册了的账号准备再注册时，发现会提示该手机号码已经存在！我们抓包，发现后端检测该手机号已经注册了的话，会返回 true。如果检测该手机号没注册的话，会返回false。修改回传参数，达到重复注册目的
短信/邮件轰炸
未对发送验证码进行时间限制，导致可进行反复抓包重发验证码请求
手机验证码凭证返回
获取验证码的地方抓包，返回的响应包Cookie里面直接返回了验证码。有一些还有在登陆或者密码找回的时候会返回密码。当对一个手机号发送验证码之后，后端会给一个包含验证码的返回包，如果前端hide属性标签的隐藏有验证码，可通过F12查看
前端审核绕过
网站他们没有严格进行身份校验，他们往往是通过依靠帐号密码登陆后发送后回传的JSON数据来判断用户身份是否正确，这就暴露出了很大的漏洞，在登录的时候输入正确的账户以及随意的密码，将报文拦截下来，然后选择 burp 里面的拦截返回包的功能，捕捉返回的状态码。
邮箱/手机号注册验证码劫持篡改
为防止恶意用户任意注册账户，大多数网站会在用户注册中输入邮箱/手机号后对其真实性进行验证，但有时候返回的验证码信息会直接隐藏在返回包中，只是不在前端显示出来，或者是可以通过抓包改包手机号/邮箱，伪造该信息，劫持到验证信息
验证码模块常见漏洞
验证码可爆破
服务端未对验证时间、次数作出限制，存在爆破的可能性。验证码常用在批量注册，任意用户登录场景
验证码重复使用
在验证码首次认证成功后没有删除session中的验证码，使得该验证码可被多次成功验证
验证码回显
验证码直接由客户端生成，在回显中显示
验证码未刷新
可复用验证码
验证码绕过
由于逻辑设计缺陷，可绕过验证，比如直接删除COOKIE或验证码参数可绕过、当验证不通过清空session时，验证码参数值为空时绕过等
验证码js绕过
短信验证码验证程序逻辑存在缺陷，业务流程的第一步、第二部、第三步都是放在同一个页面里，验证第一步验证码是通过js来判断的，可以修改验证码在没有获取验证码的情况下可以填写实名信息，并且提交成功
密码找回模块漏洞
短信验证码回传（返回凭证）
1.通过手机找回密码，响应包中包含短信验证码。
2.修改用户名、用户ID或手机号重置任意账号密码
3.通过手机找回密码是一般需要短信验证码验证（这里可以尝试爆破或绕过）。
修改响应包重置任意账号密码
通过手机找回密码一般需要短信验证码验证，服务端需要告诉客户端，输入的验证码是否正确，然后将服务端返回的false信息改为true就可以绕过短信验证码的验证了。
重置密码链接中token值未验证导致任意账号密码重置
使用邮箱重置密码时，服务端向邮箱发送一个重置密码的链接，链接中包含当前用户的身份信息（如用户名或用户ID）和一个随机生成的token信息，如果未对token值进行验证或是验证后不失效，我们就可以通过修改用户名或用户ID来重置任意账号密码。
邮箱弱token
1.时间戳的md5（Unix时间戳）
2.用户名
3.服务器时间
用户凭证有效性
1.短信验证码
2.邮箱token
3.重置密码token
重新绑定
1.手机绑定（绑上自己手机，就可以重置任意人的手机号码了）
2.邮箱绑定
服务器验证
1.服务器验证可控内容（在最后重置密码处跟随一个用户ID，改成其他用户ID，即可把其他用户改成你刚刚设置的密码）
2.服务器验证逻辑为空
用户身份验证
1.账号与手机号码的绑定
2.账号与邮箱账号的绑定
本地验证
1.在本地验证服务器的返回信息，确定是否执行重置密码，但是其返回信息是可控的内容，或者可以得到的内容
2.发送短信等验证信息的动作在本地进行，可以通过修改返回包进行控制
注册覆盖
注册重复的用户名
session覆盖
找回密码到了邮箱验证这一步骤，打开邮箱，不要在邮箱点击重置密码的链接，复制链接在同一浏览器打开
支付模块常见漏洞
商品价格修改
在支付过程中，如果在提交购买信息、确认支付和确认购买的各个步骤中没有适当的验证措施，那么可能存在漏洞，允许潜在的恶意用户修改支付金额或其他关键信息。可以直接抓包，修改支付价格
商品数量修改
抓包尝试修改购买数量，如果购买数量的修改不影响价格，或者如果他们成功将购买数量更改为负数，这可能导致价格显示为负数，从而引发支付问题。
支付金额修改
直接在支付的关键步骤数据包中直接传递需要支付的金额。金额后端没有做校验，传递过程中也没有做签名，导致可以随意篡改金额提交。
修改支付状态
这个问题源于未对支付状态的数值与实际订单支付状态进行有效的验证。这意味着攻击者可以在支付时通过捕获网络数据包并修改支付状态参数的值来欺骗系统，使其错误地认为订单已支付，从而导致虚假的支付成功
优惠劵金额修改
修改优惠券的金额、商品价格、折扣程度。
优惠劵数量修改
直接抓包修改优惠券的数量
积分修改
直接抓包修改积分
运费修改
直接抓包修改运费
购买商品编号篡改
在商品积分兑换系统中，规定了不同积分数量可以兑换不同编号的商品。可以通过编号篡改，用低价购买高价商品
修改支付接口
在某些网站上，用户可以选择多种支付方式。每个支付接口可能具有不同的参数值。如果网站的逻辑设计不恰当，当用户随意选择一种支付方式并在付款时捕获数据包，然后将支付接口更改为不存在的接口，网站未能正确处理不存在接口的情况，这可能导致虚假的支付成功
重放交易
购买成功后，重放请求，进行多次商品的购买
越权支付
通过修改一些特殊传参(如:id) 可以通过其他用户的资金购买自己的商品
多线程并发
在数据库的余额字段更新之前，同时发起多次兑换积分或购买商品请求，达到条件竞争的效果，或许有意外收获
感谢关注公众号🌹
原文始发于微信公众号（青锋云盾）：逻辑漏洞之全面总结
