这可能是一个通用的安全问题，但我想我会在我正在开发的领域提出问题。
该场景是：一个 Web 服务（WCF Web Api），使用 API 密钥来验证并告诉我用户是谁，以及前端的 jQuery 和应用程序的组合。
一方面，流量可以是 https，因此无法检查，但如果我对每个用户使用相同的密钥（例如 guid），并且我在两者中都使用它，那么就有可能被盗用并且有人可以冒充用户。
如果我实现类似于 OAuth 的东西，则会生成一个用户和每个应用程序密钥，这可以工作 - 但对于 jQuery 端，我仍然需要 javascript 中的应用程序 API 密钥。
只有当有人在实际计算机上查看源代码时，这才会成为问题。
我应该怎么办？
- md5 或以某种方式加密密钥？
- 将密钥放在会话变量中，然后使用ajax时检索它？
- 克服它，这不是什么大问题/问题。
我确信这可能是一个常见问题 - 所以欢迎任何指点。
为了让这一点更清楚 - 这是我编写的 API，我正在查询，而不是 google 等。所以我可以执行每个会话令牌等，我只是想计算出保护我将使用的客户端令牌/密钥的最佳方法。
我在这里有点过于谨慎，但只是用它来学习。
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.
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.
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.
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.
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.
I'm being a bit overly cautious here, but just using this to learn.
发布评论
评论（5）
（我建议将这篇文章标记为“安全”。）
首先，您应该清楚您要防范的内容。你能完全信任客户吗？狡猾的用户可以在您的页面上粘贴 Greasemonkey 脚本，并准确调用您的 UI 发送请求所调用的代码。将所有内容隐藏在 Javascript 闭包中仅意味着您需要一个调试器；这并不意味着攻击变得不可能。 Firebug 可以跟踪 HTTPS 请求。还要考虑受感染的客户端：是否安装了键盘记录器？整个系统是否秘密运行虚拟化，以便攻击者可以在闲暇时随时检查内存的任何部分？当您像网络应用程序一样暴露时，安全性确实很棘手。
尽管如此，这里有一些事情需要您考虑：
考虑不实际使用密钥，而是使用 HMAC 哈希值，例如，您在身份验证时立即提供的令牌。
DOM 存储可能比 cookie 更难破解。
查看 Google 的 OAuth 2 实现示例安全模型。基本上，您使用的令牌仅在有限的时间内有效（可能对于单个 IP 地址）。这样，即使令牌被拦截或克隆，它也只能在很短的时间内有效。当然，当代币用完时，你需要小心你的行为；攻击者是否可以执行与您的代码相同的操作并获取新的有效令牌？
不要忽视服务器端安全性：即使您的客户端应该在提交请求之前进行检查，也要在服务器上再次检查用户是否确实有权执行他们所要求的操作。事实上，这个建议可能会消除上述大部分内容。
(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.
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 2 for 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?
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.
这取决于 API 密钥的使用方式。 API 密钥（例如 Google 提供的 API 密钥）与发起请求的网站的 URL 相关联；如果您尝试在具有备用 URL 的站点上使用密钥，则服务会抛出错误，从而无需在客户端保护密钥。
然而，一些基本的 API 与客户端绑定，并且可以跨多个域使用，因此在这种情况下，我之前采用的做法是将此 API 包装在服务器端代码中，并对客户端如何与本地服务通信设置一些限制并保护服务。
不过，我的总体建议是围绕如何使用密钥对 Web API 施加限制，从而消除在客户端上尝试保护密钥的复杂性和必要性。
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.
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.
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.
如何使用 jQuery 调用处理与 API 通信的服务器端代码。如果您使用 MVC，您可以调用一个控制器操作，其中包含代码和 API 密钥来访问您的服务并向您的 UX 返回部分视图（甚至 JSON）。如果您使用的是 Web 表单，您可以创建一个 aspx 页面，该页面将在后面的代码中进行 API 通信，然后将内容写入响应流以供您的 UX 使用。然后，您的 UX 代码可以只包含对服务器端代码的一些 $.post() 或 $.load() 调用，并且您的 API 密钥和端点都将受到保护。
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.
通常在这种情况下，您可以使用“AJAX”通过服务器代理请求，该服务器验证发出请求的浏览器是否有权这样做。如果您想直接从 JavaScript 调用服务，那么您需要某种令牌系统，例如 JSON Web 令牌 (JWT)，如果服务位于当前域之外的其他位置，您将必须解决跨域问题。
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.
请参阅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密钥验证）
see http://blogs.msdn.com/b/rjacobs/archive/2010/06/14/how-to-do-api-key-verification-for-rest-services-in-net-4.aspx for more information
(How to do API Key Verification for REST Services in .NET 4)