logo标签列表

JavaScript对密码字段值的访问是否被视为安全风险？

javascriptsecurity
5
如果安全和良好的风格是将密码安全地存储和处理，那么对于需要用户输入密码的网页也应该如此吧？
考虑以下示例。
<script>

function copy() {
    var text = document.getElementsById('text');
    var pass = document.getElementsById('pass');

    text.value = pass.value;
}

</script>

<input type=text id=text>
<input type=password id=pass>

<button onclick="copy();">copy</button>

在密码框中输入内容并点击复制按钮，哇，它就会被暴露给全世界。但如果你从密码框中复制粘贴，则会得到无用的数据。

考虑一下登录页面上包含的未由您控制的javascript代码数量（分析、页面流跟踪器、云端托管的脚本）。为了防止这种编程方式访问密码字段，Web浏览器是否应该提供自己的密码验证API呢？

8个回答
8
这个漏洞是与传统的应用程序级身份验证实现有关，其中需要收集和传输登录/密码对。 （而且Web浏览器并不是这个秘密受到威胁的唯一地方）。
在javascript主机和/或http层面上设置了一些保障措施以防止您预见到的某些危险，但无论如何都存在代码注入的风险...
总之，如果需要有效的安全性，您可以考虑替代的身份验证方法，例如OS集成安全性、其他形式的基于挑战的安全性，以及非基于密码的方法（例如：显示一系列照片的验证码式挑战，其中部分由正在进行身份验证的人事先学习）。
8
这种编程访问密码字段的方式被阻止，而由浏览器提供自己的密码验证API，这样做有意义吗？
不。<input type="password">只是一个方便的功能，可以在输入时不显示文本。它并不作为任何安全措施。
浏览器窗口中的所有内容都完全由网站控制。它可以轻松地伪造一个密码字段或嗅探窗口中的按键，以规避对密码字段.value的任何保护。没有办法控制这一点，因此试图禁止访问密码字段是没有意义的。
更重要的是，这将破坏密码字段的几个非常有用的功能，例如能够让客户端脚本在注册时检查您是否输入了非平凡密码（并警告您使用与用户名相同的密码），或者基于客户端脚本哈希密码后发送它的登录系统。
考虑您的登录页面上包含的javascript数量，这些javascript不受您控制（分析、页面流跟踪器、云中托管的脚本）。
除非您完全做错了，否则为0。您需要停止这样做。
您在页面上包括的任何脚本都可以完全访问您的整个站点。在您的安全上下文中执行的恶意脚本隐藏输入的密码是完全无用的，因为它可以在文档的innerHTML中放置一个iframe，其中包含删除帐户表单，然后伪造单击提交按钮。或记录您在网站上按下的每个键。
如果您在页面上包括其他人的脚本，则实际上赋予了他们管理员访问权限，因此您最好信任他们。在具有任何敏感内容的站点上放置跟踪器或广告脚本是一种病态乐观的行为。
是的，Stack Overflow包括来自google-analytics.com的脚本。是的，Google可能会在那个脚本中包含代码，使每个人都编辑他们的答案以说“我喜欢屁股lol”，或者让管理员删除所有内容。也许他们不会这样做，如果他们今天心情好的话。你感到幸运吗？
我喜欢屁股lol
1
您在页面中包含的任何脚本都可以完全访问您整个站点。这就是为什么确保没有 XSS 漏洞非常重要的原因。 - Jason Harwig
虽然你提出了一些好观点，但我不会包含任何非由自己托管的JavaScript。你让它听起来像我在做错事情，而我只是指出了一些我刚意识到存在安全漏洞的功能。 - barkmadley
2
“即使有验证API，也不会有任何区别，因为页面中的任何恶意JavaScript都可以简单地监听按键并记录您在字段中输入的密码。”
“在线银行网站有时会使用有趣的密码机制，例如要求通过选择框输入密码的第二个和第七个字符（这样更难捕获）。”
“最终，网络开发人员有责任确保所有特权代码（例如文档中的JavaScript）是安全的。安装浏览器扩展、Greasemonkey脚本或桌面应用程序时也是如此-您必须检查它来自可信源。”
“您可能希望像StackOverflow本身一样使用OpenID而不是密码字段。这不仅可以减少用户记住的密码数量，而且还将安全委托给更专业的身份代理，希望其具有最严密的安全性。”
注意：检查，而不是假设。但在那个时候，JS本来就不是这项工作的正确工具。 - Piskvor left the building
1
考虑一下你的登录页面上包含的不受你控制的 JavaScript 片段数量。
为什么你会允许其他人在你的登录页面上放置不受你控制的 JS 代码？
你应该对登录页面上的内容有所掌控，这样浏览器就没有理由干涉。
2
你登录页面上从未看到过广告吗？ - DVK
你从未在登录页面上看到过jQuery或Google Analytics吗？ - Victor
6
如果您在网页上放置了未经控制的JavaScript，并且您知道这个页面需要极为严格的密码控制，那么这肯定是您自己的风险。重要的是要有适当的安全标准并遵循它们。 - Lazarus
@Victor：我在我的登录页面上看到了jQuery - 不过，这是一个经过站点本地审核的jQuery副本；就登录所保护的内容（并不太有趣）而言，我确信它不会有恶意。但是，如果您的数据足够敏感以至于需要担心恶意脚本，那么您不应该信任简单的密码，而应考虑使用双因素身份验证。 - Piskvor left the building
是的，没错，你们都是对的，你们对此负有责任...但是你们是否已经检查过jQuery源代码、Google Analytics或其他相关内容，或者完全信任它们呢？ - Victor
1

跨域JS访问已经被禁止，这样登录页面域外的脚本就无法访问您的密码字段。

3
你确定还包含了通过<script>标签引入的JavaScript代码吗？ - Victor
如果浏览器足够注重安全，实现了密码字段的特殊保护，那么它就足够安全，可以防止跨域JS访问。 - DVK
如果您通过<script>标签包含了您无法控制的随机脚本，那么您将面临比仅仅访问登录页面密码字段更大的安全问题，不是吗？ - DVK
是的，你需要这样做，但这就是重点：<script>标签可以访问所有内容。 - Victor
1

这是一个有趣的观点，但我认为如果您的网站安全性如此高，以至于这成为一个问题，那么您将不会包含任何超出您控制范围之外的JavaScript。

虽然我认为浏览器提供密码验证API是一个好主意，但无论您如何处理，某些代码（包括JavaScript或其他代码）在某个时刻都将能够访问未加密的密码文本。您会在哪里划线呢？

0

所以我们应该防止客户编写暴露自己密码的JavaScript？我在这里看不出问题。

对于想要访问密码字段内容的Web开发人员，您会怎么做？它需要是可访问的。

0

将敏感数据从JavaScript中移开。我知道人们讨厌PHP，但相信我，当涉及到表单时，它比JavaScript更安全。

对$_POST ['text']进行盐值加密、哈希处理并注册后，使用二进制类型的密码存储在数据库中。将JavaScript作为客户端与服务器端分离，至少对于敏感数据如此。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接