在 puppeteer、Headless Chrome 的 DOM 中保护凭证答案

【问题标题】：Securing credential inside DOM of puppeteer, Headless Chrome在 puppeteer、Headless Chrome 的 DOM 中保护凭证
【发布时间】：2020-01-20 18:14:30
【问题描述】：

我正在设计一种服务，

使用外部来源提供的凭据隐藏现有网站的自动登录
通过使登录浏览器可见，将其移交给用户

因此，此服务可在用户需要时立即提供登录浏览器。我正在考虑使用 puppeteer，我的问题是

在#1 中，puppeteer 在通过 puppeteer API 输入凭证（ID/PW）时是否有足够的安全性来保护凭证（ID/PW）？（不用担心外部源和应用程序之间的加密。只有在黑客可以监视隐藏的 puppeteer 会话的 DOM 结构时，才可以在应用程序和 puppeteer 之间进行加密。）
在#2中，我可以动态设置隐藏的浏览器可见吗？

【问题讨论】：

标签： selenium puppeteer google-chrome-headless headless-browser webautomation

【解决方案1】：

Node.js 与浏览器之间的通信

Node.js 环境和浏览器之间的通信默认不加密，因为它使用未加密的 Websocket 协议 (ws://) 而不是加密的 (wss://)。如果您的 puppeteer 实例从一台机器连接到另一台机器，这意味着人们可能能够嗅探连接 (more information)。

请记住，如果您的 Node.js 应用程序和浏览器在同一台机器上运行，这并不重要。当然，任何可以访问您的计算机和正在运行的应用程序的攻击者也可以监控内存，甚至可以通过 WebSocket 直接连接到您正在运行的浏览器。

动态显示或隐藏浏览器

关于您的第二部分：使用 puppeteer API 无法将浏览器状态从“可见”更改为不可见（反之亦然）。但是您可以使用操作系统的 API 来执行此操作，也可以序列化浏览器的状态并将状态传输到另一个浏览器实例 (more information)。

【讨论】：

谢谢。我从您的第二个答案中获得了深刻的见解。关于第一个，我会沿着使用带有无头 chrome 或等效的 C++ 库的路径来保护内部跟踪免受攻击者的攻击。我可能会使用无头浏览器甚至更原生的 HTTP 方式执行 #1，然后序列化您在链接中提到的 cookie，以将其交给具有可见 Web 浏览器的用户。如果有这样的无缝解决方案，那就太好了。