劫持Google Data Studio的共享报告链接(2)

按耐不住心情，我及时把漏洞上报，之后谷歌很快回复称漏洞已被接收分配。但是，我却发现其中的reportId参数我还没测试过啊，所以我继续进行了测试。我简单把上述创建报告的reportId参数87d41ef9–1ebc-4d92–84e7-d5948e5940ed，把最前面的8变成了7，换为77d41ef9–1ebc-4d92–84e7-d5948e5940ed，进行了POST提交，得到的却是状态码为500的响应。

我想估计77d41ef9–1ebc-4d92–84e7-d5948e5940ed是一个无效的reportId参数，所以当我把它替换成另一个有效的reportId参数后，执行POST请求，Google Data Studio服务端可以有效响应。

之后，我及时向谷歌上报解释了该情况。

在做Web应用测试之前，应该熟悉目标应用的工作机制；

抱着游戏的心态去分析测试漏洞，在其中反复测试，去发现一些可疑行为；

站在安全防护的角度去考虑问题，去想办法突破固定的安全模式；

测试IDOR漏洞时，要留意服务端响应，有些响应虽然不成功，但其中透露的信息可能有用；

要学会记录和思考，判断哪些操作是开发者忽视掉的，而用户却可执行的；

发现漏洞时，要认真思考它的危害性。

2019.11.22: 漏洞初报

2019.11.23: 追加reportId参数可替换的解释

2019.12.5：谷歌无法复现漏洞

2019.12.5：我发送详细漏洞信息

2019.12.14：漏洞被分类为P2级别

2019.12.16：漏洞被分类为P1级别

2020.1.4：谷歌发放漏洞奖励

2020.2.4：谷歌修复漏洞