背景介绍：

今天的白帽小哥ID：Raidh Ĥere，他在Google Dialogflow中成功找到一处IDOR漏洞，最终获得了Google发放的3133.7美元的赏金奖励。话不多说，我们开始吧。

漏洞寻找：

白帽小哥在这枚漏洞之前，已成功找到过Google的一处漏洞（这个漏洞有机会下次有机会单独来讲），于是小哥再接再厉，开始尝试挖掘更多的漏洞，他相信Google Dialogflow在访问中断时应该会更容易受到攻击。

那么什么是Dialogflow，来看看维基百科上的解释：

Dialogflow （前身为Speaktoit的Api.ai）是一项属于Google的开发工具，提供基于自然语言对话的人机互动技术。–维基百科

Dialogflow目前有两个版本，分别是Dialogflow Essentials和Dialogflow CX，事实上，Dialogflow CX可以说是是Essentials的升级版。于是白帽小哥开始尝试搜索寻找错误的访问控制问题。

小哥使用手动测试IDOR，因为他发现使用自动化工具对更改Method、添加自定义headers没有太多帮助。

在测试过程中，这处“测试用例（Test Cases）”引起了小哥的兴趣：

这个测试用例（Test Cases）是空的，小哥尝试导入，但并未成功。于是，他开始搜索这个功能，但一无所获。最终在别无选择时，他决定阅读使用文档。

功夫不负有心人，白帽小哥最终发现了一个有趣的东西，构建一个Use-pre-built-agents：

进入后有很多Pre Build Agent可用，随手选择了第一个：

成功创建后，他开始寻找测试用例（Test Cases）：

注意下面这里！

白帽小哥选择删除测试用例，并抓包查看：

请求中有这么一串字符串：

{“names”:[“projects/agent-nameas-nqsq/locations/us-central1/agents/3fbab09c-d034–4f35-bb1f-1ab0837e8806/testCases/9a1c14e8–3dee-43a6–8e58–10d4a1fb8a70”]}

这段字符串中有两个不同的ID，一个是agent id，一个是testCases id，这两个id非常复杂，基本不太可能进行暴力猜测，似乎走进了死胡同……

但此时小哥冒出了一个想法，为什么不创建一个“受害者”的账户，按照上面的步骤，重新创建Pre Build Agent呢？

说干就干！

因此，在“受害者”账户中，白帽小哥删除了相同的测试用例（Test Cases）并拦截请求，他看到了相同的testCases id！是不是眼前一亮？

他将这两个请求分别发送Burpsuite，并开始研究这两个请求的主要区别有哪些。

这两个请求的主要区别就在agents/3fbab09c-d034–4f35-bb1f-1ab0837e8806，于是他尝试将攻击者的id替换为受害者的id，成功删除了受害者账户中的测试用例（Test Cases），但是这段id是复杂且无法使用暴力猜测的，沮丧之感涌入心头…

在思考良久后，白帽小哥开始使用Dorking Google，同样没有任何成效。于是他开始在Dialogflow Essentials中搜索是否有可利用的地方。

最终他找到了上图这个地方！要将agent集成到任何网站时，您可以粘贴这个JavaScript代码，或是通过启用Web演示来分享Agent链接。

这里是获取Agent id的主要手段，完全可以利用这里去尝试获取不同组合的Agent id。

搞定!是时候报告这个漏洞了，漏洞的影响是，攻击者可以选择所有的测试用例（Test Cases），并通过修改Agent id进行一键删除。

白帽小哥最终获得Google的致谢信及3133.70美元的奖励！