wsh - 替代自定义协议(protocol)(URI 方案)

Question

我一直在我们所有的内部应用程序上广泛使用自定义协议(protocol)来打开任何类型的文档(CAD、CAM、PDF 等)，打开文件资源管理器并选择特定文件，以及运行其他应用程序。

多年前我定义了一个 myprotocol执行 C:\Windows\System32\wscript.exe 的协议(protocol)传递我的 VBScript 的名称以及每个请求具有的任何参数。传递给脚本的第一个参数描述 Action 的类型( OpenDocument ， ShowFileInFileExplorer ， ExportBOM 等)，以下参数传递给 Action 。

一切都很顺利，直到去年，wscript.exe停止工作(详见 here)。我通过将其复制到 wscript2.exe 来解决该问题.创建副本现在是我们所有计算机的标准配置中的一个步骤，并且使用 wscript2.exe现在是我们自定义协议(protocol)的官方配置。 (我们的防病毒客户支持找不到任何与 wscript.exe 交互的内容)。

今天，在构建了一台新计算机后，我们发现:

Firefox 看不到 wscript2.exe .如果我单击自定义协议(protocol)链接，然后单击浏览按钮并打开文件夹，我只会看到 .exe 的一小部分文件，其中包括 wscript.exe , 但不包括 wscript2.exe (我不知道这个问题有多近，因为我个人不使用 FireFox)。

Firefox 看到 wscript.exe ，但它仍然不起作用(与上面链接的上一篇文章中描述的行为相同)

Chrome 适用于 wscript2.exe ，但现在它总是要求确认。根据this article这似乎是一种新方法，而且情况可能很快会再次发生变化。每次点击确认框对我的用户来说都是一个很大的禁忌。这会减慢许多需要快速单击页面上数百个链接的工作流程，例如，查看 CAD 应用程序缩放到大型图纸中的一个几何图形。

去年我已经解决了一个问题，现在我正在处理另一个问题，阅读那篇文章让我感到害怕，让我认为很快就会出现更多问题。

那么问题来了:有没有使用自定义协议(protocol)的替代方案？

我不是在开发供公众使用的网络应用程序。我的自定义协议(protocol)需要 VBScript 文件、脚本使用的应用程序和大量的网络共享文件夹。它们仅在我们的内部网络中使用，并且使用它们的计算机是手动配置的。

Answer 1

首先，即使它只在内部网络上，那也是非常危险的。除非计算机/用户/浏览器被锁定在 Internet 之外，否则有人可能会猜测或发现您的协议(protocol)名称，将链接发送给您公司中的某人并造成很多麻烦(也可能造成损失)。

反正...

由于您正在控制所有计算机上的软件，因此您可以在每台计算机上添加一个迷你服务器，只监听 localhost，它只是调用您的脚本。然后定义主机如 secret.myprotocol指向该服务器，例如 localhost:1234。

为了稍微减少潜在问题，本地服务器将仅使用 HTTPS，并使用正确的证书 HSTS和 HPKP设置为很长的时间(由于您控制软件，您可以在需要时刷新它们)。最后两个，以防万一有人尝试设置相同的域，并且无论出于何种原因，主机覆盖不起作用并且用户最终调用了敌对服务器。

因此，链接必须从 myprotocol://whatever 更改至https://secret.myprotocol/whatever .

它确实引入了新的攻击面(“迷你服务器”)，但应该很容易实现，以最小化该面的大小:)。 “迷你服务器”甚至不必是真正的 www 服务器，一个可以监听套接字并调用 wscript.exe 的简单脚本会做(除非你需要向它传递更多信息)。
真实服务器有更多可能有错误的代码，但也允许添加更多内容，例如“通过”页面，显示信息“在 3 秒内打开文档 X...”和“取消”按钮。
它还可能需要某种 session 登录(只是为了确保请求操作的是用户，而不是其他)。