javascript“虚假隐私”是否会带来安全风险?

时间:2013-01-13 14:22:09

标签: javascript security

Javascript不允许您将私有数据或方法提供给对象,就像在C ++中一样。哦,实际上,是的,通过一些涉及关闭的变通方法。但是从Python背景来看,我倾向于认为“假装隐私”(通过命名约定和文档)已经足够好,或者甚至可能比“强制隐私”(由Javascript本身强制执行)更好。当然,我可以想到这种情况并非如此 - 例如人们在没有RTFM的情况下与我的代码进行交互但是我受到了责备 - 但我不是那种情况。

但是,有些东西让我停下来。 Javascript大师Douglas Crockford,在“Javascript:The Good Parts”和其他地方,反复将虚假隐私称为“安全”问题。 For example,“攻击者可以直接轻松访问这些字段,并用自己的方法替换这些方法。”

我对此感到困惑。在我看来,如果我遵循最小的安全实践(验证,不要盲目信任,从浏览器发送到我的服务器的数据;不在我的网站上包括第三方脚本而不检查它们)那么就没有情况假装 - 隐私不如强制隐私“安全”。是对的吗?如果不是,假装 - 隐私与强制隐私有什么安全隐患?

2 个答案:

答案 0 :(得分:1)

不在其中。但是,它确实意味着您无法安全地将不受信任的JavaScript代码加载到HTML文档中,正如Crockford所指出的那样。如果您确实需要在浏览器中运行此类不受信任的JavaScript代码(例如用于社交网站中用户提交的小部件),请考虑使用iframe沙盒。

作为Web开发人员,您的安全问题通常是主要的互联网广告代理商不支持(甚至prohibit)构建其广告代码。不幸的是,你必须相信谷歌不会有意或无意地提供恶意JavaScript(例如他们被黑客入侵)。

以下是我发布的iframe沙盒的简短说明,作为another question的答案:

  

为用户提交的HTML,CSS和JavaScript设置完全独立的域名(例如“exampleusercontent.com”)完全。不允许通过您的主域名加载此内容。然后使用iframe将用户内容嵌入到您的网页中。

     

如果您需要比简单框架更紧密的集成,window.postMessage()可能有所帮助,允许不同框架中的脚本以受控方式相互通信。

答案 1 :(得分:0)

似乎答案是“不,假隐私很好”。以下是一些细节:

  • 在今天存在的javascript中,您不能在网页上包含未知且不受信任的第三方脚本。它可以造成严重破坏:它可以重写页面上的所有HTML,它可以提示用户输入密码,然后将其发送到邪恶的服务器等等.Javascript编码风格对这个基本事实没有任何影响。有关处理此问题的方法的讨论,请参阅PleaseStand's answer

  • 一个无能而非邪恶的剧本可能会无意中通过名称冲突搞砸了。这是反对使用通用名称创建大量全局变量的一个很好的论据,但与是否避免伪私有变量无关。例如,我的香蕉销售网站可能会使用假私有变量window.BANANA_STORE_MODULE.cart.__cart_item_array。这个变量不会被第三方脚本意外覆盖并非完全不可能,但这种情况极不可能。

  • javascript的未来修改ideas floating around,可提供受控环境,不受信任的代码可以按照规定的方式行事。我可以通过特定的公开方法让不受信任的第三方javascript与我的javascript交互,并阻止第三方脚本访问HTML等。如果存在这种情况,则可能是私有变量对于安全性至关重要的场景。但它还不存在。

  • 编写清晰且无错误的代码显然对安全性有帮助。只要真正的私有变量和方法能够更容易或更难编写清晰且无错误的代码,就会产生安全隐患。它们是否有用将永远是一个争论和品味的问题,以及你的背景是,例如,C ++(私有变量是中心)与Python(私有变量不存在)。双向都存在争议,包括着名的博客文章Javascript Private Variables are Evil

就我而言,我将继续使用假隐私:一个主要的下划线(或其他)向我和我的合作者表明某些属性或方法不属于模块的公共支持接口。我的虚假隐私代码更具可读性(IMO),我可以更自由地构建它(例如,一个闭包不能跨越两个文件),我可以在调试和实验时访问那些假私有变量。我不会担心这些程序比任何其他JavaScript程序更不安全。