这个比较有意思，因为不知道怎么给这种类型命名

之前看过的分类，觉得跟这个都不怎么贴合

所以姑且叫做，校验参数默认为空，或者关键参数默认为空...

呃..这是后来去了补天，在补天交的第一个漏洞，12.7日

3库币，嘿嘿

这是我第一次挖到csrf，但是又超出一点csrf的定义。

甚是好玩，诱使用户点击自己收到的修改邮箱的链接

如果用户登陆状态，那么直接修改，如果不是登陆状态，那么跳转到登陆，登陆成功后，依旧修改。

对，这是另一种重置密码的姿势，修改账户绑定的邮箱为自己的邮箱。

这个漏洞是挖到第一个漏洞，对，第一个漏洞..

后续查阅了相关资料

就是说同一终端，同一浏览器只会有一个会话（session）

在客户端用放在cookie里面的sessionid来匹配服务端对应的会话

验证码校验成功后，服务端会将这个seesion设置会校验成功的状态

呃，字面上有点模糊，但是为了避免标题太长，只好删减一下

就是说，在最后设置新密码处，尽管检验了用户名、手机号、验证码等诸多参数

但是后台的更新语句这样update user set password='qwer1234' where id = 1

此时便可以其他信息都是自己用户正确的，但是id却是受害者的id

这个漏洞搞得我比较生气

网站存在两种找回方式：手机号、邮箱

刚开始的时候我貌似用了绕过客户端验证，来绕过手机号找回；但是死活绕过不邮箱找回

于是我又心塞塞的尝试绕过邮箱找回，进一步挖掘，放大

呃.. 在一个站点，挖到一处漏洞后，我总会像打了鸡血一样再去挖掘别的漏洞

这个类型这一个月内也只遇到一次，甚是稀缺

笑抽

交给了盒子，惨的是也不给个金币，贼抠

这种漏洞，在请求包里会有明确的用户名、手机号/邮箱字段

测试的时候注册两个账号测试一下就好。

那个时候我在想：

呃，都说src给钱，要挖就挖src

但是这种src哪里那么容易挖

呃，这是挖的第一个src，尽管是公益src ..

这是我挖任意密码重置一段时间后才遇到的，一天遇见了俩，很是搞笑，挺大的厂商四位数的验证码，笑抽

起初是提交给了补天

但是没给通过，理由是无法联系到厂商、厂商太小或者已经停止维护。

后来我有所明白，补天不收这种没有技术含量的漏洞，嗯，一定是这样。

然后我交给了盒子..