仅允许特定/官方的HTML5 Web应用程序连接到Websocket主机 [英] Allow only specific/official HTML5 Web Apps to connect to a Websocket host
问题描述
是否可以确保只能通过官方"(HTML5)应用程序建立Web套接字连接(通过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.
我认为，困难在于在Web应用程序中放置一个秘密，以便该应用程序可以将其用作官方"授权.
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?
感谢您的回复！
推荐答案
由于在浏览器中运行的代码的开放性，实际上没有直接做到这一点的方法.您可以要求使用APIkey或类似的东西，但是如果您从浏览器中使用这些APIkey，则它们并不是秘密，因此任何人都可以发现它们并在自己的应用中使用它们.
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的流氓服务器进程，但是，如果您检测到潜在的滥用行为，那么您至少具有一种将其锁定的机制(至少暂时将其锁定)一个新帐户).
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屋！
