原文：
https://www.ehpus.com/post/ssti-in-google-maps
前一段时间，我在研究Google地图的时间轴功能。“places”功能忽然吸引了我的注意。我记不住我在name字段输入了什么，但是肯定不是展示的内容。
看起来像是占位符一样的东西显示了出来。
初步研究
我尝试复现上面的结果。我最初以为，也许是我输入了一些类似“ aaaaaaa}的行（请注意大括号），然后这些大括号以某种方式“关闭”了输入，允许我“注入”任意字符，然后有些东西被破坏了。
按照这种思路，我尝试输入有效载荷“ aaa {} ”。我没有得到想要的结果，但是发生了其他事情-突然，GUI挂起了，如果不进行强制刷新，我将无法继续工作。回顾网络请求，我最终发现对“ aaa {} ”有效负载的响应是服务器发出的“ 500错误”，随后导致客户端发生故障。
进一步的测试表明，任何包含大括号的“places”中的有效负载都将导致服务器故障。
受这些最初结果的鼓舞，我一直在尝试越来越多的有效载荷，直到最终我能够通过输入格式为“ xxxxxx”的有效载荷（即，任何以单引号结尾的字符）重现“占位符”的问题。
因此，现在我有了两个有效的“有效负载”，它们破坏了某些内容，一个可恢复错误，一个不可恢复错误，这使我得出两个结论：
服务器在使用某种模板生成客户端页面时，正在使用客户端提供的“地名”。
缺少输入验证，并且客户端可能会干扰模板结构。
换句话说-我们在这里有一个服务器端模板注入的明显案例！
我继续四处摸索，直到设法构建一个有效载荷，在不破坏模板的情况下注入“无害”内容，形式为“ ANYTEXT} = 2 {ANYTEXT} ANYTEXT {ANYTEXT ”。
结果可以在这里看到：
可以利用吗？
尽管所有这些研究都令人兴奋，但我仍然无法真正指出实际的风险。在对SSTI漏洞进行了惊人的研究的鼓舞下，我想做些恐怖的事情，引用环境变量，读取敏感数据，甚至运行服务器端代码……但我却什么也没做。不知道我使用的是哪种模板引擎，我对如何进行这项研究知之甚少。
Google制定了一项非常棒的政策，即使没有得到证明，也要奖励研究人员最大的潜在损害（您可以在其政策的“常见问题”部分中阅读有关此信息的信息），因此我决定“按原样”报告此报告，并希望能做到最好。
因此，积极的一面是Google的团队能够重现此错误，并将其确实确定为SSTI，甚至还很友善地向我暗示了所使用的模板。
不太乐观的一面是，Google的团队显然正像我一样努力地利用它，尽管如果Google的工程师无法找到一种方法来滥用这一点，尽管我可以为自己对系统内部的普遍盲目辩解自己的困难，则可能无法执行。
确实，我花了很多时间尝试研究引用的模板引擎。我甚至摇了我最熟悉SSTI的同事之一来应对这一挑战。尽管如此，我只是无法做到这一点。我在这里拥有的SSTI并没有真正的危害。
我已经将失败的情况报告给了Google，并做出了类似的结论
显然没有办法利用
最后的想法
虽然我对最终结果感到失望，但这是漏洞赏金的生命周期-并非所有路径都以赏金结尾。尽管如此，我还是非常喜欢这项研究，并且始终坐在座位上，这就是为什么我从一开始就进行安全研究的原因。希望你像我一样喜欢这个🙂
译者按：
之前给大家分享的都是成功挖到漏洞，获得赏金的。今天给大家分享一个利用失败的。有时候，有的点确实是没有办法利用。发现确实没法利用，就换个点挖挖呗。毕竟3分天注定，7分靠打拼。剩下90分就看运气了。
本文迁移自知识星球“火线Zone”
