背景说明
目标服务器存在WAF，一旦进行扫描尝试，就会立即封锁IP地址，因此只能手动渗透该目标。为了保密，暂将目标网站称为’redacted.com‘，这是一个管理物联网项目、云解决方案、设备等的平台，它允许一个用户创建多个账户，并且只要知道他们的电子邮件地址，就可以邀请不同的用户加入项目。该网站允许灵活的账户注册，但是，每次注册都需要发送至电子邮件的OTP来进行验证，然后才能创建账户。
发现
在注册了一个用户并浏览了平台所有功能特性后， “创建新账户”功能成功引起了白帽小哥的注意。
来看下面这个请求：
在创建新账户时，它不仅有Name字段，而且还包含Email字段。返回的数据包含了idUser，Email，Role和一个名为sso_type的有趣字段。
那么如果在创建账户时将属于另一个用户的Email的值更改会发生什么？
利用另一位用户giongfnef26+user2@intigriti.me（受害者电子邮件，拥有普通账户权限）。
是的，成功发现第一处漏洞，攻击者可以创建属于另一个用户的帐户。
批量分配漏洞
再次观察请求：在用户界面上，只需要输入名称 -> 但在请求中，需要一个电子邮件地址。
拥有丰富渗透经验的白帽小哥意识到，这里可能存在一个隐藏参数！但是尝试了常见的参数均无任何收获。
在这个时候，白帽小哥考虑到命名规则可能会根据开发者的习惯有所不同 -> 于是白帽小哥尝试以这种方式进行探索，将其与观察到的模式结合起来，有趣的事情发生了！
这显然是一个“批量分配漏洞”（https://portswigger.net/web-security/api-testing#mass-assignment-vulnerabilities）。既然有了密码，那尝试登录看看。
额…完全没有用！这里有两个问题需要思考：
1、如果知道与该用户关联的电子邮件，那么就可以在任何用户中创建任何账户
2、如果不知道那个用户的电子邮件怎么办？如果那个电子邮件从未被用来注册用户怎么办？
使用一个从未注册过的电子邮件尝试，然后在响应包中发现了一些奇怪的东西：
原因找到了，原来是密码不符合密码复杂度要求，重新调整密码复杂度，哦耶～
再次使用Email和Password登录，令人难以置信的是，可以直接登录，而不需要从电子邮件中验证OTP。
账户接管
坦白的说，能够绕过双因素认证确实能够带来更高的影响，但白帽小哥一时想不到更好的方法，于是他向他的一位资深同事（一位经验丰富的黑客）请教，他以一种非常有趣的方式启发了白帽小哥：
假设以下场景：
1、攻击者可以首先使用诸如 passwdAttacker 之类的密码注册用户
2、然后，受害者使用不同的密码 passwdVictim 注册相同的用户
3、如果攻击者仍然可以使用旧密码 passwdAttacker 登录用户，这就意味着：攻击者实现了账户接管，或者更准确地说，是预账户接管
假如仍然可以注册用户 vrongdethuongv@gmail.com -> 那不就OK了？
失败！会检查该用户之前是否存在…
但是一件奇怪的事情是：注册时，网站被重定向到 sso.redacted.com -> 与之前遇到的 store.redacted.com 不同…
1、 检查用户的电子邮件API：
因此，如果电子邮件通过 sso_type:1 验证，则表示用户已通过电子邮件验证；如果未通过验证，则表示 sso_type:null。现在注意type值，分别是sso和local。
如果 sso_type:1 -> 我们将重定向到 sso.redacted.com 中的登录，验证用户没有的功能：“迁移”：
尝试一下该功能：
“成功迁移 SSO 登录” ?
再次检查了这封电子邮件 -> 响应已更改：sso_type:1 & type:sso
现在，这个邮箱就可以正常注册了！
使用不同的密码注册了该用户，并像往常一样验证了 OTP，但是却仍然可以使用旧密码登录该帐户！
那么，成功地进行了一次 Pre-ATO，同一个账户同时存在两个密码！？
发生了什么？
白帽小哥的推断是这样的：
有 2 个不同的数据库，我们称之为 Store 和 SSO，普通用户只能在SSO数据库中注册，只有获得授权的个人（特殊角色）才能在商店中创建帐户，并且“迁移”功能会将该普通用户的电子邮件迁移到 SSO。但是这两个数据库不同步。
- 如果先在 Store 中创建用户，就可以使用“迁移”功能将数据迁移到 SSO -> 就可以同时登录 store.redacted.com 和 SSO.redacted.com
- 如果先在 SSO 中创建帐户，则用户只能在 SSO.redacted.com 登录，并且只能使用第一次注册时的密码
这就是无法在第 2 部分登录的原因。
Pre-ATO 场景如下：
1、攻击者利用在Store数据库中预注册victim@companyA.com帐户的漏洞
2、接下来，攻击者登录victim@companyA.com，并使用“迁移”（Migrate）功能将其转移到SSO数据库，等待受害者注册该帐户
3、受害者注册账户victim@companyA.com并正常使用
4、攻击者仍然可以以victim@companyA.com身份登录并访问所有资源
总结
一个非常有趣的案例，可以从中学到很多东西！
可以从漏洞中收获更多的“赏金奖励”！
当大家都在谈论漏洞赏金时，却很少有人问“你睡得怎么样？”
想要有所成就，就需要付出努力！
付出的努力越多，你得到的就越多！
如果你在自己热爱的工作中感到沮丧，那就再努力一点！
