我们计划为我们的公共 web 应用程序提供用 javascript 编写社区驱动扩展的可能性,并让人们自定义他们的应用程序实例。问题是监控扩展的质量。
你会建议如何自动化这个过程?
或者如何扫描 Javascript 中的恶意代码?
简而言之,我们希望有一些像杀毒软件这样的服务,可以实时扫描上传的扩展是否是恶意的。如果它检测到任何可疑代码,它会生成警报。
欢迎任何提示/建议!谢谢你。
我们计划为我们的公共 web 应用程序提供用 javascript 编写社区驱动扩展的可能性,并让人们自定义他们的应用程序实例。问题是监控扩展的质量。
你会建议如何自动化这个过程?
或者如何扫描 Javascript 中的恶意代码?
简而言之,我们希望有一些像杀毒软件这样的服务,可以实时扫描上传的扩展是否是恶意的。如果它检测到任何可疑代码,它会生成警报。
欢迎任何提示/建议!谢谢你。
一种方法是为要使用的扩展定义一个安全的 API,方法是在扩展的执行范围内声明实现该 API 的对象。然后要求扩展代码以沙盒版本的 Javascript 编写,因此扩展代码只能调用您定义的安全 API 方法,仅此而已。
因此,如果您的 API 包含存储在变量中的对象api
,那么代码:
var x = api.frob();
x.bar();
将被允许扩展代码,因为api
它是您的安全 API 的一部分,并且安全的 Javascript 变体允许您调用暴露给扩展代码的 API。
但是,代码:
document.createElement("img");
不会被允许,因为document
它不是您的安全 API 的一部分。
在设计 API 时,请确保没有暴露的对象具有可能被恶意使用的属性。要限制对资源的访问,请使用闭包来创建私有引用资源的函数。
有许多项目已经定义了沙盒版本的 Javascript,您可以将其用于此目的:SES、Caja、ADsafe、FBJS等。SES 和 Caja 让开发人员编写代码时限制最少:感觉很像只是编写 Javascript,但有一些小限制(例如,no eval
、nowith
)。ADsafe 和 FBJS 要求开发人员学习 Javascript 的变体。SES、ADsafe 和 FBJS 的性能最好。SES 需要最新 Javascript 引擎的支持,因此与一些较旧的 Web 浏览器不兼容。如果扩展代码将在服务器端执行,那么 SES 可能是最好的选择,因为您可以确保您的 Javascript 引擎是最新的。如果扩展程序要在用户的浏览器上执行,如果扩展程序不是性能关键,您可以考虑 Caja,或者如果是 ADsafe/FBJS。
没有很好的方法来扫描 Javascript 中的恶意代码。你不能这样做。问题是恶意/流氓开发人员可以通过多种方式在他们的代码中隐藏恶意内容,而您将永远无法全部检测到。
防病毒在这里没有帮助。您需要了解一点防病毒软件的工作原理及其局限性。粗略地说,这是它的工作原理。如果反病毒公司检测到病毒感染了许多机器,那么他们会分析病毒,识别病毒的签名(例如,其代码的摘录),并将其构建到他们的引擎中。此后,如果您的计算机被该特定副本的副本(与他们分析的完全相同)感染,则防病毒软件将通过此签名检测其存在。因此,反病毒软件主要只对广泛传播的病毒有用。现有的防病毒软件不会检测到您的 web 应用程序的恶意扩展程序中的恶意代码。杀毒软件有一些用处,但对于你的特定场景基本没用。
您需要接受这不是您可以通过扫描代码来解决的问题。因此,您需要考虑其他一些方法。你有什么选择?有几种:
你可以放弃并拥抱混乱。您可以为扩展创建一个公共站点,允许用户对扩展进行评分,以及发布/查看评论。这样,如果开发人员发布了一个有缺陷或崩溃的低质量扩展程序,注意到它的用户可以发布负面评论。(当然,如果开发人员是恶意的并发布了恶意扩展,则无法保证任何人都会注意到——如果你幸运的话,也许有些用户会碰巧注意到恶意代码并报告给你,但它是就像没有人会注意到一样。这就是你冒的风险。)
这被称为具有开放式扩展系统。参见例如 Android Market 或 Google Chrome Extension Gallery 或 Userscripts.org(一个 Greasemonkey 扩展站点)。
您可以建立某种审查系统,让专家在公共扩展站点上发布(或发布后不久)每个扩展之前对其进行审查。如果您只是想发现质量问题,让专家安装扩展程序并对其进行测试可能就足够了,也许还可以运行代码质量错误查找工具来扫描常见问题。如果您还想捕获恶意扩展,则审阅者需要是能够阅读代码并逐行阅读扩展的开发人员;这是非常乏味和耗时的,但实际上没有更好的选择。
这被称为具有策划的扩展系统。例如,请参阅 Apple iOS App Store 或 Firefox 扩展站点 (addons.mozilla.org) 获取一些示例,尽管我相信它们只关注代码质量而不是检测恶意。
无论您采用哪种方法,从单个公共扩展站点提供的扩展都具有显着优势,该站点托管扩展的权威版本。您可能希望采取各种步骤来鼓励用户从该站点安装扩展程序,并阻止他们从其他站点安装扩展程序(例如,默认情况下禁用从其他来源安装扩展程序并要求用户单击以授权他们想要的任何其他域安装,就像 Firefox 一样)。有什么好处?这样做的好处是,这可以确保您的所有用户都获得相同的扩展副本。它可以防止攻击,例如,恶意网站使用一些脚本来检查用户的浏览器版本和用户来自哪里,并以此为基础,决定是提供恶意代码还是合法代码——这些类型的攻击使得检测恶意变得更加困难,所以阻止它们是一件好事。它还确保用户获得评论和评级的好处。
您还应该仔细考虑哪些 API 暴露给扩展,哪些没有。您可能会考虑仅将 API 的一个子集公开给扩展,以便扩展在本质上受限于它们可以做的事情,以此来限制损害。例如,Chrome 浏览器允许扩展程序与网页的 DOM 和网站交互,但不允许扩展程序执行本机代码(例如,安装和运行 .exe)。这种事情有助于安全。或者,您可以提供一个基本 API 来避免最高风险的 API,然后要求任何需要访问超过基本 API 的扩展必须首先获得版主的批准,然后才能发布到公共站点上。
另一种针对恶意扩展的可能防御措施是引入权限系统。您确定一组权限。扩展需要包含一个清单,它指定了它需要的权限集。当用户安装权限时,系统应该向用户显示扩展程序正在请求的权限集以及这些权限意味着什么(例如,它们带来的安全/隐私风险,它们授予扩展程序的访问权限),允许用户要么批准权限并继续安装,要么拒绝权限并取消安装。这为用户提供了对扩展的更多控制和可见性,降低了错误扩展的风险(因为扩展中的安全漏洞的后果现在仅限于它请求的权限,而不是所有权限),并且可能使恶意扩展更加明显(因为它们需要请求某些权限才能造成伤害)。例如,请参阅 Android 应用程序或 Google Chrome 扩展程序以获取此类示例。
(不要尝试推出自己的卫生方案。鉴于 JavaScipt 的复杂性,家庭烹饪的卫生设施可能不安全。使用已经过充分审查的现有解决方案。)
Google 的 Caja 编译器是一种工具,可让第三方 HTML、CSS和 JavaScript安全地嵌入您的网站。
如果我没记错的话,它是用于 iGoogle 的,因为只是将不受信任的代码分成iframe
s 仍然有缺点。
我不知道这是否可以轻松自动化,我同意@jfriend00 和@slhck 关于成功筛选这些Javascript 的一般难度。话虽如此,我知道至少有一种工具可以尝试检测恶意脚本。
这个工具是Wepavet,由加州大学圣巴巴拉分校运营。是这样描述的:
Wepawet 是一个用于分析基于 Web 的威胁的框架。Wepawet 能够确定访问网页是否会导致试图破坏访问者的环境。