记一次项目测试挖掘思路

0x01 突破条件竞争

在项目过程中，客户需要测试一个拉新功能，该功能流程为：用户分享邀请给新用户—>新用户点击链接填写并提交信息—>系统判断是否为新用户—>若是新用户则返回app下载链接—>新用户登录app—>app请求服务器发送新人奖励—>系统返回新人奖励—>系统将奖励次数减为零。

在点击他人分享的邀请链接后需要填入自己手机号等信息，在提交信息以后，服务端会先判断是否为新用户 ，若为新用户，页面会直接返回”请下载app领取奖励“，若不是新用户，则提示该账户已在本app注册。登录app时，app会自主向服务器发送一个新用户请求奖励的数据包，系统收到请求后返回用户奖励并扣除奖励次数。

奖励成功时的返回包

奖励成功再次提交就会返回重复提交

该逻辑在非并发情况下是没有问题的，但若短时间内用户发送多次请求奖励的数据包，系统就会在返回完用户奖励后，还没来得急修改奖励次数就处理下一次请求而导致返回用户多次奖励，引发条件竞争。在此次测试过程中，也是在几千次数据包中成功了四次，也就是奖励了四次。

一般抽奖，领奖，提现，充值等与次数有关的地方都值得测一下。

任意密码重置常见的思路是：输入手机号/账号—>获取验证码—>判断验证码是否正确—>验证码正确—>输入新密码—>重置成功

这种思路问题一般出现在最后一步，在最后提交新密码时系统可能会不做任何判断直接进行修改，若次数抓取数据包，将自己的账号/手机号修改为他人手机号/账号，然后重放就可以任意重置他人密码。

在测试过程中遇到了一个跳过验证步骤的任意密码重置，该逻辑与上面一样，也是输入验证码，如果验证码正确则允许输入新密码进行重置，但不同的是，它的验证码可以绕过。先正常流程走一遍，并记录验证码正确时的返回包。然后重新他人手机号获取验证码，这时我不需要知道正确的验证码，输入验证码时随便输入错误的即可，然后抓取其返回包并修改为刚才记录过的正确的返回包并且发包，页面就会跳到重置密码的界面，输入新密码就可以重置成功。该漏洞造成的原因是对修改密码的步骤，没有做严格校验，导致用户可以绕过验证码的验证去重置密码。

修改前

修改后

一次客户再让测试一个社交app时，同事圈/朋友圈图片转发可控的漏洞，具体场景为在转发朋友圈/同事圈时，朋友圈图片地址在请求包中泄露了出来

将其引用的图片地址修改为自己想引用的，然后转发到群或朋友圈时，图片已修改为自己想引用的了

修改前

修改后

像这种可以控制图片url的时候，可以直接将url改为www.baidu.com/#.jpg,然后可以点击改图片或朋友圈的时候，可以尝试看下是否会跳转到其他页面。

这是在测试一个公众号时发现的一个漏洞，在聊天软件中，我们聊天时都会建立一个会话id

此id只有聊天的两个人能用，我们发消息时，会话id会随着消息一起发送，正因为这个会话id的限制，只有聊天的两个人能看到这个消息，简单来说这个会话id就是用于区别不同的聊天窗口。

在测试时发现，用户A给用户B发消息，此时会建立一个会话id=1，然后用户B关注了一个公众号C，此时也会建立一个会话id=2，之后A发送消息给B，数据包中的参数为id=1然后加上发送的内容，当我们将id直接修改为2的时候，就可以恶意闯入用户B与公众号C的会话，会发现A用户会冒充公众号C给用户B发送了你想要发送的内容。

一般人脸识别功能会出现在修改限定金额，支付，签约等地方。

大致流程为：输入金额进行交易—>输入密码—>人脸识别—>发送交易数据包

在测试过程中遇到过大致两种情况，一种是直接修改返回包0和1，这种比较常见，在人脸识别过程中，会发送人脸信息给服务器—>服务器判断该人脸信息—>若是本人则返回正确数据包/若不是本人则返回错误数据包，假设正确数据包中返回的是1，错误数据包中返回的是0，我们也可以正常走一遍流程，记录正确返回包方便后续的修改，系统收到返回的数据包从而判断是否要跳转到下一个界面，或是否发送交易数据包。这时我们把返回包中的0修改为1就可以绕过。

修改前

修改后

另一种是正常人脸识别，然后抓取支付包，尝试把支付包重放，如果可以重放，说明人脸识别可以绕过，因为人脸应该在支付时校验人脸，但是可以重放支付包的情况，说明服务端没有调取刚才是否经过人脸的数据，导致支付时没有和人脸做联动，所以导致的该问题。

之前的图没有了，找张重放的图冒充一下

在测试金融行业的情况下，非常建议测试下身份证时间校验，因为在很多场景情况下，比如借款，贷款这种场景下，这种情况下，如果拍取的身份证时间已经过期了，则不允许通过，金融行业如果遇到这种场景，尽可能的注意下这个测试点。

在测试的过程中遇到过一个这样的情况，在网站的搜索框中点击搜索，如果没有填入任何信息系统会提示搜索条件不能为空，但是这个限制只是前端限制，我们抓取数据包，将搜索字段参数制空，则系统将返回该表中所有数据，这是一个典型的sql语句没有处理好的问题，它的语句应为select * from table where keyword like '%$keyword%'，当我们传入的参数$keywork为空时，like '%%'就会匹配该表中所有数据。

当然了，思路不要局限于一处，比如条件竞争，在这次拉新功能的测试项目中，本来没想到条件竞争的，最后报着侥幸的心理去试了一下，没想到真的有，所以在测试过程中，不要在思想上判定为不存在的漏洞就判定为这个功能点就没有，一定要动手去测试一下，不要只凭想象去判定这个功能点该有的漏洞。而且比如这次测试及时通讯软件，比如qq，微信，以及其他公司开发的聊天软件，存在的问题可能会很多，比如你越权查看他人群聊天记录，查看他们群上传的文件或者公告，尝试以平台用户权限去顶掉管理员权限，越权删除他人朋友圈（同事圈），所以在测试的过程中，觉得有漏洞的地方尽管去试，当然一定要在授权的情况下。