VS Code存在安全漏洞？Golang开发者需注意
VS Code存在安全漏洞？Golang开发者需注意 我们许多人都使用基于Electron的VS Code作为Go语言编辑器（包括我在内）。类似这样的漏洞让我思考：将不安全的浏览器作为核心工具的基础是否可靠？
大家对此有何看法？
theckman：
在编辑器中实现跨站脚本的概念远非理想，但如果你使用其他提供插件的编辑器，你是否会审核所有插件以确保其中没有恶意软件？我认为在这些情况下风险是相似的。
确实如此。我不认为我们通常会使用 VS Code 浏览不受信任的网站，但我们却隐式信任安装的任何插件，而这些插件拥有对系统的完全访问权限。
更多关于VS Code存在安全漏洞？Golang开发者需注意的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
如果你使用其他提供插件的编辑器，你会审核所有插件以确保没有恶意软件吗？
不，尽管这是个好主意。所有不在沙箱中运行且能访问主机操作系统的软件都可能造成损害。这类软件的每个插件也同样可能造成损害。
基于 Electron 的应用程序问题似乎在于它们依赖一个嵌入式浏览器，这种浏览器可能存在各种漏洞。这些漏洞似乎不适用于使用其他方式构建用户界面的应用程序。
所有软件都存在安全漏洞的可能性。近年来，浏览器厂商有动力尽可能提高用户体验的安全性。即便是你认为"安全"的浏览器，仍然存在安全漏洞的风险，所以这其实是个伪命题。我认为依赖那些能快速响应安全问题的团队所支持的技术是安全的：
我们还要感谢 Electron 团队能够极速响应并快速向公众提供补丁。
在我的编辑器中存在跨站脚本攻击的想法远非理想，但如果你使用其他提供插件的编辑器，你是否会审核所有插件以确保没有恶意软件？我认为在这些情况下风险是相似的。
与非 Electron 替代方案相比，我对这些编辑器更大的问题是它们隐含的资源消耗需求。
我承认我可能没有完全理解这个漏洞，或许低估了它的严重性。但据我理解，问题在于当我们在 Electron UI 中查看不可信内容时，这些不可信内容可能会执行超出我们预期的操作。然而，在我的 VS Code 界面中显示的内容只有我的代码、插件显示的内容，以及安装程序界面中插件的帮助/自述文件等。后两者可能具有恶意，但这意味着插件本身就是恶意的，这样我们又回到了问题的起点。比如，Go 插件会从 Github 获取十几个不同的程序来为我编译和运行…
但我认为这是整个行业面临的一个严重问题。如今任何小小的 JavaScript 项目都会通过 npm install 引入成千上万个模块，其中任何一个都可能被入侵，有些确实已经被入侵了。即使是一个完全良性的插件，也可能依赖某个在我安装前几小时刚变恶意的模块，那样我就中招了，无论是否存在 XSS。
有人考虑用 Qubes OS 吗？
作为Golang开发者，确实需要关注VS Code这类基于Electron的编辑器的安全问题。Electron框架的安全漏洞（如CVE-2018-1000136）主要源于其允许网页内容访问Node.js API，可能导致远程代码执行风险。不过，VS Code团队已经通过沙箱机制和禁用nodeIntegration等配置来缓解这些风险。
对于Go开发者来说，关键是要确保VS Code配置的安全性。以下是一些具体措施：
- 检查工作区设置：确认
"nodeIntegration": false，这是VS Code的默认设置。可以在.vscode/settings.json中验证：
{
"editor.fontSize": 14,
// 确保没有启用nodeIntegration
}
-
扩展安全性：仅从官方市场安装扩展，定期更新。恶意扩展可能利用漏洞。例如，在Go开发中，只使用golang.go等官方扩展。
-
隔离开发环境：考虑在容器或虚拟机中运行VS Code，限制潜在影响。例如使用Docker：
FROM golang:1.19
RUN apt-get update && apt-get install -y code
- 替代方案评估：如果安全性是首要考虑，可测试非Electron编辑器，如Vim with vim-go或GoLand。例如在Vim中配置：
Plug 'fatih/vim-go'
let g:go_version_warning = 0
实际漏洞利用通常需要特定条件（如加载恶意内容），保持VS Code和扩展更新可大幅降低风险。Go生态中的工具链（如gopls）本身不直接受Electron漏洞影响，但编辑器层面的风险仍需管理。
