首页 文章

Google Map 如何保护其API密钥?如何制作类似的东西?

提问于
浏览
70

目前,Google要求您创建一个API密钥,该密钥特定于将从中提供 Map 的域 . Google如何执行此操作?我想做同样的事情 .

我为我的服务公开了一个API,但是希望允许客户端通过javascript而不是从服务器嵌入对API的调用 . 我可以使用随机令牌来保护它,但当然,任何查看客户端计算机代码的人都很容易欺骗它 .

我总是理解这个概念是不可能的,但不知何故谷歌在执行它方面做得很好 .

编辑 - 听起来谷歌毕竟没有做过任何惊人的事情 . 他们的API很可能仅用于跟踪,而不是真正保证他们的API由具有密钥的人使用 .

5 回答

  • -6

    我很确定他们使用REFERER URL来确定来电的来源 . 如果域与分配给密钥的域不匹配,则它是无效请求 .

    对于实际示例,使用PHP,您可以使用 $_SERVER['HTTP_REFERER'] 检查域以检查引用程序 . 如果域匹配,则返回有效响应 . 如果没有,您可以返回401 Unauthorized或其他响应 .

  • 64

    API密钥本身很可能是与密钥关联的域的单向散列,以及只有Google API服务器知道的秘密 . 它可能包含其他一些众所周知的(当然是谷歌)信息 . 当您从该域发出请求时,API服务器将获取请求来自的域并进行相同的单向散列计算并比较这两个值 .

    对于Ajax调用,他们很可能使用referrer来获取文档主机的域 . 虽然引用者可能会被欺骗,但最终为了使用API,您需要让Google javascript在文档中执行 . 此时,此javascript可以验证调用Ajax API调用的文档确实来自目标服务器 . 当然,如果你有自己的DOM实现或者对脚本进行即时修改,这也是可以欺骗的 . 但是,这种欺骗需要在客户端进行,并且想要使用Google API的网站能够欺骗客户端软件的可能性非常小 .

    请注意,由于API基本上是免费的,因此他们也可以提供对其API的匿名访问 . 显然,谷歌的意图不是保护对它的未经授权的访问,而是确保他们能够尽可能多地收集有关该数据使用的数据,并能够将该使用与他们收集的有关目标域的其他数据相关联 . 因此,我不希望API密钥验证比我上面描述的要复杂得多 - 更高级方法的ROI太低 .

    当然,也有人担心可能通过他们的API进行XSS攻击 . 但我不相信他们的API密钥与他们拥有的任何反XSS代码相关联 .

  • 28

    正如我的评论所说:

    REFERER是可欺骗的,因此谷歌可能不太可能将其用作验证手段 . 查看此维基百科条目 .

    我的猜测是Google可能会使用调用者的IP地址和DNS查找 . DNS并不是真的可以欺骗,因为你的DNS条目必须正确,网站才能找到你 .

    但是,即使这有问题,因为如果服务器使用循环IP地址DNS设置,则在进行DNS查找时,Google将被重定向到不同的IP地址 .

    来自FAQ

    请注意,只有在使用此地址访问网站时,才会接受http://www.mygooglemapssite.com/的密钥 . 如果通过IP地址(例如http://10.1.2.3/)或使用DNS CNAME记录别名为www.mygooglemapssite.com的主机名访问该站点,则不会被接受 .

    我的猜测是它可能正在使用在请求页面时发送的 Host 标头,这可能正常,因为Google会要求您将其API脚本直接包含在页面中 . 然后该脚本可以访问当前页面的 Headers ,并可以使用它来检查 .

    我的猜测得到了支持,因为它不适用于IP地址或别名,这意味着它没有进行DNS检查 .

    这种方法不能被欺骗,因为它必须是访问页面的正确 Headers . 但是,这意味着域的任何别名都不起作用 .

    但是,这也意味着你必须提供一个Javascript库来访问代码,因为你不能检查这个服务器端,我相信 .

  • 2

    我同意所有要点that Franci Penov has listed.我想详细说明一下使用别人的API密钥 . 我们假设您使用 example.com 注册 key1 .

    • 第一次尝试 - 如果 anothersite.com<script src="http://www.google.com/jsapi?key=key1"> ,Google可以检查其引用者(提到的哈希方案),在这种情况下,存在不匹配 . 邪恶的攻击者如何克服这一点,因为很多人都提到引用者可以被欺骗?这并不适用于此 . 相信你如果你发出请求,可以发送任意 Headers ,但是 anothersite.com 上的恶意黑客如何欺骗引用者?这通常不容易 . IE 6上有旧版本的Flash,允许攻击者在发出跨域请求时设置任意标头,但一般来说这对脚本 src 不起作用 . 我不确定所包含的Javascript是否对 document.location 进行了任何验证以防止这种情况(可能不会) .

    • 第二次尝试 - 邪恶攻击者从 mysite.com 的页面源复制Google Javascript以获取API密钥,然后在 anothersite.com 上嵌入修改后的javascript . 现在谷歌可以't check anything (the remote IP will be the user'的电脑,而你或谷歌可以做的不是很多 . )

    因此,如果您出于某种原因希望保密API密钥(一个原因,恶意的人可以将您的密钥列入黑名单/阻止),那么请不要通过您的服务器将密钥嵌入客户端和代理请求中(您的应用程序代码现在具有键) .

  • 3

    它的工作原理是你不能使用javascript进行API调用 . 浏览器安全性可防止javascript在除javascript源自的域之外的任何地方发出请求 . 因此,任何来自javascript的API调用都需要通过存储API密钥的服务器进行退回(javascript密钥永远不会被javascript看到) .

相关问题