在 HTML 中显示凭据的安全隐患

Question

我目前正在开发一个 java 后端 和一个 使用 php、html 和javascript 用于私人项目（但我最终希望将其开源），这意味着无论如何访问都仅限于我的 LAN，并且安全性目前并不发挥重要作用但将来可能会。由于我最喜欢用 Java 进行编码，因此大多数数据处理和存储（MySQL）都是用 Java 处理的，并通过 http 提供给前端（javascript; fetch()）。此外，java 后端处理身份验证进程意味着我必须通过 javascript 中的 fetch 调用将登录凭据传递到后端。由于我并不真正喜欢高级网络编程，所以我想了一个基本的 POST ->重定向->登录的 GET 设置应该足够了，我之前使用过类似的登录过程（但在 PHP 中处理身份验证）。所以：客户填写HTML-Form并提交浏览器向 /login 发出 POST 请求并传递凭据 和目标页面PHP 然后返回包含 javascript 部分 的 HTML，该部分以纯文本形式保存凭据 login("<?php echo $_POST['username'] ?>", "<?php echo $_POST['password'] ?>", "<?php echo $_POST['target'] ?>");Javascript 然后获取 java后端创建会话凭据 使用这些Javascript 问题window.location.replace(target);并且客户端被重定向到目标页面（其中通过会话 cookie 处理身份验证）我目前正在过度思考，从效率和安全的角度来看这是否是一个好主意。我目前的想法是使用表单通过javascript直接将数据获取到后端，而不是使用POST请求到附加页面（跳过上面的步骤2和3）：这意味着首先 PHP 永远不会看到凭据（这将减少一个故障点）并且凭据可能不会显示在 HTML 中。此外，这会减少加载时间，因为不再需要 POST。因此我的问题是：在 HTML 中显示凭据是否是一种不好的安全做法（就像在 URL 中显示凭据一样，以防止用户在复制 URL 时意外将其凭据发送给某人）？与此相关的风险是什么？这些凭证可以被任何使用的 JS 库或浏览器扩展读取吗？如果是这样，那些人可能也可以读取我在表单中输入的凭据？从安全角度（和效率角度）来看，我的替代设置是否更好？在这种情况下还有其他提高安全性的建议吗？感谢你们对我的帮助。

Answer 1

这篇文章的简短摘要和下面的讨论：

首先将凭据发布到 PHP，然后在返回的 HTML 中将它们返回给客户端，延迟（由于附加页面负载）增加，PHP 被添加为另一个故障点并且理论上，该系统可能会面临更多安全问题（即通过 JavaScript 或浏览器扩展扫描代码或黑客攻击 PHP 服务器）。

因此，有两种解决方案是合理的：

1. 完全跳过 PHP 并让登录由 javascript 和 < 处理仅 a i=4>java 后端（此过程的详细说明说明如下 第 1 - 5 点；这仅是可能的，因为 PHP 服务器在此特定用例中不需要身份验证信息< a i=11>)

2. 将凭据 POST 到 PHP，并让 PHP 与负责身份验证的 java 后端通信将它们保留给客户

原帖：

我不太明白为什么你认为 PHP 后端不可信，但在你的方案中，PHP 已经获得了你的凭据，这要归功于原始的 POST。如果您想避免使用 PHP，为什么不让您的表单调用 JavaCcript 函数，而不是首先 POST 到 PHP 后端：

1. 用户输入凭据

2. 用户点击“登录”

3. JavaScript 拦截登录尝试，调用login()

4. JavaScript 从文档正文 () 获取user,passgetElementById(...)

5. JavaScript 联系处理登录的 Java 后端

无需 PHP。但我可能想知道为什么这是必要的 - 如果您不能信任自己的后端，那么您的安全实践到底是什么？如果你的 PHP 不可信，为什么你的 Java 会更好呢？

在您的方案中，您已经在 POST 请求中将凭据传递到 PHP 后端。如果您担心 PHP 不知道凭据，那么您已经失败了。

至于效率，您的方案有额外的页面加载，这将使用带宽，最大化延迟（而不是最小化延迟的目标），并且让注意到额外重定向的用户认为您无能。 JavaScript 听起来更好的解决方案是您想用 Java 编写数据库代码。

就 HTML 中显示的凭据而言，实际上没有区别，因为唯一可以访问它们的人就是用户（已经输入了这些凭据的人）。如果他们输入不正确的凭据，他们只会看到不正确的凭据。 也就是说，它违反了最佳实践，而且可能不是一个好主意。

1. 在 HTML 中显示凭据是否是一种不好的安全做法（就像在 URL 中显示凭据一样，以防止用户在复制 URL 时意外将其凭据发送给某人）？与此相关的风险是什么？这些凭证可以被任何使用的 JS 库或浏览器扩展读取吗？如果是这样，那些人可能也可以读取我在表单中输入的凭据？

答案是肯定的，这完全是不好的做法，会让您面临额外的风险。他们可能不太关心，但你说得完全正确——恶意代码可以在更多地方读取凭据，并且任何 JS 库或安装的扩展都可以读取它们。

1. 从安全角度（和效率角度）来看，我的替代设置是否更好？

不，不。从安全角度来看，它增加了另一个故障点；他们可以选择破解 PHP 后端，而不是需要破解 Java 后端。这不一定是世界末日，但是一个额外的故障点。

1. 在这种情况下还有其他提高安全性的建议吗？

我在上面解释了我的建议。要么接受它并使用 PHP，要么使用 JavaScript 完全绕过 PHP。

还有一件事，在处理登录时，请确保 Java 传递一个秘密值（每个会话都是唯一的），并且服务器会在每个页面加载时验证该值< a i=2>.当我作为道德黑客工作时，我测试的应用程序通过了身份验证令牌（OAuth2），但服务器实际上并未验证它是否正确，只是客户端说它是有效的。确保服务器检查客户端所做的任何事情。

此外，强调每个会话都是唯一的，因为每个会话都保持相同的秘密值肯定是保存最差的你曾经希望没有泄露的秘密。