在HTML中显示凭据的安全含义

Question

我目前正在为一个私人项目开发一个java后端和一个使用php、html和javascript的前端(但我最终想开源)，这意味着访问权限无论如何都局限于我的局域网，安全性目前不起重要作用，但将来可能会起到重要作用。

由于我最熟悉用java编码，所以大多数数据处理和存储(MySQL)都是用java处理的，并通过http提供给前端(javascript；fetch())。

此外，这个java后端处理身份验证过程，这意味着我必须通过javascript中的fetch调用将登录凭据传递给后端。

由于我并不是真正喜欢高级web编程，我设计了一个基本的POST->REDIRECT->登录的GET设置应该足够了，我以前使用过类似的登录过程(但在PHP中处理身份验证)。因此：

1. 客户端填写HTML表单并提交
2. 浏览器向/login发出POST请求，传递凭据和目标页面
3. 然后，PHP返回包含javascript部分的HTML，该部分以明文形式保存凭据login("<?php echo $_POST['username'] ?>", "<?php echo $_POST['password'] ?>", "<?php echo $_POST['target'] ?>");
4. Javascript然后使用凭据获取java后端以创建会话
5. Javascript发出window.location.replace(target);，客户端被重定向到目标页面(通过会话cookie处理身份验证)

如果从效率和安全的角度来看这是个好主意，我现在想得太多了。我目前的想法是使用该表单使用javascript直接将数据提取到后端，而不是使用POST请求到附加页面(跳过上面的第2步和第3步)：

这意味着首先PHP将永远看不到凭据(这将减少一个失败点)，并且凭据可能不会显示在HTML中。此外，由于不再需要POST，这将缩短加载时间。

因此，我的问题是：

1. 在HTML中显示凭据(就像在URL中显示凭据一样，以防止用户在复制URL时意外将凭据发送给他人)是否是一种糟糕的安全做法？与此相关的风险是什么？这些凭据可以被任何使用的JS库或浏览器扩展读取吗？如果是这样的话，他们可能也会阅读我在表格中键入的凭据
2. 从安全角度(和效率角度)看，我的替代设置是否更好
3. 在这种情况下，是否有其他改进安全性的建议

谢谢你帮我。

Answer 1

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

通过首先将凭据张贴到PHP，然后在返回的HTML中将其提供回客户端，延迟(由于额外的页面负载)增加了，PHP被添加为另一个故障点，理论上系统会面临更多的安全问题(即通过javascript或浏览器扩展扫描代码或入侵PHP服务器)。

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

1. 完全跳过PHP，让登录只由javascript和java后端处理(下面第1-5点中对该过程的详细描述；这是可能的，因为PHP服务器在此特定用例中不需要身份验证信息)
2. 将凭据POST到PHP，并让PHP与负责身份验证的java后端通信，而不是将其保留给客户端

原始帖子：

我不太明白为什么你认为PHP后端不可信，但在你的方案中，由于最初的POST，PHP已经获得了你的凭据。如果你想避免使用PHP，为什么不让你的表单调用JavaCscript函数，而不是首先发布到PHP后端：

1. 用户输入凭据
2. 用户点击"；登录">
3. JavaScript拦截登录尝试，调用login()
4. JavaScript从文档主体(getElementById(...))获取user,pass
5. JavaScript与处理登录的Java后端联系

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

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

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

至于HTML中出现的凭据，实际上没有什么区别，因为唯一可以访问它们的人是用户(已经输入了它们)。如果他们输入的凭据不正确，他们只会看到不正确的凭据也就是说，这违反了最佳实践，可能不是一个好主意。

1. 在HTML中显示凭据(就像在URL中显示凭据一样，以防止用户在复制URL时意外将凭据发送给他人)是否是一种糟糕的安全做法？与此相关的风险是什么？这些凭据可以被任何使用的JS库或浏览器扩展读取吗？如果是这样的话，他们可能也会阅读我在表格中键入的凭据

答案是肯定的，这完全是一种糟糕的做法，会给你带来额外的风险。它们可能不太令人担忧，但你做得很对——有更多的地方恶意代码可以读取凭据，任何JS库或安装的扩展都可以读取它们。

2. 从安全角度(和效率角度)看，我的替代设置更好吗

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

3. 在这种情况下，是否有其他改进安全性的建议

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

还有一件事，在处理登录时，请确保Java传递一个秘密值(每个会话唯一)，并且服务器在每次页面加载时都会在上验证该值。当我作为一名道德黑客工作时，我测试的一个应用程序通过了身份验证令牌(OAuth2)，但服务器实际上并没有验证它是否正确，只是客户端说它是有效的。确保服务器检查客户端执行的任何操作。

此外，强调对每个会话都是唯一的，因为每个会话保持不变的秘密值肯定会是你所希望的最糟糕的秘密。