前言
目前常规漏洞的挖掘越来越困难，在这种情况下，我们可以多去看看业务逻辑方面的漏洞，也是复杂的系统，越有可能出现这方面的问题。本篇文章就来看看常见的一些场景下都有哪些业务漏洞。
由于本人水平有限，文章中可能会出现一些错误，欢迎各位大佬指正，感激不尽。如果有什么好的想法也欢迎交流，谢谢大家了~~
常见的场景
验证码
验证码可以解决很多业务安全问题，比如撞库、垃圾注册，等等，可谓防御业务风险必备神器。验证码有图片验证码、滑动验证码、短信/邮箱/电话、二维码等分类，而据保守估计起码有80%以上的验证码是存在可以爆破和简单识别的问题，设计一个有效的验证码尤为重要。
常见问题
验证码问题主要分为两类：验证码绕过，验证码资源滥用
验证码绕过：空验证码，万能验证码，验证码可爆破，验证码无效等等
验证码滥用：短信/邮件轰炸，
安全设计
可以从下面几个方面去设计
1）验证码使用一次强制刷新
2）短信或者邮件验证码必须要6位以上字母和数字混合，图片或者语音验证码需要加强混淆干扰，比如图片文字变形，增加干扰斑点等。语音验证码增加背景噪声。
3）验证码要动态生成，不能统一生成多次调用
4）设置验证码错误次数
5）不把验证码放到HTML页面或者Cookie中
6）限制单个手机号在一个时间段内请求接收短信的次数
7）限制某个IP在一个时间段内请求接收短信的次数
用户登录
用户登录是最常见的一个功能，登录就意味着权限授予，如果攻击者能任意登录管理员的账号，也就拥有了管理员的权限，更多的访问权限就能带来更多的安全问题，所以在登录的安全尤为重要。
常见问题
1）任意用户登录（注册）
任意用户登录指的是我们可以通过漏洞登录任意一个账号。能导致任意用户登录的问题如下：
登录验证码可爆破
账号通过验证登录，但是验证码设置比较简单并且可以爆破，此时我们可以通过暴力破解的方式登录任意账号。
验证码明文返回
登录验证码在数据包中被返回
存在万能验证码
在js等文件中可以找到通用的登录凭证；一般是测试为了功能测试方便，设置了诸如000000，123456（六位验证码爆破能发现）之类的万能验证码，项目上线时忘记下掉，导致任意用户登录
验证码未绑定用户
a.后端仅验证了验证码是否正确，没有验证验证码与获取手机号的对应关系，导致可以先输入自己的手机号A获取验证码，再输入他人手机号B获取验证码后，填写自己手机号A接收到的验证码，达到登录手机号B的目的
b.后端仅验证码了手机号与验证码是否一致，并未校验手机号是否为号主本人的,导致可以使用自己的手机号+验证码绕过。常见于用户绑定的功能处。
获取验证码的手机号字段可双写
输入自己的手机号抓包，将手机字段后面加一个逗号或者分号后再加一个手机号，或者双写手机号字段phone=13333333333&phone=18888888888，当两个手机号均收到一个验证码时大概率漏洞存在。使用自己的手机号便可以任意登录其他手机号
验证码为空/任意验证码可成功验证
验证码为空时，手机号正确则成功登录（账号密码登录体系也发现过这种情况，空密码的情况下账号存在即登录）
凭证泄露
当登录凭证泄露的时候也可以导致可以登录任意用户，泄露用户凭证的途径如下：
凭证可伪造
登录凭证如果比较简单，我们可以通过伪造凭证登录任意账号
多步登录时改变其它步的参数
以两步登录为例，登录输入账号密码/手机号验证码/其他的凭证信息后第一个请求校验其正确性后，第二个请求根据后端返回的账号/手机号/用户id等字段去获取用户凭证的登录逻辑。
只要修改第一个请求中的返回包或者修改第二个请求中的字段即可
更改登录Type
部分系统有免密登录/快捷登录之类的功能，只要一个账号就能登录，当遇到登录数据包中含有type之类的字段时，可以尝试此方法
账号数据覆盖
常见于用账号信息更新处，例如修改手机号、账户重新绑定功能、修改账号等功能点处
修改请求中的oldmobile字段为其他手机号，成功将其他用户的账户数据覆盖到新手机号中，达到任意用户登录。
2)登录无验证码防护
登录无验证码防护时，可以暴力破解用户名和密码
3）撞库
没有限制时间段内IP登录错误次数。
4）API无凭证登录
API登录时没有带上唯一的token，只提供了有用户ID。如下以前爆出的一个漏洞
安全设计
可以从下面的几个方面去设计安全的登录
1）用户名密码加密传输
2）登录验证码不可预测
3）多步登录之间验证上一步的结果
4）验证码要与用户绑定
5）不允许注册已存在的用户
6）登录失败次数限制
7）登录失败次数限制
用户注册
用户注册的漏洞其实很多跟登录时差不多，有下面的几个，这里就不在多做介绍
安全设计
1）设计验证码。
2）采集用户机器唯一识别码，拦截短时间内多次注册。
3）根据账号格式自学习识别垃圾账号。
密码找回场景
密码找回是出现逻辑问题最多的一个功能，因为它的交互流程最多，目前找回密码的方式比较常见的有邮箱验证码、手机验证码以及密保问题
常见问题
很多的利用跟用户注册也是相同的，要注意重置链接的安全性以及不可预测，同时要绑定用户
安全设计
1）接收验证码的邮箱和手机号不可由用户控制，应该直接从数据库中读取出来。
2）加强验证凭证复杂度，防止被暴力破解。
3）限制验证凭证错误次数，单个用户在半个小时内验证码错误三次，半小时内禁止找回密码。
4）验证凭证设置失效时间。
5）验证凭证不要保存在页面。
6）输入用户邮箱或ID、手机号取验证凭证的地方需要设置验证码防止短信轰炸和批量找回等。
7）验证凭证跟用户名、用户ID、用户邮箱绑定，找回密码时验证当前凭证是否是当前用户的。
支付场景
曾经有不少体量不小的电子商务网站都出现过支付漏洞，最终导致的结果是不花钱或者花很少的钱买更多的东西，还真的有不少人测试漏洞之后真的收到了东西，这种天上掉馅饼的漏洞太有诱惑力了。
常见问题
这里介绍几个常见的漏洞
1）修改支付金额/修改购买数量
通过修改数据包中的总价或者购买数量，达到零元购或者一份的价钱购买多个商品的目的。
2）条件竞争
并发购买，简单来说就是在购买一个物品的时候，抓支付操作的包，然后再高并发下实现多次购买，就有可能造成，只支付一次，可能购买了多次
3）用户/订单/优惠券等ID生成有规律，可枚举
这些ID可以猜测时，就可以改变ID使用别人的优惠券以及操作别人的订单等操作
安全设计
1）保证数据可信，商品单价及总价不可从客户端获取。
2）购买数量不能小于等于0。
3）账户支付锁定机制，当一个支付操作开始就应该立马锁定当前账户，不能同时两个后端请求对余额进行操作。
私信及反馈
私信和反馈功能在大多数网站中都能见到，特别是社交应用，私信是必不可少的功能。这个功能是两个用户之间互动使用，两端都是人，除了特殊情况下可以滤去的SQL注入或者命令执行等少见漏洞外，最常见的就是XSS漏洞以及越权漏洞。
安全设计
1）对用户提交的内容的特色字符要做转义
2）注意权限问题
投票/积分/抽奖
投票和抽奖以及积分在很多促销活动或者推广手段上都经常用到，背后的奖品成本可能上数十万，如果这些奖品被恶意用户（黄牛）刷走了，不仅推广的效果没有，而且浪费了成本投入
常见问题
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、用户名等是否可以随意修改绕过用户单次限制。
安全设计
机器识别码验证，每台机器都可以根据硬件信息生成唯一的识别码。
操作需要登录，当前用户信息从session中读取。
总结
本篇文章介绍了一些常见的业务漏洞，当我们遇到这些场景时，要注意上面的这些问题。常规漏洞越来越不好挖掘的情况下，我们可以多去看看业务方面的漏洞。
4A评测 - 免责申明
本站提供的一切软件、教程和内容信息仅限用于学习和研究目的。
不得将上述内容用于商业或者非法用途，否则一切后果请用户自负。
本站信息来自网络，版权争议与本站无关。您必须在下载后的24个小时之内，从您的电脑或手机中彻底删除上述内容。
如果您喜欢该程序，请支持正版，购买注册，得到更好的正版服务。如有侵权请邮件与我们联系处理。敬请谅解！
程序来源网络，不确保不包含木马病毒等危险内容，请在确保安全的情况下或使用虚拟机使用。
侵权违规投诉邮箱：4ablog168#gmail.com（#换成@）
