本地存储可以被认为是安全的吗?

时间:2013-06-24 16:29:35

标签: html5 security local-storage html5-appcache owasp

我需要开发一个可以长时间离线运行的Web应用程序。为了使其可行,我无法避免在本地存储中保存敏感数据(个人数据,而不是您只存储散列的数据类型)。

我接受这不是推荐的做法,但是我没有做出什么选择,而是采取以下措施保护数据:

  • 使用stanford javascript加密库和AES-256加密所有进入本地存储的内容
  • 用户密码是加密密钥,未存储在设备上
  • 通过ssl
  • 从单个受信任服务器提供所有内容(在线时)
  • 使用owasp antisamy项目验证进出服务器上本地存储的所有数据
  • 在appcache的网络部分,不使用*,而是仅列出与受信任服务器连接所需的URI
  • 通常尝试应用OWASP XSS备忘单中建议的指南

我很欣赏魔鬼经常处于细节之中,并且知道对于本地存储和基于javascript的安全性存在很多怀疑。任何人都可以评论是否有:

  • 上述方法的根本缺陷?
  • 这些缺陷的任何可能的解决方案?
  • 当html 5应用程序必须长时间离线运行时,是否有更好的方法来保护本地存储?

感谢您的帮助。

6 个答案:

答案 0 :(得分:65)

WebCrypto

客户端(浏览器)javascript中的加密问题详述如下。除了其中一个问题之外的所有问题都不适用于WebCrypto API,现在是reasonably well supported

对于离线应用,您仍必须设计并实施安全密钥库。

除此之外:如果您使用的是Node.js,请使用内置的crypto API。

Native-Javascript Cryptography(pre-WebCrypto)

我认为主要关注的是对您的网站localStorage有物理访问权限的人,并且您希望加密技术有助于阻止该访问。

如果某人有物理访问权限,您也可以接受其他攻击并且比阅读更糟糕。这些包括(但不限于):键盘记录程序,脱机脚本修改,本地脚本注入,浏览器缓存中毒和DNS重定向。这些攻击仅在用户使用机器受到攻击后才能使用。然而,在这种情况下的物理访问意味着你有更大的问题。

所以请记住,如果机器被盗,本地加密有价值的有限情况就会出现。

有些库可以实现所需的功能,例如: Stanford Javascript Crypto Library。但是有一些固有的弱点(正如@ ircmaxell的回答中提到的那样):

  1. 缺少熵/随机数生成;
  2. 缺少安全密钥库,即私钥必须受密码保护,如果存储在本地,或存储在服务器上(禁止离线访问);
  3. 缺少安全擦除;
  4. 缺乏时间特征。
  5. 这些弱点中的每一个都与加密折衷的类别相对应。换句话说,虽然你可能有'#34;加密"按名称,它将远远低于人们在实践中所追求的严谨性。

    所有这一切,精算评估并不像" Javascript加密是弱的,不要使用它"。这不是认可,严格意义上的警告,它要求您完全理解上述弱点的暴露程度,您所面临的载体的频率和成本,以及您在发生故障时的缓解或保险能力:Javascript加密,尽管存在缺点,可能会减少您的曝光率,但仅限于技术能力有限的盗贼。但是,您应该假设Javascript加密对于定位该信息的坚定且有能力的攻击者没有任何价值。有些人认为调用数据并加密#34;当已知许多弱点是实施所固有的。换句话说,您可以略微降低您的技术风险,但会增加您的披露财务风险。当然,每种情况都不同 - 而减少技术风险敞口的分析也是非常重要的。这是一个说明性的类比:Some banks require weak passwords,尽管存在固有的风险,因为他们从弱密码中获得的损失小于支持强密码的最终用户成本。

    如果您阅读最后一段并且想到了#34;互联网上的一些名叫Brian的人说我可以使用Javascript加密", 不使用Javascript加密。

    对于问题中描述的用例,用户加密本地分区或主目录并使用强密码似乎更有意义。这种类型的安全性通常经过充分测试,广泛信任并且通常可用。

答案 1 :(得分:55)

嗯,这里的基本前提是:不,它还不安全。

基本上,您无法在JavaScript中运行加密:JavaScript Crypto Considered Harmful

问题在于您无法可靠地将加密代码加载到浏览器中,即使可以,JS也不能让您安全地运行它。因此,在浏览器具有加密容器(加密媒体扩展提供,但为了其DRM目的而被反对)之前,将无法安全地进行加密。

就“更好的方式”而言,现在还没有。您唯一的选择是以纯文本格式存储数据,并希望获得最佳效果。或者根本不存储信息。无论哪种方式。

或者,如果您需要那种安全性,并且您需要本地存储,请创建自定义应用程序......

答案 2 :(得分:12)

作为对此主题的探索,我有一个题为"使用Web Cryptography API保护TodoMVC的演示文稿" (videocode)。

它使用Web Cryptography API存储在localStorage中加密的待办事项列表,密码保护应用程序并使用密码派生密钥进行加密。如果您忘记或丢失了密码,则无法恢复。 (免责声明 - 这是一个POC,不适合生产使用。

正如其他答案所述,这仍然容易受到客户端计算机上安装的XSS或恶意软件的影响。但是,当数据存储在服务器上并且应用程序正在使用时,任何敏感数据也将存在于内存中。我建议离线支持可能是引人注目的用例。

最后,加密localStorage可能只会保护数据免受只读系统或其备份访问的攻击者的攻击。它为OWASP Top 10项A6-Sensitive Data Exposure添加了少量的防御深度,并允许您回答"这些数据是否长期以明文形式存储?"正确。

答案 3 :(得分:3)

这是一篇非常有趣的文章。我正在考虑实施JS加密,以便在使用本地存储时提供安全性。绝对清楚的是,这只会在设备被盗(并且正确实施)时提供保护。它不能提供针对键盘记录器等的保护。然而,这不是JS问题,因为键盘记录器威胁是所有应用程序的问题,无论其执行平台(浏览器,本机)如何。至于文章" JavaScript Crypto Considered Harredful"在第一个答案中提到,我有一个批评;它表明"您可以使用SSL / TLS来解决这个问题,但这种情况既昂贵又复杂[&34;我认为这是一个非常雄心勃勃的主张(可能还有偏见)。是的,SSL有成本,但是如果你考虑为多个操作系统开发本机应用程序的成本,而不是仅仅由于这个问题而基于网络,那么SSL的成本变得无关紧要。

我的结论 - 有一个客户端加密代码的地方,但是与所有应用程序一样,开发人员必须认识到它的限制并在适合他们的需求时实施,并确保有减轻它的方法&#39风险。

答案 4 :(得分:1)

任何网页都无法访问(true),但可以通过开发工具轻松访问和轻松编辑,例如chrome(ctl-shift-J)。因此,在存储值之前需要自定义加密。

但是,如果javascript需要解密(验证),那么解密算法就会暴露出来并且可以被操纵。

Javascript需要一个完全安全的容器,并能够正确实现仅供js解释器使用的私有变量和函数。但是,这违反了用户安全性 - 因为跟踪数据可以不受惩罚地使用。

因此,javascript永远不会完全安全。

答案 5 :(得分:-25)

没有

localStorage可以通过任何网页访问,如果你有密钥,你可以更改你想要的任何数据。

话虽如此,如果您可以设计一种安全加密密钥的方法,那么传输数据的方式并不重要,如果您可以在闭包内包含数据,那么数据(有些)是安全的。 / p>