javascript Web 服务 API 密钥和 Ajax - 保护密钥
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/6302341/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Web services API Keys and Ajax - Securing the Key
提问by crucible
This is probably a generic security question, but I thought I'd ask in the realm of what I'm developing.
这可能是一个通用的安全问题，但我想我会问我正在开发的领域。
The scenario is: A web service (WCF Web Api) that uses an API Key to validate and tell me who the user is, and a mix of jQuery and application on the front ends.
场景是：一个 Web 服务 (WCF Web Api)，它使用 API 密钥来验证并告诉我用户是谁，以及前端的 jQuery 和应用程序的混合。
On the one hand, the traffic can be https so it cannot be inspected, but if I use the same key per user (say a guid), and I am using it in both then there's the chance it could be taken and someone could impersonate the user.
一方面，流量可以是 https，因此无法对其进行检查，但是如果我对每个用户使用相同的密钥（比如 guid），并且我在两者中都使用它，那么就有可能被占用并且有人可以冒充用户。
If I implement something akin to OAuth, then a user and a per-app key is generated, and that could work - but still for the jQuery side I would need the app API key in the javascript.
如果我实现了类似于 OAuth 的东西，那么会生成一个用户和一个每个应用程序的密钥，这可以工作 - 但对于 jQuery 端，我仍然需要 javascript 中的应用程序 API 密钥。
This would only be a problem if someone was on the actual computer and did a view-source.
如果有人在实际的计算机上并查看源代码，这只会是一个问题。
What should I do?
我该怎么办？
- md5 or encrypt the key somehow?
- Put the key in a session variable, then when using ajax retrieve it?
- Get over it, it's not that big a deal/problem.
- md5 或以某种方式加密密钥？
- 把key放在一个session变量里，然后在使用ajax的时候取回呢？
- 克服它，这不是什么大问题/问题。
I'm sure it's probably a common problem - so any pointers would be welcome.
我确定这可能是一个常见问题 - 因此欢迎提出任何建议。
To make this clearer- this is my API I have written that I am querying against, not a google, etc. So I can do per session tokens, etc, I'm just trying to work out the best way to secure the client side tokens/keys that I would use.
为了更清楚地说明这一点- 这是我编写的 API，我正在查询，而不是谷歌等。所以我可以按会话令牌等进行操作，我只是想找出保护客户端的最佳方法我会使用的令牌/密钥。
I'm being a bit overly cautious here, but just using this to learn.
我在这里有点过于谨慎，但只是用它来学习。
回答by Ken Arnold
(I suggest tagging this post "security".)
（我建议将此帖子标记为“安全”。）
First, you should be clear about what you're protecting against. Can you trust the client at all? A crafty user could stick a Greasemonkey script on your page and call exactly the code that your UI calls to send requests. Hiding everything in a Javascript closure only means you need a debugger; it doesn't make an attack impossible. Firebug can trace HTTPS requests. Also consider a compromised client: is there a keylogger installed? Is the entire system secretly running virtualized so that an attacker can inspect any part of memory at any time at their leisure? Security when you're as exposed as a webapp is is really tricky.
首先，您应该清楚自己要防范什么。你能完全信任客户吗？狡猾的用户可以在您的页面上粘贴 Greasemonkey 脚本，并准确调用您的 UI 调用以发送请求的代码。将所有内容隐藏在 Javascript 闭包中仅意味着您需要一个调试器；它不会使攻击变得不可能。Firebug 可以跟踪 HTTPS 请求。还要考虑一个受感染的客户端：是否安装了键盘记录器？整个系统是否秘密运行虚拟化，以便攻击者可以在闲暇时随时检查内存的任何部分？当你像 webapp 一样暴露时的安全性真的很棘手。
Nonetheless, here are a few things for you to consider:
尽管如此，您需要考虑以下几点：
Consider not actually using keys but rather HMAC hashes of, e.g., a token you give immediately upon authentication.
DOM storage can be a bit harder to poke at than cookies.
Have a look at Google's implementation of OAuth 2for an example security model. Basically you use tokens that are only valid for a limited time (and perhaps for a single IP address). That way even if the token is intercepted or cloned, it's only valid for a short length of time. Of course you need to be careful about what you do when the token runs out; could an attacker just do the same thing your code does and get a new valid token?
考虑不实际使用密钥，而是使用 HMAC 哈希，例如，您在身份验证后立即提供的令牌。
DOM 存储可能比 cookie 更难戳。
查看Google 对 OAuth 2 的实现以获取示例安全模型。基本上，您使用的令牌仅在有限的时间内有效（可能对单个 IP 地址有效）。这样即使令牌被拦截或克隆，它也只在很短的时间内有效。当然，当令牌用完时，您需要注意自己的操作；攻击者是否可以做与您的代码相同的事情并获得新的有效令牌？
Don't neglect server-side security: even if your client should have checked before submitting the request, check again on the server if the user actually has permission to do what they're asking. In fact, this advice may obviate most of the above.
不要忽视服务器端的安全性：即使您的客户端在提交请求之前应该已经检查过，也要在服务器上再次检查用户是否确实有权执行他们所要求的操作。事实上，这个建议可能会排除上述大部分内容。
回答by LewisBenge
It depends on how the API key is used. API keys like that provided by Google are tied to the URL of the site originating the request; if you try and use the key on a site with an alternate URL then the service throws and error thus removing the need to protect the key on the client side.
这取决于 API 密钥的使用方式。像 Google 提供的 API 密钥与发起请求的站点的 URL 相关联；如果您尝试在具有备用 URL 的站点上使用密钥，则该服务会引发错误，从而无需在客户端保护密钥。
Some basic API's however are tied to a client and can be used across multiple domains, so in this instance I have previously gone with the practice of wrapping this API in server side code and placing some restrictions on how the client can communicate with the local service and protecting the service.
然而，一些基本 API 与客户端相关联，可以跨多个域使用，因此在这种情况下，我之前已经将这个 API 包装在服务器端代码中，并对客户端如何与本地服务进行通信设置了一些限制和保护服务。
My overall recommendation however would be to apply restrictions on the Web API around how keys can be used and thus removes the complications and necessity of trying to protect them on the client.
然而，我的总体建议是围绕如何使用密钥对 Web API 应用限制，从而消除尝试在客户端保护它们的复杂性和必要性。
回答by John Sheehan
Generally in cases like this though you proxy requests through the server using 'AJAX' which verifies the browser making requests is authorized to do so. If you want to call the service directly from JavaScript, then you need some kind of token system like JSON Web Tokens (JWT)and you'll have to work out cross-domain issues if the service is located somewhere other than the current domain.
通常在这种情况下，尽管您使用“AJAX”通过服务器代理请求，该服务器验证发出请求的浏览器是否有权这样做。如果您想直接从 JavaScript 调用该服务，那么您需要某种令牌系统，例如JSON Web 令牌 (JWT)，并且如果该服务位于当前域以外的某个地方，则您必须解决跨域问题。
回答by Justin Schwartzenberger
How about using jQuery to call server side code that handles communication with the API. If you are using MVC you can call a controller action that can contain the code and API key to hit your service and return a partial view (or even JSON) to your UX. If you are using web forms you could create an aspx page that will do the API communication in the code behind and then write content to the response stream for your UX to consume. Then your UX code can just contain some $.post() or $.load() calls to your server side code and both your API key and endpoint would be protected.
如何使用 jQuery 调用处理与 API 通信的服务器端代码。如果您使用的是 MVC，您可以调用一个包含代码和 API 密钥的控制器操作来访问您的服务并将部分视图（甚至 JSON）返回给您的 UX。如果您使用 Web 表单，您可以创建一个 aspx 页面，该页面将在背后的代码中进行 API 通信，然后将内容写入响应流以供您的 UX 使用。然后，您的 UX 代码可以只包含一些对服务器端代码的 $.post() 或 $.load() 调用，并且您的 API 密钥和端点都将受到保护。
回答by Thinker
see http://blogs.msdn.com/b/rjacobs/archive/2010/06/14/how-to-do-api-key-verification-for-rest-services-in-net-4.aspxfor more information (How to do API Key Verification for REST Services in .NET 4)
有关更多信息，请参阅http://blogs.msdn.com/b/rjacobs/archive/2010/06/14/how-to-do-api-key-verification-for-rest-services-in-net-4.aspx信息（如何在 .NET 4 中对 REST 服务进行 API 密钥验证）
