一.用户凭证暴力破解
比如说要修改密码的时候，我们通过发送短信验证码来进行身份验证，然后就可以看看这个验证码是否可以进行暴力破解，如果他只是4位数字这种很容易就爆破的，直接上burpsuite就可以搞了。
相关的例子：
http://www.anquan.us/static/bugs/wooyun-2012-011833.html(这个是当当网的例子，他没有处理请求次数过多时进行屏蔽)
https://bugs.shuimugan.com/bug/view?bug_no=11720（这个是微信的例子，他对爆破次数进行了限制，但是限制的时候是按手机号码来认的，所以手机号加了点特殊字符以后就绕过爆破次数限制了，然后真正验证验证码的时候再进行手机号码提存，结合验证码进行验证），这样的话就直接绕过限制，利用四位数的验证码进行密码修改。
在这里我整理一下验证码绕过的思路: 1.试试万能验证码 2.试试直接去掉验证码是否能成功 3.试试怎样绕过验证码的限制，直接爆破验证码，这一部分我觉得可以学习一下那个微信的例子，爆破的时候有可能会遇到长度以及相应包完全相同的，可以先比较成功与失败的响应不同之处，定义各自的标志。
二.返回凭证
1.URL返回验证码以及token，主要是短信验证码直接从URL中返回了，直接看URL就可以看到了。
进阶的情况是验证码加密之后返回在返回包里面，然后可以探查邮箱里面重置密码邮件里面的验证码是否包含在返回包里面返回的内容里面，是的话就直接可以绕过验证码限制了，这一点主要看第二个例子。
相关例子：
https://bugs.shuimugan.com/bug/view?bug_no=5630
https://bugs.shuimugan.com/bug/view?bug_no=58210
2.密码找回凭证在页面中
这种漏洞的意思是密码找回的时候，使用验证码或者其他的密码找回问题等等方式来验证漏洞的时候，我们可以查看页面源代码来进行寻找，看看会不会有密码找回凭证直接就出现在页面源代码里面，例如密码找回问题答案就直接在源代码中等。
相关例子：https://bugs.shuimugan.com/bug/view?bug_no=4728
3.返回短信验证码
主要是把短信验证码放在返回包里面返回给客户端，然后可能就做了加密，只要你把可以字符串解密了就可以看到返回的短信验证码。
相关例子：https://bugs.shuimugan.com/bug/view?bug_no=85124
在这里我整理一下验证码返回测试的思路：先看url有没有直接返回，再看页面源代码里面也可能有，接着是返回报文里面也看下，然后有可能出现加密的情况，可以试着解密看看，如果解不出来就试试与邮箱里面的验证码进行对比，如果有相同的那就可能那串加密字符串就是验证码。
三.邮箱弱token
1.时间戳的md5
360在设置密码找回时，是通过对邮箱名以及时间戳的验证来验证用户身份的，这样带来一个情况就是如果时间戳是最近生成的话，就可以通过生成时间戳暴力破解的方式来重置用户密码。
相关例子：https://bugs.shuimugan.com/bug/view?bug_no=8333
2.服务器时间
厂商返回的邮箱充值密码连接主要是返回邮箱和验证token，如果他的token是用服务器时间来设置的，那么同一时间两个不同账号返回的token应该很接近，所以我们通过遍历这个token来修改别人的账号密码（获取别人的账号往往可以通过注册界面来获取，就是注册过的邮箱会显示已注册）
相关例子：https://bugs.shuimugan.com/bug/view?bug_no=90226
这个主要是服务端对用户身份和修改账号之间的关系做了验证，但是这种验证采用的token存在缺陷，导致这个token可以被预测出来，从而导致逻辑漏洞出现。
四：用户凭证的有效性（本质上就是拿着有效的验证码去修改别人的账号密码）
1.短信验证码
这个思路是这样的，服务端只是验证了用户凭证是否是真的，但是没有验证用户凭证是否是要修改密码的那个用户，还是那句话，不仅要验证用户身份，还要对用户身份以及修改账号之间的关系做一个强有力的验证才行，谈回这个例子，该白帽子是这样做的，先是用自己的手机账号找回密码，收了一个验证码，接着用别人的手机号找回，然后验证码那里输入自己前面收到的手机验证码，直接就绕过了。多说无益，直接看例子（这道题的思路是真的牛逼！）
相关例子：https://bugs.shuimugan.com/bug/view?bug_no=53349（这道题的哥们在中途更改了手机号码结果反而修改了原号码，是真的强）
第二个例子是注册完一个账号以后，直接用刚注册的账号给找回密码，然后收验证码后利用该账号找回密码截获请求包，然后直接修改别的用户名，就把修改完的用户名直接给重置密码了，还是那句话，多说无益，直接上链接。这道题目和第一题是一样的思路，没啥差别。
相关例子：https://bugs.shuimugan.com/bug/view?bug_no=20032（没错还是oppo......我还记得人生第一个挖的sql injection是vivo 家的）
2.邮箱token
这个主要是说有些邮箱设置的token就是吓唬人了，其实根本就没啥用，白帽子在找回密码界面输入新密码，然后直接使用brup来抓包，接着虽然他有设置token，但是这个token其实没啥卵用，然后直接修改uid就可以重置别人的账号密码了。话不多说，直接上例子。
相关例子：
https://bugs.shuimugan.com/bug/view?bug_no=12572
3.重置密码token
这个主要是在讲服务器在重置密码的时候验证了用户的身份（通过cookie）,但是没有验证用户要修改的邮箱是否是对应这个用户身份（也就是说用户邮箱与用户身份account未绑定认证）,从而导致在验证身份后，直接替换cookie就可以重置密码了。（简单点直接点说吧，就是先获取自己找回密码时的令牌token,是cookie里面的一部分，然后最后修改密码的时候贴上自己的cookie，邮箱却修改为自己的，账号为别人的，然后就通过验证了），直接上例子。
相关例子：
https://bugs.shuimugan.com/bug/view?bug_no=78208
这个主要是在讲用户凭证的有效性出问题，首先要验证用户是否是合法的用户，其次是要对修改的账户和用户凭证之间做绑定，使用强token来绑定，你的token应该要具有不可预测性，这样就可以防住这种攻击。
五.重新绑定
1.手机绑定
主要是在绑定手机时，服务端只用了uid来标识用户，并未使用cookie或者session来进行验证用户身份，导致了修改了uid以后就可以直接用自己可控的手机号来绑定别人的账号，这样就可以美滋滋地修改密码了，话不多说上url。
相关例子：https://bugs.shuimugan.com/bug/view?bug_no=08307
2.邮箱绑定
这个主要是在说服务器其实不是按照username来作为账号标识地，而是用了邮箱作为绑定邮箱作为账号标识，而我们在获取了修改密码的连接以后，保持绑定邮箱不改，然后修改uid，直接就把uid对应的绑定邮箱给改了。
相关例子：https://bugs.shuimugan.com/bug/view?bug_no=92319
我觉得四五本质上都是一样的道理，就是用户凭证有效性验证出问题。
六.服务器验证
1.最终提交步骤
又是服务器未对用户身份进行验证，使用uid这种自定义的参数来进行身份辨别，所以出了问题，请看链接。
相关例子：https://bugs.shuimugan.com/bug/view?bug_no=18263（这个例子和第五是一样思路）
2.服务器验证可控内容
修改密码的时候只对自定义字段进行验证，而未对用户身份进行认证匹配，所以出现问题。
相关例子：https://bugs.shuimugan.com/bug/view?bug_no=80278（这种本质上来说算是弱token）
3.服务器验证逻辑为空
就是说设置了验证逻辑，但是去掉这些逻辑以后就直接通过验证了，和之前学的去掉验证码是一样的道理，所以相关例子为：https://bugs.shuimugan.com/bug/view?bug_no=88927(这种和前面空摆设token是一样的)
这个主要是弱token的一些拓展把，有时候token不一定是显是出现的，有可能是通过某些逻辑，例如第二个。
七.用户身份验证
1.账户与手机号码的绑定
这道题目是上海电信的，还是差不多，主要是充值密码的时候改了uid（本例中是修改了手机号），然后就重置了别人的号码，大概如此。
相关例子：https://bugs.shuimugan.com/bug/view?bug_no=75941
2.账号与邮箱地址的绑定
修改密码的时候做了先用别人的邮箱来申请，接着拦截请求修改为自己的邮箱，然后在自己邮箱接收验证码就可以了，大致如此。
相关例子：https://bugs.shuimugan.com/bug/view?bug_no=91216
同四五
八.找回步骤
跳过找回步骤，只能说这个思路是真他妈骚，直接找一个存在的账户名，然后直接访问设置新密码页面（跳过选择方式找回这一步骤，也就是说他是跨步骤重置密码），直接就重置密码了，这思路真他妈也行！！！
相关链接：https://bugs.shuimugan.com/bug/view?bug_no=42404
这个的思路也是很骚的，主要强调了找回步骤跨越这一操作，开阔新思路。
九.本地验证
1.服务器返回的信息是可控的信息，这个信息告诉了浏览器是否通过漏洞验证，然后我们控制返回报文的信息就绕过了验证。(也就是说他的验证其实是在本地进行验证，而不是服务器端进行验证，这样的话就可以直接绕过验证了，毕竟本地端都是可控的)
相关例子：https://bugs.shuimugan.com/bug/view?bug_no=69987
https://bugs.shuimugan.com/bug/view?bug_no=83035（这个例子更加直接，就改了一下返回包也绕过了）
2.发送短信等验证信息在本地进行，因此直接修改包就可以绕过控制，再上一个oppo的例子，是真的有毒。
相关例子：https://bugs.shuimugan.com/bug/view?bug_no=20532
这一部分本质上就是在说验证都是本地验证，而不是服务器验证，所以只要修改某些参数就可以完美进行绕过。
十.注入
找回密码处存在注入漏洞，这是一个搜索型注入来着，直接扔sqlmap就出来了。
相关例子：https://bugs.shuimugan.com/bug/view?bug_no=68060
这个就没啥好说的，常规漏洞
十一.token生成可控
先上一个例子，这个例子问题出现在重置密码的时候没有对用户身份以及账号关联性进行验证，然后白帽子在某个出现邮箱的参数输入想重置的账号，然后获取其加密字符串，然后自己使用该字符串放到url中直接重置了别人的账号。
相关例子是：https://bugs.shuimugan.com/bug/view?bug_no=94242
这个和前面的未对关联性进行验证其实也很像，只是前面是直接修改，而这里要修改的token要自己生成而已。
十二.注册覆盖
这个思路我是真的服气，他是这样的，在注册界面填入用户名之后会自动校验该名字存不存在，然后白帽子先填好密码等等其他信息，最后再填好用户名，填完立马点击提交，然后流程是这样的，他先自己提交了表单，然后网站还是会进行用户名校验，但是这时候就没什么用了，直接提交的表单就把之前的用户密码给修改了，但是进去以后发现用户之前哪些身份证什么信息还在，所以只是重置密码而已。
相关例子：https://bugs.shuimugan.com/bug/view?bug_no=88708
这个和前面不太一样，弱点出现在未对用户身份进行验证，和前面未对关联性金西行验证漏洞点不同。可重点看下。
十三.session覆盖
他妈的，越往后思路真他妈越绝了，我怎么就没有在wooyun还存在的年代进入安全圈呢，现在没思路分享真的要比以前难入门地多了。。。
接下来讲一下这思路，这名白帽子是这样的，首先自己先申请重置，然后是自己使用别人的账号又申请了一次，接着在同一浏览器里面打开自己邮箱里面的那个连接，其实这时候跟的是别人邮箱的session,然后就使用了别人的session打开自己的连接，最后重置也是直接重置了别人的账号，这思路，牛逼到飞起。。。
相关连接：https://bugs.shuimugan.com/bug/view?bug_no=85843
下面很多白帽子去查了自己媳妇的购物记录都震惊了哈哈哈2333.
这个本质上问题也是出现在未对关联性进行验证。
简单总结一下：一二三可以直接归结为一类，四五六七十一为一类，剩下的八九十十二十三主要是思路拓展。
And take a brainstorm picture as below.
Logical Vulnerability
网友评论