桌面应用程序的同源策略?

信息安全 沙盒 同源策略 桌面
2021-08-24 18:05:47

同源策略是我们浏览器中最重要的安全功能之一

它基本上为保护我们用户的应用程序提供沙盒。

桌面应用程序可以读取您计算机上的任何内容。如果您错误地安装了恶意应用程序,它可能会开始读取您不想在计算机上与其共享的文件。例如,它可以窃取您的 cookie(有足够的权限?)并在网站上冒充您。

所以,我想知道:

桌面应用程序是否有类似的同源策略?

似乎它可以解决桌面上的许多安全问题。

目前,如果您访问恶意网站,例如冒充 google 的网站,您不会永远受到威胁。当你离开恶意网站时,你又好了。如果你没有在上面做任何危险的事情,比如输入你的谷歌登录信息,那么你就没有发生任何不好的事情。

相反,如果您安装恶意桌面应用程序,我认为这相当于加载恶意网页,您的所有数据和系统都会受到损害。通常,您可能需要完全格式化然后重新安装计算机上的所有内容,以摆脱该恶意应用程序(病毒)。

在我看来,如果任何应用程序,包括病毒,默认受同源策略限制,你可以在你的计算机上安装许多病毒,不知情的用户经常这样做,就像他们经常访问恶意网页一样,你仍然可以.

其他有用的问题

为什么 Windows 中的应用程序没有沙盒化?

如何限制应用程序可以对我的计算机执行的操作?

4个回答

在我看来,您正在讨论两件事:桌面上的沙盒,然后是沙盒应用程序中用户内容访问的策略。

沙盒

有许多沙盒模型,包括操作系统使用的模型:

  • Windows 8 WinRT 应用商店应用
  • OS X 沙盒商店应用
  • iOS 应用
  • 安卓应用

一些应用程序是沙盒化的,例如 Chromium(在 Linux 上使用 seccomp2/BPF,在 Windows 上使用完整性级别)、Acrobat Reader 和 Microsoft Office(通过受保护的视图,见下文)等。以及强制特定应用程序被沙盒化的工具,例如 Sandboxie (Windows)、mbox (Linux) 等。此外,还有大量或多或少具有功能的研究原型……

沙盒本质上限制了应用程序执行 IPC、访问用户数据、检查其他进程、执行可能危险的系统调用、访问系统以及限制几个额外的 API(例如访问设备功能)的能力。它们几乎总是依赖于系统调用接口插入(seccomp/BPF/Capsicum)、针对特定 API(例如 WinRT)或强制访问控制(SELinux-sandbox、Android?)等构建/链接,并结合能力/权限系统访问危险接口(设备上限、某些形式的 IPC 或文件访问、网络访问......)。这些功能可以在安装时获得(不好:人们并不总是审查它们,通常不能撤销它们,例如 Android),在运行时通过提示(不好:没有人阅读它们)或通过受信任的 UI 元素(好!参见电源盒、UDAC、指定安全性,现在部分在 Windows 8、OS X 上实现,并将成为 Linux GNOME 沙盒模型的一部分)。有时对文件系统的访问是通过分层文件系统管理的,这样应用程序就不会注意到强加于它们的限制(例如,mbox、Linux 命名空间)。

话虽如此,与沙盒性能有关的主要问题是开发人员构建沙盒应用程序的能力,以及沙盒模型准确地将应用程序限制为实际所需的最低权限的能力。

例如,在所有现有的操作系​​统沙盒(Win、OS X、iOS、Android)上,应用程序可以永久访问它们曾经打开的所有用户文件(例如 WinRT 中的 futureAccessList,它允许您重新打开您之前看到的每个文件/文件夹)。这意味着破坏合法应用程序可能会让您访问与其相关的所有文件。这与同源策略形成鲜明对比,在同源策略中,应用程序只能访问与其之前操作过的任何内容相关的内容:您使用精心制作的文件或数据包破坏应用程序应该只会让您获得访问权限到已在同一会话中访问的数据或从下载数据/发送网络数据包的域访问的数据。

桌面沙盒中的一些模型接近 SOP

Windows 应用程序的受保护视图:某些应用程序(例如 Office 和 Reader)可以创建受限隔间,在这些隔间中它们会打开被视为可疑的文件。由于不允许此类隔间与主 UI 交互,因此大多数应用程序的功能都被禁用:文件是只读的,并不总是可打印的,等等。用户必须单击主 UI 中的一个按钮才能使文件读写并启用这些功能,从而基本上消除了所有保护。该模型的假设是:

  • 内容很少需要编辑,并且经常需要查阅(在很多情况下可能是这样)
  • 当恶意文件是恶意文件时,用户会注意到自己,只要看到它(这根本不是真的:))

如果文件是从非白名单域下载的,或者附加到不属于您联系人的人的电子邮件中,则文件被视为可疑文件。这对一些企业用户很有效,但不是对所有人都适用,一些用户一直在询问如何禁用受保护的视图。

基于内容的隔离这仅仅是微软研究院开发的面向服务的操作系统的理论模型。关于正在开发什么以及用于什么的信息很少,这可能不是您感兴趣的。实际上,他们的论文提供了非常明确的论点,为什么基于内容的隔离将成为一个热门话题,以及它可以期待什么提供。

