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

Question

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

use*_*706 147 security html5 owasp local-storage html5-appcache

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

我接受这不是推荐的做法,但是我没有做多少选择来保护数据:

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

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

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

谢谢你的帮助.

Answer 1

Bri*_*unt 67

WebCrypto

客户端(浏览器)javascript中的加密问题详述如下.除了其中一个问题之外的所有问题都不适用于WebCrypto API,现在可以得到相当好的支持.

对于脱机应用程序,您仍必须设计并实现安全密钥库.

旁白:如果您使用的是Node.js,请使用内置加密 API.

Native-Javascript Cryptography(pre-WebCrypto)

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

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

因此请记住,本地加密有价值的有限情况是机器被盗.

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

缺少熵/随机数生成;
缺少安全密钥库,即私钥必须受密码保护,如果存储在本地,或存储在服务器上(禁止离线访问);
缺乏安全擦除;
缺乏时间特征.

这些弱点中的每一个都与加密折衷的类别相对应.换句话说,虽然你可能通过名字"加密",但它将远远低于人们在实践中所追求的严谨性.

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

如果您阅读最后一段并想到"互联网上的某个名叫Brian的人说我可以使用Javascript加密",请不要使用Javascript加密.

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

Answer 2

irc*_*ell 56

那么,这里的基本前提是:不,它还不安全.

基本上,你不能在JavaScript中运行加密:JavaScript加密被认为是有害的.

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

至于"更好的方式",现在没有一个.您唯一的选择是以纯文本格式存储数据,并希望获得最佳效果.或者根本不存储信息.无论哪种方式.

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

@ircmaxell如果你和狗一起睡觉,你不能指望不要用跳蚤醒来.如果用户安装的恶意软件添加与用户在其PC上安装病毒的版本相同,则与之没有什么不同.您的Java或C程序可以像它一样安全,但只要攻击者能够运行代码,您就会被搞砸.这对JS来说并没有什么不同.插件不只是神奇地出现在浏览器中.此外,如果用户有恶意软件,不保存加密的信息将无助于任何方式,因为它可能只是实时劫持数据. (12认同)
@BenjaminGruenbaum:问题是加密代码需要多个地方与第三方代码进行交互.我链接到的那篇文章的重点是你无法控制执行环境.所以你安装了Stanford Crypto lib.那么如果某个浏览器插件覆盖`sjcl.encrypt`以将密钥通过电子邮件发送给攻击者,会发生什么？在JS中,这是100%可能的,你无能为力阻止它.这就是基本点.没有"安全"机制来阻止其他JS对您的数据做出令人讨厌的事情.那是一个**问题**. (11认同)
@ircmaxell不是我,但我不同意这个答案."问题在于你无法可靠地将加密代码加入浏览器中,即使你可以,JS也不能让你安全地运行它." - 为什么？什么是_inherent_问题？您可以使用Stanford JavaScript加密库并在其中加密/解密.你可以哈希,你可以安全地做每件事.我没有在JS中执行标准crpyto的离线应用程序中看到固有的问题,就像使用任何其他语言构建的应用程序一样. (9认同)
@BenjaminGruenbaum:不同意.在正常的应用程序中,您需要**来破坏应用程序本身(读取内存位置),或获得对该框的root访问权限(危及操作系统).无论哪种方式,你需要妥协的东西不仅仅是做正常的行为.JS允许这种行为正常.哪个是问题...... (9认同)
Downvoter:你能提供更好的答案吗？我意识到这是一个有点争议的问题,安全专业人士(以及非专业人士)之间存在重大分歧,因此备用观点值得分享.除非你因为另一个原因而贬低,在这种情况下我怎样才能改善这个答案呢？ (8认同)
@ircmaxell不同意.与普通应用程序一样,您需要妥协应用程序本身(读取其中的本地存储)或获取对"框"(浏览器)的root访问权限.无论哪种方式,你都会比正常行为更妥协.那是完全一样的.在实践中很难安装"错误"的扩展(你得到一个大盒子,你必须在安装时确认,就像在Windows中的UAC或在linux中要求管理员权限).这仍然不是web js的固有问题,当然可以通过精心设计来减轻这种问题. (4认同)

Answer 3

Kev*_*son 12

作为对该主题的探索,我有一个题为"使用Web Cryptography API保护TodoMVC"(视频,代码)的演示文稿.

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

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

最后,加密localStorage可能只保护数据免受只读访问系统或其备份的攻击者的攻击.它为OWASP Top 10项目A6敏感数据曝光增加了少量防御,并允许您回答"这些数据是否长期以明文形式存储？" 正确.

归档时间：	12 年，7 月前
查看次数：	88280 次
最近记录：	7 年，5 月前