本文中，作者在分析某社交应用的注册机制时，发现复制其中的Confirm链接至微软Edge浏览器中，即能绕过原有的身份确认操作，属于用户注册邮箱自动化确认漏洞，漏洞上报后获得微软官方奖励的$10,000。

漏洞发现过程

在疫情隔离期间，我在Facebook上看到了以下这条帖图：

这条贴图激起了我深入学习WEB安全的动力，经过在HackerOne的项目筛选，我选择了Lark Technologies公司的系统作为测试目标。一开始，我花了将近五六个小时的时间，但一无所获。在漏洞测试中，我本来用Firefox比较顺手，但那天我决定用其它浏览器试试，于是，我就打开了微软的Edge浏览器对Lark的用户注册机制进行了测试。

使用邮箱进行用户注册后，我在邮箱中收到了以下Lark发来的确认邮件：

在点击确认（Confirm）按钮之前，我复制了该按钮的URL链接，尝试在浏览器中进行打开测试，看看有什么反应。当在Edge浏览器打开后，我发现该条URL链接会直接跳转到确认（Confirm）操作之后的界面，等等，这里我都还没点击确认（Confirm）按钮的啊，怎么回事？

我觉得这应该是一个漏洞，为了深入确认，我又用另外一个我的邮箱分别在Firefox和Chrome浏览器进行了测试。注册->接收确认邮件->复制其中的确认（Confirm）按钮URL链接->浏览器中打开链接，但是，什么也没发生。之后，我又把该链接复制到了Edge浏览器的地址搜索栏中，在没执行访问操作的情况下，我竟然又看到了该邮箱已被Lark身份验证通过。迷惑了。接下来，我用此种方式在Facebook、Spotify等社交应用的注册机制中尝试了一遍，但都没有出现Lark的这种情况。

我认为Lark的此种情况属于自动化的注册邮箱确认漏洞，但内心还是充满好奇。为了消除疑虑，我用BurpSuite中的burp collaborator作为 *** 服务，拷贝了上述确认邮件中的Confirm按钮链接到Edge浏览器中，不一会儿，我就观察到产生了向IP地址125.20.208.158发起的DNS请求，经反向查询，该IP地址归属于微软 *** 架构。

此时，综合上述情况，也就是说，当我把Lark注册邮件中的Confirm按钮URL链接复制在Edge浏览器的地址搜索栏中，此时，Edge浏览器会向IP地址125.20.208.158发起一个DNS请求，当Lark应用后端探测到该DNS请求后，它即认为其中包含的Confirm按钮已被用户点击并且已形成了HTTP请求，因此，Lark应用后端“理所当然”地就把该用户邮箱设置为经过身份确认的。但遗憾的是，当我把该漏洞通过HackerOne上报后，厂商Lark认为这不是一个有效漏洞，且把漏洞分类为了N/A，有点扯。

有点不甘心，之后，我想该漏洞涉及到了微软，可以把它向微软进行了上报。这里要说明的是，虽然Microsoft Edge是基于chromium内核的，但是在Google chrome浏览器该漏洞是不行的，所以，最终我也只剩下对微软的期待了。我都差不多把这事忘记了，在2021年1月6日的凌晨4点，我收到了来自微软的邮件，其中表示，我的漏洞已被微软接收，并给予了$10,000的奖励。当时，我太激动了。还是大厂实在啊。

漏洞上报和处理进程

2020.12.2 ? 漏洞一并向Lark和微软进行了上报
2020.12.2 ? 漏洞被Lark拒绝
2020.12.3 ? 微软审核我的漏洞
2020.12.23 ? 微软确认了漏洞
2021.1.6 ? ? ? 微软奖励了我$10,000
2021.1.14 ? ? ? 微软修复了该漏洞

参考来源：medium