Qubes OS Qubes OS 是基于 Xen VMM 的活动隔离操作系统。它允许用户创建和命名可以运行应用程序集的虚拟机,并在定制的桌面环境中合并不同虚拟机的界面。它提供了现代桌面很少的典型功能,但具有非常强大的安全模型,尤其是 wrt。对操作系统组件的硬件和低级攻击。

它的主要问题在于它是模态的:用户必须始终记住应用程序在哪个 VM 中运行,并确保永远不要将 VM 混合在一起以避免破坏其安全模型。他们还必须自己管理应用虚拟机之间的文件同步。对于大多数用户来说,这是 HCI 中的典型禁忌,Qubes OS 开发人员只为那些有安全动机并愿意维护其安全模型的人宣传他们的操作系统。Qubes OS 是隔离内容而不仅仅是应用程序的最先进的操作系统原型。

更多实验模型包括PIGA OS,它使用基于 SELinux 的 MAC 执行系统来防止不需要的信息流。借助名为ContextD的组件,它可以使用新策略即时重新配置,假设有些人用 PIGA 自己的 MAC 语言为用户必须可用的每个活动编写策略。用户无法更新策略,实际上用户甚至无法看到正在执行的策略。他们一次只能在整个操作系统上执行一项活动,而不是每个应用程序都有活动。PIGA OS 不能在生产中使用,它是作为 OS 安全竞赛的研究原型开发的。我参与了围绕它开发一些工具,团队对开发技术基础设施比开发用户界面更感兴趣。威胁模型明确将用户视为对手。我认为该项目不会继续进行。

最后,另一个研究团队目前正在为 Android开发Bubbles如果我记得很清楚,它使用 Linux 命名空间来隔离应用程序或应用程序组。它提供了一些 UI 用于管理不同的“社交环境”并与参与这些社交环境的联系人共享数据。该模型非常面向协作信息共享和通信,这是一种典型的移动工作流程,而不是桌面(存在更复杂的工作流程)。我对此感到遗憾的是,没有关于这些社会背景如何随着时间的推移而出现和管理的愿景,这使我们...

为什么这么难?

围绕识别可以在同一容器中组合和隔离的内容的主要问题是与人们对其活动的结构和背景的意识有关的问题,他们有多大能力和意愿做出努力管理他们作品的准确表示(以及可以通过他们执行计算的方式向他们提供什么以补偿这些成本),计算机如何管理与人类同等的意义,如何在复杂的界面中处理模式,如何考虑到人类行为的位置性以及用户在日常使用计算机时经常跨越安全边界的需求,如何处理短暂或新兴的活动等等。

这些都是困难、复杂的人机交互研究课题一些相关读物包括 Bardram 的基于活动的计算项目、活动理论等理论,以及 HCI 中几乎所有受现象学启发的理论和研究(尤其是情境动作体现交互)。令人惊讶的大多数安全研究(包括“可用安全”研究)假设用户愿意或能够专注于与安全相关的任务并维护准确的安全模型,并且现有问题都可以通过一些 UI 修复和更好的方式解决“安全通信”。他们所做的研究依赖于不同的人类行为理论和不同的研究方法,而不是理解人们如何为他们在计算机上所做的事情创造和维持意义以及理解如何在计算机和转变为安全边界。据我所知,目前没有其他人调查用户体验和隔离机制的使用情况,恐怕我'

我认为这归结为您认为桌面应用程序的“同源”。在忽略某些 Windows 功能的完美世界中:

  • 是一个过程吗?进程 A 无法访问进程 B 内存。
  • 是用户吗?用户 A 无法访问用户 B 的文件。
  • 是用户会话吗?如果您不在 Session 0 中,那么您不是 SYSTEM。

所以我认为沙盒化桌面应用程序有点与桌面模型相反,只是因为应用程序应该与系统的其他部分交互(通常是间接的)。浏览器/Web 应用程序不应该与系统进行这种交互,因此沙盒更加可行。

要回答您的问题,如果您想对桌面应用程序进行沙盒处理,我认为您必须使用虚拟机。 病毒可以突破那个沙箱吗?这是可能的。但更多的是不太可能发生的事情。

这就是我对事情的看法。

回到问题的另一个方面:Same-Origin-Policy 是一个重要的安全边界,理论上听起来不错。但是,与其他安全边界一样,它经常受到阻碍,因此在实践中经常被解决。

最常见的解决方法是将第三方方作为脚本包含在内。广告、跟踪或社交网络通常包含在脚本中(而不是 iframe),因此可以完全访问 DOM。他们可以做页面来源可以做的任何事情,从而破坏了 SOP。

Windows 商店应用程序的文件访问权限

来自应用商店的 Windows 应用程序在您的系统上的文件访问权限有限。这有点类似于同源策略,因为它们只能访问以下文件:

  • 他们的安装目录
  • 应用程序数据位置
  • 可移动设备(仅限于您在应用程序中指定的某些文件类型)
  • 下载文件夹(只能自己下载)
  • 应用程序清单中指定的额外位置...

我想这并不完美,但这是一个好的开始。