Ste*_*nes 6 javascript security
Javascript不允许您将私有数据或方法提供给对象,就像在C++中一样.哦,实际上,是的,通过一些涉及关闭的变通方法.但是从Python背景来看,我倾向于认为"假装隐私"(通过命名约定和文档)已经足够好,或者甚至可能比"强制隐私"(由Javascript本身强制执行)更好.当然,我可以想到这种情况并非如此 - 例如,人们在没有RTFM的情况下与我的代码进行交互但是我受到了指责 - 但我不是那种情况.
但是,有些东西让我停下来.Javascript大师Douglas Crockford,在"Javascript:The Good Parts"和其他地方,反复将虚假隐私称为"安全"问题.例如,"攻击者可以直接轻松访问字段并用自己的方法替换方法".
我很困惑.在我看来,如果我遵循最小的安全实践(验证,不要盲目信任,从浏览器发送到我的服务器的数据;不在我的网站上包括第三方脚本而不检查它们)那么就没有情况假装 - 隐私不如强制隐私"安全".是对的吗？如果不是,假装 - 隐私与强制隐私有什么安全隐患？
答案似乎是“不，假隐私没问题”。以下是一些阐述：
在现有的 javascript 中，您不能在网页上包含未知且不受信任的第三方脚本。它可以造成严重破坏：它可以重写页面上的所有 HTML，它可以提示用户输入密码，然后将其发送到邪恶的服务器，等等。Javascript 编码风格对这个基本事实没有影响。有关处理此问题的方法的讨论，请参阅PleaseStand 的答案。
一个无能但不邪恶的脚本可能会无意中因名称冲突而把事情搞砸。这是反对创建大量具有通用名称的全局变量的一个很好的论据，但与是否避免假私有变量无关。例如，我的香蕉销售网站可能使用 fake-private 变量window.BANANA_STORE_MODULE.cart.__cart_item_array。该变量并非完全不可能被第三方脚本意外覆盖，但这种可能性极小。
目前有一些关于未来对javascript进行修改的想法，这些想法将提供一个受控环境，让不受信任的代码可以按照规定的方式运行。我可以让不受信任的第三方 javascript 通过特定的公开方法与我的 javascript 交互，并阻止第三方脚本访问 HTML 等。如果这种情况存在，则可能是私有变量对于安全至关重要的场景。但它还不存在。
显然，编写清晰且无错误的代码对于安全总是有帮助的。只要真正私有的变量和方法使编写清晰且无错误的代码变得更容易或更困难，就存在安全隐患。它们是否有帮助始终是一个争论和品味的问题，以及您的背景是 C++（私有变量是核心）还是 Python（私有变量不存在）。两个方向都有争论，包括著名的博客文章Javascript Private Variables are Evil。
就我而言，我将继续使用虚假隐私：前导下划线（或其他任何内容）向我自己和我的合作者表明某些属性或方法不是模块公开支持的接口的一部分。我的假隐私代码更具可读性（IMO），并且我在构造它时有更多的自由（例如，闭包不能跨越两个文件），并且我可以在调试和实验时访问这些假私有变量。我不会担心这些程序在某种程度上比任何其他 JavaScript 程序更不安全。