自己遇到的一些逻辑漏洞

1.验证码类缺陷
    1.1 验证码回显到验证码回显在客户端(响应主体、Set-Cookie等等…)。
    1.2 验证码过于简易时效性过长，没有限制(一般为纯数字4-6位数，时效性较长，就可以尝试爆破)。
2.权限不严谨
    2.1 任意手机号验证码都可重置任意账号。
    2.2 修改响应包的主体(例如验证请求对应的响应报文的主体为false 你可以修改为true,或者是0的话，修改为1)。
    2.3 修改重置密码的相关参数(例如id,user这种参数，算是越权漏洞)。
3.重置链接不安全
    3.1 现在很多重置密码都是发送到邮箱的这种，有时候是根据后面参数来进行重置的，例如：你的:http://qqq.com/id=1，可以试试更换一下重置链接里面的参数http://qqq.com/id=2.就可以重置别人的。  
    3.2 链接里有些经过编码的参数，如果加密简单例如base64，解密一下再进行测试

1.具体看我之前的一篇文章，里面的tips1
    SRC 挖洞tips
2.补充
    2.1 容易识别的图形验证码,我们就可以通过脚本来进行识别验证码
    2.2 图形类的验证码，可复用，刷新过的验证码可继续使用
    2.3 短信类的验证码，一般是四位数到6位数的，要是没有限制尝试次数，可以试试爆破。
    2.4 万能验证码，以前没遇到过，最近有次真遇到了。。000000万能验证码，类似的还有888888，0，666666

1.各种修改参数
    1.1 修改价钱
    1.2 修改数量
    1.3 修改折扣
    1.4 增加折扣参数
    1.5 增加折扣卷参数
    1.6 修改订单号
    1.7 测试负数，测试溢出，用一些临界值进行fuzz。
    1.8 有些类似充值接口的，你冲10.96，其实充了11块 
    1.9 有一些sign参数，进行验证订单的时候，看看sign参数是不是可以自己构造，例如md5(订单号+金额)
    1.10 并发购买，有时候可以用一件的价钱，买两三件

也不知道放在哪个分类里面。。
0.1 领取各种卷的时候进行并发，或者修改里面的数量
0.2 在代码里，像$_REQUEST['id'],可以同时进行get和post的，最后处理的时候只是对post的参数进行验证，所以我们可以切换请求方式来测试。
0.3 不知道测试的时候把值设置为啥，就将参数设置为空或者0。
0.4 有些扫描验证码进行的业务，可以测试一些越权
0.5 有一些业务设置了次数，例如一个账户最多创建一个项目，你可以尝试突破他的限制，然后就是漏洞。。
0.6 有些高权限的业务限制，可以增加参数vip=，等等类似的参数。
0.7 前端验证，抓包进行绕过即可。