这是一个创建于 807 天前的主题，其中的信息可能已经有所发展或是发生改变。
之前 Windows 下 Chrome 被盗密码和 cookie 的贴还挺多的，本身 Chrome 的安全原则就没有考虑过用户模式被攻破的情况，但似乎有了转机，无意中发现 Chromium 开发者其实正在测试基于应用的密码加密（存进系统密码库前 chrome 先一步加密密码和 cookie ）
相关 issue
https://bugs.chromium.org/p/chromium/issues/detail?id=1333461&q=Dpapi&can=2
但是感觉 release 后也许又会被谴责无法一键导入给其他浏览器后造成垄断的问题
相关 issue
https://bugs.chromium.org/p/chromium/issues/detail?id=1333461&q=Dpapi&can=2
但是感觉 release 后也许又会被谴责无法一键导入给其他浏览器后造成垄断的问题
 |
1
geelaw 2022-09-12 18:11:25 +08:00
这个做法到底在保护什么并不明确。
如果 Chrome 以用户 A 的身份运行，那么用户 A 身份运行的其他程序都可以向其中注入代码，因此验证进程对应的可执行文件路径无法保证运行的代码全部来自该可执行文件。 另外这个功能看起来需要以 SYSTEM 身份运行 Chrome 代码，除了以 SYSTEM 身份运行代码本身相当不安全之外，这会导致安装 Chrome 时（或者运行的时候）必须提权——现存的设计允许 Chrome 以非管理员身份安装和运行，这显然是巨大退步。 |
 |
2
shinsekai 2022-09-12 20:42:27 +08:00  2
为啥不能学习 firefox 上架商店，直接在沙盒中运行，这不就解决了问题
|
 |
3
kkocdko 2022-09-12 23:25:06 +08:00
唉，对应用开发者的约束确实是很有必要的，容器化 / 沙盒化 才是安全的未来。
|
 |
4
nyxsonsleep 2022-09-12 23:46:27 +08:00
@fansvista 不太了解沙盒细节，为什么在沙盒中运行就避开了，密码安全呢？
|
 |
5
geekvcn 2022-09-13 05:18:54 +08:00
@nyxsonsleep namespace 都隔离开了，没有绝对的安全，只能说不会中个木马密码随便读，起码得高手利用漏洞或者侧信道攻击才能攻破，高手又不屑于攻击普通用户，有软硬件漏洞直接卖暗网或者找谷歌微软领奖。
|
 |
6
hez2010 2022-09-13 09:16:27 +08:00 via iPad
何必呢，直接存储到系统自带的安全位置不就行了。比如 Windows credentials manager
|
 |
7
asm 2022-09-13 10:07:16 +08:00
没啥吊用，就是想法自己做个密码保护呗，问题是 cookie 需要实时使用，这一加密解密，性能肯定更不上。涉及本机安全，本机已经沦陷了，整那么多都是徒劳。
|
 |
8
SekiBetu 2022-09-13 11:13:05 +08:00
chrome 密码泄漏了， 才知道用 chrome 保存密码等于裸奔
https://www.v2ex.com/t/872745 |
 |
9
ysc3839 2022-09-13 19:05:51 +08:00
个人认为主要问题还是操作系统没有提供应用级的权限管理，目前三大桌面操作系统中只有 macOS 默认有应用级的权限管理。
|
 |
