Google地图中的SSTI

前一段时间，我在研究Google Maps的“时间轴”功能，特别是添加自己的“地点”的功能。我复制以前在“导出为KML”功能中找到的XSS，并认为自定义位置“名称”可能是放置payload的好地方。突然我发现-我输入的“地点”之一显示不正确。我不记得我输入了什么“名字”，但是我确定它不是显示的名字：

什么？占位符？这里发生了什么？

我尝试重现上面的结果。我最初以为，也许我输入的内容类似“ aaaaaaa} ”（请注意大括号），然后这些大括号以某种方式“关闭”了输入，使我可以“注入”免费字符，然后又坏了。

按照这种思路，我尝试输入payload“ aaa {} ”。我没有得到想要的结果，但是发生了其他事情-GUI挂起了，如果不进行强制刷新，我将无法继续工作。回顾网络请求，我最终发现对“ aaa {} ”payload的响应是服务器发出的“ 500错误”，随后导致客户端发生故障。

进一步的测试表明，任何包含大括号的“地名”中的payload都将导致服务器故障。

受这些最初结果的鼓舞，我一直在尝试越来越多的payload，直到最终我能够通过输入格式为“ xxxxxx”的payload（即，任何以单引号结尾的字符）重现“占位符”问题。

因此，现在我有了两个有效的“payload”，它们破坏了某些内容，一个可以恢复的错误，另一个不能恢复，这使我得出两个结论：

换句话说-我们在这里有一个服务器端模板注入的清楚案例！

我继续四处摸索，直到设法构建一个payload，在不破坏模板的情况下注入“无害”内容，格式为“ ANYTEXT} = 2 {ANYTEXT} ANYTEXT {ANYTEXT ”。 

结果可以在这里看到：

尽管所有研究都令人兴奋，但仍然无法真正指出实际的风险。在对SSTI漏洞进行了惊人的研究鼓舞下，我想引用环境变量，读取敏感数据，甚至运行服务器端代码……但我什么也没做。不知道我使用的是哪种模板引擎，我对如何进行这项研究知之甚少。

Google制定了一项非常棒的政策，即使没有得到证明，也要奖励研究人员最大的潜在损害（您可以在其政策的“常见问题”部分中阅读有关此信息的信息），因此我决定“按原样”报告此报告，并希望能做到最好。

初次报告后的几天，我收到了一封回复

因此，积极的一面是Google的团队能够重现此错误，并将其确实确定为SSTI，甚至还很友好地向我暗示了所使用的模板

不太乐观的一面是，Google的团队显然像我一样努力地利用它，尽管如果Google的工程师无法找到一种方法来滥用它，尽管我可以为我自己对系统内部的普遍盲目性感到抱歉。则可能无法执行。 

确实，我花了很多时间尝试研究引用的模板引擎。我甚至招募了一位最熟练的同事来应对这一挑战。但是，我无法做到这一点。我在这里遇到的是一个SSTI，没有真正的危害。

我已经将失败的情况报告给了Google，并做出了类似的结论：