只允许特定/官方的 HTML5 Web 应用程序连接到 Websocket 主机 [英] Allow only specific/official HTML5 Web Apps to connect to a Websocket host

问题描述

是否可以确保只能从官方"(HTML5) 应用程序建立网络套接字连接(通过 socket.io)?

is it possible to ensure, that establishing a web socket connection (via socket.io) is only possible from an "official" (HTML5) app?

目标是，在没有进一步授权信息的情况下，了解 API 的第三方应用无法连接到主机.

The target is, that third party apps with knowledge of the API cannot connect to the host without further authorization information.

在我看来，难点在于在网络应用程序中放置一个秘密，以便应用程序可以使用它来授权为官方".

In my opinion, the difficulty is to place a secret in the web app so the app can use it to authorize as "official".

这个要求有点难以实现，因为 javascript 内容总是可读的，无论你是否在代码上应用了晦涩的方法.

This requirement is kind of hard to realize, because javascript content is always readable, no matter if you apply obscure-methods over the code.

是否有任何概念/插件/库等以描述的方式对 API 进行对冲?

Are there any concepts / plugins / libraries etc. to hedge an API in the described way?

感谢您的回复！

推荐答案

实际上没有办法直接做到这一点，因为在浏览器中运行的代码是开放的.您可以要求 APIkeys 或类似的东西，但如果您在浏览器中使用这些 APIkeys，它们就不是秘密，因此任何人都可以发现它们并从他们自己的应用程序中使用它们.

There is really no way to do this directly because of the openness of code that runs in a browser. You can require APIkeys or some such thing, but if you're using those APIkeys from a browser, they are not a secret so anyone can discover them and use them from their own app.

网站处理此问题的最常见方式是要求对您的 websocket 连接进行用户身份验证(通常可以利用可能已经通过已经存在的 cookie 完成的网页用户身份验证).这显然需要用户在您的服务上拥有一个帐户并登录到该帐户.然后，如果您发现某个特定连接被滥用，您可以从该服务中禁止该用户的凭据.

The most common way sites deal with this is to require user authentication on your websocket connection (can often leverage webpage user authentication that may already have been done via a cookie that is already present). This obviously requires users to have an account on your service and to login to that account. Then, if you see misuse of a particular connection, you can ban that user's credentials from the service.

这并不能阻止某人设置使用他们自己的凭据来使用您的 API 的流氓服务器进程，但是如果您检测到潜在的滥用，那么您至少有一种机制可以将它们锁定(至少是暂时的，直到他们使用您的 API)新帐户).

This does not prevent someone from setting up a rogue server process that uses their own credentials to use your API, but if you detect potential misuse, then you at least have a mechanism for locking them out (at least temporarily until they make a new account).

您还可以确保您的服务不接受跨域请求.这可以防止其他基于浏览器的应用程序直接从浏览器使用您的 API.它不会阻止脚本(在浏览器外部或服务器上运行)使用您的 API.

You can also make sure your service does not accept cross-origin requests. This prevents other browser-based applications from using your API directly from the browser. It does not stop a script (running outside the browser or on a server) from using your API.

您可以创建服务条款，允许您禁止任何与您的条款不一致的访问.如果需要，这实际上只是一种法律支持，但并不能防止有目的的滥用.

You can create terms of service that allow you to ban any access that is not consistent with your terms. This is really just a legal backstop if needed, but doesn't prevent purposeful misuse.

您可以在您的 API 中构建一些异常使用模式的检测(例如有人试图从您的站点收集所有数据)，而您的常规客户端应用程序通常不会尝试这些模式.这可能会导致帐户被标记，人们可能会进一步调查并决定是通知还是禁止该帐户.许多服务(如 Google 服务)在站点中内置了速率限制，以防止某个特定连接使用超过公平份额的服务器资源.该路径更多的是服务器保护或负载保护策略，而不是防止未经授权的使用功能.

You can build into your API some detection of abnormal usage patterns (such as someone attempting to harvest all data from your site) that would not normally be attempted by your regular client application. This could then lead to an account being flagged that a human might look into further and decide whether to notify or ban the account. Many services like Google services have rate limiting built into the site to keep one particular connection from using more than a fair share of server resources. That path is more of server-protection or load-protection-tactic rather than a prevent-unauthorized-use feature.

我见过的另一种技术是一种威慑，但我自己并没有真正使用过，它是将不断变化的代码嵌入到使用您的 API 的每个合法网站页面中，并要求该代码与所有 API 请求一起发送.这可以防止 API 在未首先发出网页请求以获取代码的情况下完全自行使用.如果代码本身没有直接嵌入到页面中，而是根据嵌入在网页中的其他一些东西使用一些 Javascript 计算出来的，那么服务器进程从网页中抓取代码的工作量会更大要求.不断变化的代码有一定的生命周期，您的服务器可以知道它何时过期.这不是真正的安全，因为有进取心的开发人员可以通过发出正常的 Web 请求来解决它，获取所需的令牌，然后计算不断变化的代码的当前版本，并定期执行此操作以保持其代码最新.但是，它确实使它足够工作，可以阻止更随意的黑客尝试使用您的 API.

Another technique I've seen described which is a deterrent, but not actually used myself is to embed an everchanging code into each of your legitimate web-site pages that uses your API and require that code to be sent with all API requests. This prevents the API from being used entirely on it's own without first making a web page request to fetch the code. If the code itself is not directly embedded in the page, but instead is calculated with some Javascript based on some other things embedded in the web page, then it makes it even more work for a server process to scrape the code out of a web page request. The everchanging code then has some lifetime and your server can tell when it has expired. This is not true security because an enterprising developer can work around it by making a normal web request, getting the tokens needed to then calculate the current version of the everchanging code and to do that regularly to keep their code up to date. But, it does make it enough work that it's a deterrent to the more casual hacker trying to use your API.

而且，如果您发现某个特定来源的重复滥用行为，您还可以从您的服务中阻止 IP 范围(也冒着意外阻止某些合法用户的风险).

And, if you see repeated abuse from a particular source, you can also block IP ranges from your service (at the risk of accidentally blocking some legitimate users too).

这篇关于只允许特定/官方的 HTML5 Web 应用程序连接到 Websocket 主机的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！