11
nothingistrue 2022-09-14 11:36:27 +08:00
@ysc3839 #9 苹果的生态都是靠封闭来控制安全的，Windows 跟 Linux 系压根不可能用那种方式。纯 UWP win10 商店前车之鉴。而 Win10 mobile 前车之鉴也决定了微软短期内不会抛弃现有的 windows 生态去另行搞一份类似 macOS 的生态。
|
|
12
ysc3839 2022-09-14 11:54:17 +08:00
@nothingistrue 应用级权限管理并不等于封闭，Android 也在用这种模式，你觉得它封闭吗？
macOS 也不是非常封闭，至少是有 root 权限，以及允许加载内核扩展的。 UWP 的失败不能说明应用级的权限管理是失败的，相反，我认为 UWP 在桌面 Windows 失败是因为微软一刀切。macOS 在引入新 API 时仍然保留了传统好用的 POSIX API ，同时 macOS 和 iOS 的 API 不是完全通用的，而是根据桌面端和移动端不同的应用场景、界面操作做了区分的。而 UWP 则是一刀切强行统一桌面端和移动端，把桌面端传统好用的 Win32 API 直接砍掉，我认为微软此举是通过限制 API 能力来让开发者“自动”为其移动端进行开发，这才是开发者用脚投票拒绝在桌面平台使用 UWP 的原因。以微软的能力完全可以实现传统与现代 API 混合、权限逐步收紧，渐进式地进行更新。 |
|
13
nothingistrue 2022-09-14 15:13:32 +08:00
@ysc3839 #12
Android 的应用权限管理，也就是个应用权限管理，有那么点安全，但整体安全性是个屎。本主题讨论的是跨应用文件保护问题，这点上 Android 连它基于的 Linux 的用户文件隔离都没有，根本没法保护。而就算 Android 官方系统把应用沙盒特性给做好了，OEM 可以不上这个特性，各种国产 APP 有各种方式可以绕过这个特性，在 Android 这种非封闭生态下，安全性需要多方协作才能保证，光靠操作系统一方根本不可能保证。 第二段，说了那么多没说到点上。第一，UWP 可以不适配移动端，只适配桌面端的 UWP 多的很。第二，Win32 API 从来没有被砍，它的限制只是不能上架商店，以及不能使用 Win10 新增的相机、位置这些移动端才需要用的 API 。第三，UWP 的失败，主因是它能被自家的 Win32 应用或 Web 应用随意替代，换句话说，是因为 Windows 生态太开放。 |
|
14
ysc3839 2022-09-14 16:24:22 +08:00
@nothingistrue 本主题讨论的是跨应用文件保护问题，Android 难道保证不了应用数据安全的问题吗？ Android 的其他权限，如录音、录像、录屏权限能绕过吗？
UWP 可以不适配移动端，但微软这种设计显然是想开发者自动适配移动端，因为 UWP 中桌面独有的 API 很少，很多界面元素也是为触屏设计的，开发者写一个桌面应用，很容易甚至无需改动就能在移动端上运行。 我说 Win32 API 被砍指的是 UWP 应用中被砍了，隔壁 macOS 应用仍然可以调用 POSIX API 去打开文件，去启动新进程，但 UWP 应用给吗？甚至反过来，一个非 UWP 的 Win32 应用想使用 UWP 的 XAML UI ，在很长一段时间都是不可行的，直到微软推出了 Xaml Island 。隔壁 macOS 新旧 API 都兼容，也不见怎么失败。所以我说 UWP 失败的原因是它一刀切，而一刀切的原因是要强迫开发者开发出来的应用能自动兼容移动端，因为如果不砍掉旧的 API ，开发者们就会像 macOS 那样新旧 API 混用，享受新 API 带来的爽的开发体验的同时不给移动端做半点贡献。 微软曾经也做过类似的事情，Windows Vista 时代，一些操作系统已经开始提供丰富好用的 API 了，比如 macOS 的 Cocoa ，当时传言微软要把.NET 做成 Windows 的基础部分，结果 Vista 发布后大家发现.NET 仅仅是随系统附带了，没有与系统深度集成，Windows 中并没有多少应用是使用.NET 开发的。微软甚至不给.NET 提供 Win32 API 的声明，想用.NET 调用底层 API 的话还得自己参照文档写声明，虽然.NET 加入了 WPF 这个全新的界面库，但是整个.NET 整得像是个二等公民，像是独立的岛屿。微软自己在 Vista 中加入了一套私有的界面库，但是却不肯公开出来，言下之意是你想开发得爽就去用我们的.NET 和 WPF 吧，给我们的.NET 做贡献。这个操作可以说是进一步推动了 Windows 开发框架的碎片化。 |
 |
15
mmdsun 2022-09-14 21:22:21 +08:00 via iPhone
@nothingistrue Windows 安全体系很完善，只是开发者用的少。https://docs.microsoft.com/zh-cn/windows/security/
|
|
16
mmdsun 2022-09-14 21:27:18 +08:00 via iPhone
这不属于浏览器安全的保护范围，这根本上是病毒。
我在 github 上面下载的各种窃取密码历史浏览记录软件，无一例外例外，都被 Windows defender 识别为病毒。 https://github.com/moonD4rk/HackBrowserData ，里面打包的 exe Windows defender 秒提示病毒：Trojan:Win32/Wacatac.H!ml |
Select Language