从带有公共站点的 js 访问 127.0.0.1 上的网络服务器的陷阱答案

【问题标题】：Pitfalls of accessing a webserver on 127.0.0.1 from js with a public site从带有公共站点的 js 访问 127.0.0.1 上的网络服务器的陷阱
【发布时间】：2008-12-02 01:47:01
【问题描述】：

我正在考虑探索让我们的客户端软件作为服务在高端口上运行并侦听来自 127.0.0.1 的简单 http GET 请求的想法。理论上，我可以通过 js 从我的网站提供的网页访问此服务。

1) 用户安装客户端软件，将自身安装为服务并在 127.0.0.1:8080 上等待经过身份验证的请求

2）当用户点击我的主页时页面上的js向127.0.0.1:8080发出xhtml请求并询问状态

3) 然后主页向我的 Web 服务器发出另一个 js 请求，发送它收到的状态。

这将允许我的用户从浏览器实时上传/下载和编辑 USB 连接设备上的文件。轮询可能是类似于我们今天所做的后备方法。

有没有人这样做过，有哪些潜在的陷阱？这还能用吗？

【问题讨论】：

标签： security web-applications hardware

【解决方案1】：

我看不到任何潜在的陷阱。不过，我确实有几点意见。

1/ 您可能希望确保您的服务仅接受来自本地计算机 (127.0.0.1) 的传入连接。否则，任何人都可以查看您的 JavaScript 并确定它正在与 [your-ip]:8080 通信。然后，他们可以从远程站点自行尝试（安全漏洞）。

2/ 我不会使用端口 8080，因为它通常用于其他事情（备用 HTTP 服务器等）。使其可配置并选择一个不错的高随机类型值。

3/ 我不确定您要对第 3 点做什么，但我认为您正尝试将状态发送回给用户。在这种情况下，为什么您主页上的 JavaScript 不能在单个会话中获取状态并输出/更新要呈现给用户的 HTML？您的“另一个 js 请求返回到我的网络服务器”对我来说没有意义。

【讨论】：

1) 好点。这就是我提到认证的原因。它可能是一个安全令牌，甚至是传入的会话 ID，服务将与 Web 服务器进行验证。
2) 另一个好点。我只以8080为例。我确实看到了一个真正的问题，选择一个总是有效的端口。由于我必须将端口放在 js 中，我无法想象动态端口将如何工作。可能必须选择一个主要和备用端口，如果主要失败，请尝试备份。
3) 服务将与之通信的硬件设备在我们的服务器上拥有用户想要的大量数据，因此他们可以对其进行操作。该代理服务允许 USB 设备与我们的网络服务器通信，并允许服务器与设备通信。

【解决方案2】：

您可能无法向 127.0.0.1 发出 xml http 请求，因为 XMLHTTPRequest 通常仅限于与提供主要内容的域相同的域。如果服务器位于客户端计算机上，我不确定此限制是否适用。话虽如此，您仍然可以创建一个 src 指向 127.0.0.1 的 <script> 标记，并让 Web 服务器返回一些 Javascript 以运行。如果您只需要一个简单的响应，这可能会很好。

【讨论】：

这将是 XMLHTTP 请求的一个很好的备份选项，但它不起作用。仍然可能被阻止，但可能性较小。

【解决方案3】：

我认为最好避免在 JavaScript 和 html 中实现应用程序逻辑。一旦用户单击网页上的按钮，JavaScript 应该向您的服务发送请求并允许它完成其余的工作。

【讨论】：

【解决方案4】：

根据您的目标用户群，您可能会遇到第 1 步（客户端自行安装）的问题。

您需要为每个支持的环境（Win2K、Vista、Linux、MAC OS 9.0/10.0 等）进行自定义安装。

如果您的用户在工作 PC 上处于锁定状态，则根本不允许这样做。

对于某些用户来说，这可能看起来非常类似于木马，除非您明确指出您将安装作为服务运行的软件。

您没有提到卸载程序。用户对“Adobe”之类的软件感到反感，这种软件会自行安装并且不提供任何合理的卸载选项

否则，这种方法是合理的，并且有几个商业产品正是使用这种方法！

【讨论】：

这是一款非常合法的软件，甚至没有任何可疑之处。如果我们的客户希望他们的硬件设备正常工作，他们需要安装一些东西，这将是一个比当前版本更精简的版本。
无意批评您的软件。只是由于僵尸网络和网络钓鱼攻击的数量众多，无辜的安装可能会被用户误解。关键是提前通知用户您将安装一些软件！