对内容管理系统的开发来说，一个重要和关键的步骤就是账户的身份认证实现。身份认证功能可以管理用户登录行为和会话，作出有效的登录访问控制。通常，这种认证功能一般由用户名和密码来实现，但在实际应用场景中，某些重要的内容管理系统仍然存在严重的身份认证漏洞。比如我测试的雅虎小企业平台Luminate。
Luminate：前身为图片广告公司，后被雅虎于2014年9月收购，与雅虎小企业服务平台整合，共同推动雅虎广告和小企业客户业务。
忘记密码功能
在我晚间例行参与的漏洞众测项目中，我决定研究研究Luminate的密码忘记处理功能。果然，他们还有一个重置用户密码的方法：
该方法的基本流程如下：
首先，用户向雅虎服务器提交邮箱地址，告知服务器自己忘记密码：
POST /forgotpassword HTTP/1.1 Host: login.luminate.com ontent-Type: application/x-www-form-urlencoded Content-Length: 861 Connection: close Upgrade-Insecure-Requests: 1 email=example@example.com服务器将根据提交请求的用户创建一个一次性令牌，并发往用户邮箱：
https://login.luminate.com/passwordreset?sign=TMaJJnAjigfnprxqbcfnuBK8eJmJL2PHFByAA8OblfyHdZvxhXkeTmo5G_V1TNabJHUmSR9OSeYAnzm-yAlKbUfCYLsCQtrZnZF2IxCotLh_VEn7Px6nVTA3Sm_fF9t490t_x9-t1xKcVqRPLOgQGSHb3wXYBevsypDblPoO1c4用户将使用这个一次性令牌验证自己身份，并进行密码重置操作：
POST /passwordreset HTTP/1.1
Host: login.luminate.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Content-Type: application/x-www-form-urlencoded
Content-Length: 463
onnection: close
Upgrade-Insecure-Requests: 1
password=password&cpassword=password&uuid=6491c80b-2850-4d9c-9061-73a6122b3dca&sign=TMaJJnAjigfnprxqbcfnuBK8eJmJL2PHFByAA8OblfyHdZvxhXkeTmo5G_V1TNabJHUmSR9OSeYAnzm-yAlKbUfCYLsCQtrZnZF2IxCotLh_VEn7Px6nVTA3Sm_fF9t490t_x9-t1xKcVqRPLOgQGTiD-OCPPqBlpAWpi4yXgz0&email=example@example.com
实验
这个密码重置方法非常有趣，因为它包含了其它一些没必要的额外参数。在以上流程第二步中，为了排除利用数据猜测发起的密码重置攻击，服务器根据用户邮箱地址生成了一串安全密钥的sign参数。严格意义上来说，该sign参数是密码重置的唯一必要参数，其它参数只是系统辅助数据。
在以上流程第三步中，可以看到，在实际的密码重置要求中，用户竟然可以修改“email”和“uuid”参数，这是非常有意思的地方，因为它可能与用户身份认证相关。
随着一点点的研究深入，我发现修改email参数根本无济于事，它只是起到了一个直观的提示作用。
那么，“uuid”参数是什么呢？再次勾起了我的兴趣。如果sign参数是必须的，那么这个独特的用户uuid参数又是什么作用呢？从编程开发的角度来看，我觉得开发者在超出常人想像设计系统时，可能会利用sign参数识别并获取数据，把这些数据存储在hidden隐藏字段中，之后，再对这些数据进行进一步的解析验证。
<input name="uuid" value="6491c80b-2850-4d9c-9061-73a6122b3dca" type="hidden">利用发现的问题进行攻击测试
根据以上的假设和实验可知，uuid是与用户账户ID关联的参数。如果该参数可以利用的话，我想那么不需要与sign参数配对，就能用其它人的用户ID进行密码重置。
为了验证这种攻击猜测，我利用测试账号“attacker@attacker.com”进行密码重置信息提交，其产生了一个UUID：1231c32b-2850-4e9c-9061-42k3022b3dcd；另一个测试账号为我自己的samwcurry@gmail.com，产生的UUID为：6491c80b-2850-4d9c-9061-73a6122b3dca。
当把“attacker@attacker.com”产生的UUID替换成我自己账号samwcurry@gmail.com生成的UUID后，按照以上重置流程操作，利用BurpSuite向服务器提交修改后的POST请求，最终samwcurry@gmail.com账号对应的密码竟然以账号attacker@attacker.com身份被成功重置了，GOD：
问题总结起来是这样的：uuid是与每个用户账户关联的认证参数，在密码重置请求提交时可以被修改，密码重置操作时与sign参数无关。
漏洞利用思路
回到文章一开始，用户名密码是身份验证的重要方式，当然，掌握了密码就能控制账户。而uuid又与账户密码重置相关，当然，换句话说，如果知晓uuid，也就能控制账户。假设的攻击场景如下：
虽然uuid值获取存在难度，但这种攻击场景也能说明雅虎小企业平台存在的身份认证漏洞。一旦攻击者获取了uuid，就可以利用这种攻击进行反复密码重置攻击，直到完全接管控制账户。
漏洞报送时间表
2017年6月14日 – 向雅虎漏洞初报
2017年6月14日 – 雅虎方面进行漏洞验证分类
2017年6月15日 – 漏洞修复
2017年6月25日 – 公布漏洞，等待赏金。
该漏洞利用存在一定前提，文中表达思路仅供测试参考。
*参考来源：samcurry，freebuf小编clouds编译