用vs2012做网站教程,怎么做关于花的网站,typecho跟wordpress,公司网站建设佛山哪家好依赖, 我们需要它们#xff0c;但如何有效安全地使用它们#xff1f;在本周的节目中#xff0c;Kris 与 Ian 和 Johnny 一起讨论了 polyfill.io 供应链攻击、Go 中依赖管理和使用的历史#xff0c;以及 Go 谚语“一点复制胜过一点依赖”。当然#xff0c;我们用一些不受欢…依赖, 我们需要它们但如何有效安全地使用它们在本周的节目中Kris 与 Ian 和 Johnny 一起讨论了 polyfill.io 供应链攻击、Go 中依赖管理和使用的历史以及 Go 谚语“一点复制胜过一点依赖”。当然我们用一些不受欢迎的观点来结束本集
(译者注: polyfill .js 是一个流行的开源库可帮助旧浏览器支持新浏览器中的功能) 本篇内容是根据2024年7月份#321 Dependencies are dangerous音频录制内容的整理与翻译
过程中为符合中文惯用表达有适当删改, 版权归原作者所有. Kris Brandow: 欢迎收听 Go Time又是新的一周也意味着又有新的一集。我是你们的主持人 Kris今天我们要讨论的是供应链安全和依赖管理。与我一起参与这期讨论的有 Ian 和 Johnny。Ian今天你怎么样
Ian Lopshire: 我很好。
Kris Brandow: 太棒了。
Ian Lopshire: 没什么可抱怨的。
Kris Brandow: 不错。Johnny你今天怎么样
Johnny Boursiquot: 我正在检查我们用的东西是否和 polyfill 有关或者… [笑声] 你知道的只是做个简单的检查。这就是我现在的状态。
Kris Brandow: 只是简单的检查一下代码库… 所以今天我们要讨论几个话题但首先我们要谈的是一个漏洞或者说是一次攻击可以称之为 polyfill.io 的入侵事件。Ian你能给听众简单介绍一下发生了什么吗
Ian Lopshire: 好的当然。polyfill.io 是一个提供浏览器 polyfill 的 JavaScript 库的 CDN。几个月前这个 JavaScript 库的维护者警告不要使用 polyfill.io 的 CDN因为这个 CDN 已经被卖给了另一家公司而他与之无关。最近他们开始注入恶意 JavaScript影响了成千上万的网站包括 Hulu 和 JSTOR 等等。他们被发现重定向到赌博网站影响非常大。所以是的这是个大事件。
Johnny Boursiquot: 当你说到这个我就在想 “CDNCDN”。特别是在前端社区CDN 几乎是主宰。通常任何用于构建应用或发布内容的 JavaScript 库都会有一个 CDN URL因为这是最佳实践。CDN 是全球分布的用户通常离某个节点很近这意味着你的网站或应用加载速度会更快。这就是 CDN 的价值所在。但我想很少有人会停下来仔细检查 CDN因为它们总是在那儿它们总是有效。你看到一个链接比如一个 bootstrap 的 CDN 链接你直接复制粘贴然后就可以用了。你有了 Bootstrap或者你想用的任何库。几乎可以说你默认认为“哦肯定有人为此买单我不需要担心它。我只需要把它包含在我的 JavaScript 或应用中然后继续使用。” 所以现在由于域名所有权的变化突然冒出这样的事情确实很有趣。而且在 npm 社区虽然这不是 npm 独有的事情任何使用这个 polyfill 的人都会受到影响。我猜主要是 JavaScript 库受到影响吧
Kris Brandow: 是的。
Ian Lopshire: 其实不仅仅是 JavaScript 库至少在这次攻击中任何包含这个 CDN 的网站都会受到影响。
Johnny Boursiquot: 对任何人。
Ian Lopshire: 就像如果 jQuery 或 Google Analytics 被攻击或入侵那会影响多少网站对吧
Kris Brandow: 我觉得有趣的是前端 CDN 提供商的最大优势之一就是如果每个人都使用同一个 CDN那么你要使用的库或代码很有可能已经被缓存了所以甚至不需要向 CDN 发起请求加载速度超级快。但这也让它们成为巨大的攻击目标因为它们被包含在那么多的网站上。所以如果你在其中做一个小改动如果你能进入这个 CDN你就可以攻破大量的网站。
但在某种程度上CDN 似乎有点像过去的遗物当然我不是说 CDN 本身而是说用于这种特定用途的 CDN。有点类似于我现在看到的将资源放在不同的子域上似乎也是过去的遗物… 当我们都在用 HTTP/1 时我们一次只能有六个连接你希望所有资源都加载得更快… 而现在有了 HTTP/2 和 /3我们不再那么需要这种做法通常你可以把很多东西压缩得非常小只有在首次加载页面时才会有影响… 所以也许我们继续使用这么多 CDN 的原因之一是我们已经习惯了而不是因为我们真的需要它们。尤其是如果你是一个较小的网站或者类似的情况。所以如果你想在未来更安全一些你也可以考虑不使用 CDN直接从你的域名上提供这些资源或者使用 Google 的 CDN。
Johnny Boursiquot: 那么如果你是一个 Go 开发者这会对你有什么影响呢或者它会影响你吗
Ian Lopshire: 它不会影响你但…
Johnny Boursiquot: 不会直接影响。
Ian Lopshire: 不会直接影响。但供应链攻击的概念确实会影响你作为一个 Go 开发者。我认为 Go 已经做了很多工作让我们不需要太多考虑这些问题但它仍然是需要注意的事情。我们今年已经看到了其他一些非常狡猾的供应链攻击… 如果你听说过那个压缩库的攻击事件…
Kris Brandow: 哦xz
Ian Lopshire: 对。如果你听过 xz 攻击那实际上是有人基本上对维护者进行了网络霸凌指责他们更新不够快然后成功成为了维护者之一… 接着在几年时间里逐渐提交了不同的代码片段最终导致了这次漏洞。
Johnny Boursiquot: 这真是很复杂的攻击。
Ian Lopshire: 是的非常复杂。
Johnny Boursiquot: 谁能说霸凌者没有被别人胁迫交出了他们的 GitHub 账号呢…
Ian Lopshire: 这倒是有可能。
Johnny Boursiquot: …或者其他什么东西。所以可能连原始的维护者都不是。
Ian Lopshire: 考虑到攻击持续的时间确实有可能。但是的百分之百同意。
Johnny Boursiquot: 是的完全有可能。
Ian Lopshire: 是的我们也不知道。但---你们在部署和构建代码时会考虑供应链问题吗
Johnny Boursiquot: 幸运的是我不会在运行时加载这些东西。即使我是在通过 Go 提供一个应用程序---你可以通过 Go 提供一个 Web 应用程序对吧你可以设置一个 HTTP 服务器提供一个静态网站或者任何内容… 所以从某种程度上说如果你通过 Go 提供了一个网站部分 HTML 或 JavaScript 包含了某个库并且你在运行时从 polyfill 的 CDN 加载这些库你可能会受到影响对吧这是你可能会直接受到影响的方式。所以你的 Go 代码本身不会受影响但你提供的前端代码中包含的库可能会受到影响。
因此对于 Go 本身我依赖于 Go 团队采取的措施确保我发布的二进制文件确实是我认为发布的内容。我想你已经链接了关于我们如何在 Go 中防止供应链攻击的帖子。这是 Filippo Valsorda 在 2022 年发布的帖子---我们会在节目笔记中链接这个帖子。所以基本上从构建的锁定、版本管理到构建内容、依赖项的确定性因为我们使用了校验和数据库再到使用代码库中的提交哈希作为真实来源构建代码---构建时不会执行代码这些都是防止攻击的步骤之一。
另外总的来说在 Go 社区中我们非常谨慎不会随便引入随机的包… 或者至少我们中的大多数人不会。至少我是非常严格地审视我导入到程序中的任何包的。我们 Go 社区中很多人都非常认同“少量复制比少量依赖更好”这样的理念。
如果我只需要一个简单的库来做某件小事比如一个实用工具我宁愿找到一个库看看他们是怎么实现的然后实现我自己的版本。或者直接复制我需要的部分附上引用将其放在我控制的包中这样我就知道其中发生了什么。
所以我认为 Go 开发者非常… 让我这样说吧这可能不是一个很受欢迎的观点。我认为平均而言我接触到的 Go 开发者比普通前端开发者更注重安全性。我认为通常来说后端的 Go 开发者比前端开发者更注重安全。这是我的观点我坚持这个观点。
Kris Brandow: 我觉得这有点像路径依赖。我注意到我自己的变化… 我刚开始写 Go 时正值那段混乱的时期那时我们只是“哦你只需 go get 一下”然后它会拉取 Git 仓库中 master 分支的最新代码就是这样。如果它发生了变化导致某些东西坏了那么祝你好运。所以对我们很多人来说依赖项在某种程度上是一种负担因为如果你想回去重新构建一些旧代码而你没有将依赖项打包保存那么在某些情况下你根本无法构建它或者你得花几个小时挖出旧的提交仔细设置你的 GOPATH确保里面有正确的东西。
所以我认为这促使我们作为一个社区减少依赖项而且让这些依赖项更加稳定某种程度上也更小这样它们的变化就不会那么频繁… 然后我们得到了这些其他的东西比如版本控制、稳定的构建以及所有这些加密校验确保依赖项不会在你不知情的情况下发生变化。我认为这巩固了整个流程。而在 Node 或 JavaScript 社区他们走的是一条完全不同的道路他们的路径依赖是“尽可能拉取所有东西不要重新发明轮子使用别人已经编写好的东西。” 这种“骄傲地使用别处的代码”的理念非常普遍。如果有人已经写好了某个功能你就不需要再写一次这是一种完全不同的依赖项管理方式。我认为这些不同的路径导致了现在完全不同的结果… 这在某些情况下确实让 Go 工程师整体上更加注重安全性。但我不确定这两者之间是否真的有直接关系。我觉得它们可能只是并列存在的东西但我确实认为我们之所以很少遇到这些问题是因为我们是一个---我猜可以说是对依赖项不太友好的社区。我们会说“我们的标准库已经很好了。” 依赖项曾经是非常麻烦的事情这种观念已经深植于社区中并将持续到未来。这种情况可能在未来会改变但我认为随着我们引入更多的安全措施这种观念将会继续巩固。
如果我们从一开始就有一个包管理器那么我们可能会遇到 JavaScript 社区或其他许多社区正在面对的那些问题比如包管理混乱无序需要做大量的修复工作才能回到一个稳定的状态。
Johnny Boursiquot: 我们并不是对漏洞免疫的对吧
Kris Brandow: 当然不会。
Johnny Boursiquot: 我一直在反复思考依赖项的问题……很多安全问题和漏洞确实源自于依赖项。每当你引入一个来自第三方的依赖无论你是否熟悉它---而大多数情况下你并不熟悉它……你可能引入的依赖本身也依赖于其他依赖项也许你熟悉你引入的那个依赖的作者但你不熟悉那个依赖所依赖的其他作者……所以每次你引入一个新的依赖时实际上你是在将一大堆东西带入你的项目。那么谁能阻止现在或将来某人在这些依赖中引入恶意代码呢
这样想吧如果我有一个流行的 Go 包而有一天---或者某天有人掌握了我的 GitHub 凭证然后他们决定更新我的包可能利用 OS 包获取你应用程序中的所有环境变量就是你导入了我的包的那个应用程序。我读取了所有环境变量然后发送---或者更准确地说恶意行为者将这些环境变量发送到某处的服务器。就是这么简单。有人可以轻易地获取你所有的环境变量。如果你遵循 12-factor 应用程序方法这在 Heroku 时代很流行通过环境变量配置你的应用程序而且你在其中存储了秘密信息等那么谁能阻止某人获取你所有的环境变量并将它们发送到某个随机的服务器因为你导入了一个你认为只做某件事的库但事实上它做了更多的事情
类似的情况让我对我引入的任何包以及这些包所依赖的包都非常谨慎。所以通常如果我看到一个包中有大量的依赖特别是这个包并不常用……或者说如果我在 pkg.go.dev 上查找某个包我能看到足够的元数据来帮助我做出判断。我可以查看 pkg.go.dev它会告诉我有多少东西导入了这个包有多少包被这个包导入……这些因素都会影响我是否导入这个包的决定。尤其是如果这是一个新的包没有太多活动没有太多人在使用它但它却引入了很多东西……看起来它做的事情比表面上更多……对我来说这些都是我立刻会去检查的信号。我会去这个仓库查看代码看看它到底在做什么然后再决定是否引入它。而且这个包的功能必须足够复杂我自己无法轻松实现。
所以依赖项可能会对我造成伤害---这是一个非常真实的威胁。尽管 Go 社区有各种检查和防范机制来防止恶意代码的引入但如果你主动引入了恶意代码那责任在你。因为你可以去阅读代码你可以至少去检查一下这个包是否在积极维护是否是一个流行的包或者根据你的选择标准进行检查这完全取决于你……应该花些时间去做这些检查。
当然我们不是完美的有些东西可能会被忽视。但你应该养成阅读代码库和源代码的习惯。显然有些库很大你可能无法全部阅读。但你可以依赖一些轶事你可以依赖于这个库有多少人在使用它已经存在了多久是否有人在维护……你可以依赖这些信号来帮助你选择依赖项。所以对我来说随便挑选依赖项并将它们放入你的 Go 程序中---这是一个大忌。
Ian Lopshire: 我认为整个……这曾经是一个有争议的观点……或者说最小版本选择在我们进行包管理讨论时是有争议的。但我确实认为它在这些情况下有所帮助。它使得更新依赖项以及依赖项的依赖项变得更慢了因为它会引入它能找到的最低版本。但我确实认为这样更安全。版本不会自动更新到可能含有恶意代码的新版本……我觉得这很有趣。
Kris Brandow: 但我觉得这取决于更新的内容……如果更新是为了修复一些漏洞你肯定不希望使用旧版本。
Ian Lopshire: 这确实是个双刃剑。
Johnny Boursiquot: 但谁会去检查他们程序中导入的每一个包的每一个更新呢如果项目足够大你真的会逐条检查所有提交确保没有引入恶意代码吗我这么说完全是因为我自己也确实这样做。我会更新依赖项希望能更新到小版本以捕捉补丁和安全更新而不是直接跳到下一个功能版本……但如果项目足够大你真的会去检查所有提交确保它们是安全的吗
Kris Brandow: 我觉得有些东西……我不一定会去检查……如果某个包足够大我会依赖于“维基百科效应”也就是说如果有足够多的人在关注这个包出了问题应该很快就会被发现。那些稍微小一些但有一些人使用的包才是“危险区”。
Johnny Boursiquot: 可疑的。
Kris Brandow: 是的。所以如果它是一个巨大的库并且有很多人关注它我就不会太担心因为即使它是一个更大的攻击目标漏洞被发现的速度会比其他东西快得多。但我确实觉得……我一直以来都有一个不太喜欢的现象那就是软件工程的很大一部分已经变成了配置依赖项而不是自己构建东西……我觉得这确实是一个不太受欢迎的观点你应该尽量自己构建大部分所需的东西。或者至少你应该足够了解它是如何工作的这样你就可以去阅读代码确保它在做你认为应该做的事情。我认为最大的漏洞之一就是当你不知道代码是什么也不理解它应该做什么时。这时可能会有某种漏洞存在而你却觉得“哦这段代码看起来没问题因为我不理解我试图做的这个底层操作。”显然这有一个底线。你不需要去阅读 Linux 内核代码只是因为你想构建一个应用程序。但我认为我们对个人工程师应该审查的内容设定的门槛有点太高了。
我觉得你说得对Johnny---人们确实需要深入到他们的依赖项以及依赖项的依赖项去了解那里发生了什么。如果你不想这样做那也没关系。但你就少引入一些依赖或者找到一种更好的方式来处理它们。我认为这是我们整个行业需要转变的方向这份工作的一部分就是处理安全问题理解你制作的东西里包含了什么。你不能制造产品也不能向人们出售食品如果你不知道其中包含了什么。在大多数其他行业中如果你不知道供应链中的东西人们会认为这是不可接受的。
我们确实批评过其他行业比如服装行业总会有“哦有些可怕的劳动环境问题。我们需要解决这些问题。”作为公司你有责任了解供应链中的这些问题即使它离你有很多环节之遥你也应该了解这些问题并尽快解决。我认为我们也处在类似的境地不管问题出在第几层依赖项上最终你都要为此负责所以你需要确保你的供应链和材料清单是干净的。
Ian Lopshire: 说实话我不会更新依赖项直到检查工具告诉我有漏洞。你真的会定期检查你的大项目并更新每个依赖项吗
Johnny Boursiquot: 我确实做过……对此我有一些“伤痕”。在 OpenTelemetry 的 Go SDK 还在成熟阶段时---那是在我在 Heroku 的可观测性团队工作期间。我们非常早期就开始在 Heroku 采用 OpenTelemetry。所以我们经历了很多变动依赖项不断变化。突然某个包路径不再存在了然后我们必须去找出某个类型现在在哪个位置或者某个特定行为现在被移动到哪个位置……
我们在开始时就知道这一切我们接受了这些变动并尽力去做一些贡献或者理解为什么这些东西会发生变化并尽量减少对我们的影响……但这确实是一个挑战。当时我们知道我们会长期采用 OpenTelemetry我们不想创建一个只有我们自己知道的内部机制因为我们需要更好的可观测性但我们又不想依赖某种内部的、不透明的东西。因为随着团队的变动人员进出他们需要去学习一些难懂的东西。我们更愿意采用 OpenTelemetry因为这是标准世界正在朝这个方向发展。于是我们有意识地走向了这个方向。
但也确实有很多小问题很多小伤口。每当依赖项发生变化时我们不得不更新代码找到那些不再有效的引用之类的东西。
所以是的对于其他我们尽量保持在小版本更新的库我们只做补丁但 OpeTelemetry 是一个例外每次更新我们都得跟进。
Ian Lopshire: 是的我认为对于你知道会发生变化的东西做一些小的改动比一次大规模的破坏性改动更容易。我觉得如果我们从另一个角度来看这个问题会很有趣……如果你想在一个流行的 Go 库中引入漏洞首先这是否可能其次你需要如何去做
Johnny Boursiquot: 我首先想到的是如果你能设法让漏洞数据库或者某个数据库在代码仓库内容发生变化的情况下仍然保持相同的哈希值。如果你能做到这一点你就成功了。因为会发生的情况是---
Ian Lopshire: 这很有趣。
Johnny Boursiquot: 是的。因为会发生的情况是每次新的提交发生时校验和都会发生变化。所以如果你说“嘿版本 1.0.2 在这个仓库中这个提交哈希一切关于这个仓库的内容在这个时间点都有一个特定的校验和。”然后现在你设法保持相同的校验和但仓库的内容已经更改包含了恶意代码。这样你就成功了。因为每个人都会进行检查确认“嘿这些东西对齐了吗校验和和我们基于它进行的安全检查是否一致”“是的你通过了。” 但实际上我们有了新代码---这看起来很不可能。但我们讨论的是那些不应该发生但还是发生的事情对吧
Ian Lopshire: 这真的不可能吗这不就是比特币挖矿的原理吗我们试图追加数据直到哈希值符合预期。你不能这样做吗
Kris Brandow: 我认为现代密码学的基础假设是这不是不可能但它几乎是不可能的碰撞不会发生。
Ian Lopshire: 它可能需要一百万年对吧但你可以做到。
Kris Brandow: 我觉得这有点像 XKCD 的那个漫画某人使用了某种强加密“我们永远无法破解”结果却是“用扳手打他直到他给出密码。”[笑声] 与其试图绕过整个系统不如绕过人类系统或者在人类系统中找到漏洞。
所以你找一个包比如 xz 事件中维护者精疲力尽的情况。你提供帮助慢慢开始参与其中也许在某个无害的提交中你偷偷引入了一个包。你控制的包可能并没有做什么特别复杂的事情。然后它在那里待了很久人们就习惯了它……一段时间后你在其中加入了恶意代码可能是在一个小补丁版本中---你只做了个补丁版本更新没有人真的注意到……尤其是如果这是一个你经常更新的包也许你添加了很多东西你一直在构建它……所以它就这样悄悄地混了过去。也许它是你依赖的某个依赖项的依赖项所以有一些间接性。
然后你在其中加入了一点漏洞代码它就这样传播到所有地方。它只是另一个人们看到的例行更新。你可能不会去检查代码本身因为代码本身看起来没问题。你没有在主要依赖项中引入任何恶意代码它是在某个更远的依赖项中可能很早就被更新了现在才逐渐浮现。所以你真的要追踪很多东西。我觉得如果你有一个大的库包含很多依赖项某人就有机会在其中偷偷引入一些东西。这比试图破解现代密码学更可行。
Ian Lopshire: 是的你几乎必须把它隐藏在显眼处---不实际上你必须把它隐藏在显眼处。我认为这是 Go 的一个优势。比如对于 C 程序你通常会发布一个包含编译后内容的压缩包。所以你可以随意隐藏你想要的东西。
Johnny Boursiquot: [笑]
Ian Lopshire: 我是认真的你可以这么做。
Johnny Boursiquot: 希望它带有校验和。至少可以验证。
Ian Lopshire: 但你不能对 C 代码进行哈希处理确保压缩包中的内容与 C 代码一致因为这不是它的工作方式。那是一个预编译的东西。
Kris Brandow: 哦你的意思是如果你发布了一个---
Ian Lopshire: 比如一个 DLL或者---
Kris Brandow: 是的一个 [听不清 00:32:12.00] 之类的东西。
Ian Lopshire: 是的。老实说我不太清楚它是怎么工作的但我知道你不会发布 C 代码。
Kris Brandow: 是的如果你只是发布了对象代码然后说“哦只需在编译过程中将其链接起来”这样它就成为了---
Ian Lopshire: 没错。我们发布源码而不是预编译的部分这让隐藏东西的空间少了很多。所以你真的得慢慢地在显眼处偷偷引入它。
Kris Brandow: 是的我觉得这是一个优势。但这也意味着我们不能像 C 代码那样发布……我最近开始重新学习 C 编程其中一个我想做的项目是用它来控制我的相机……而 Sony 提供了一个 SDK你可以使用它。他们只是发布了编译好的对象文件。也许它只是一个共享库。但他们会为你的平台发布已编译的代码这样他们就可以为所有人提供 SDK而不必开源它……我认为这是一个有趣的代码共享模式它允许你共享功能而不共享代码……但这确实带来了漏洞你可以在那个对象文件中放入任何你想要的东西它可以做任何事情。不过你也可以使用其他代码扫描技术来发现恶意代码。还有其他的安全技术。在你举的例子中Johnny如果我获取了所有环境变量并将它们发送到某个地方---那么如果你阻止你的进程访问随机的 URL是的你可能获取了所有环境变量但你无法将它们发送出去因为你不被允许访问某些随机的服务器。
所以我认为记住我们可以有其他的保护层这样即使有某种漏洞也不一定会影响我们这一点很重要。我认为在 C 世界里---我不是 C 程序员所以我不知道他们是怎么做的……但在你不能查看所有可能使用的源代码的情况下你被迫使用这些其他类型的保护机制。而我们在 Go 中可能不太倾向于使用这些机制因为我们可以看到所有源代码所以我们觉得“哦我们可以查看它。如果有问题我们可以看到问题所在。”
所以我们可能不会限制我们的进程访问随机的服务器……尽管我们应该这么做。但这是一个运营问题通常这是运维部门的事可能会有点烦人……某个开发人员可能会觉得不爽因为他们想把数据发送到某个随机的分析服务而他们不想向 IT 部门提交工单来开放……你知道我们不做这些事情是有原因的……但如果你被迫为了基本的安全性这么做那么有时这确实能有所帮助。但实际上你应该默认锁定你的程序然后为正当理由提供方便的开放方式。
Johnny Boursiquot: 你不允许你的二进制文件随意向任何地方发送 HTTP 请求吗
Kris Brandow[笑] 我的意思是如果我在运行生产基础设施那当然不会允许这种情况发生。
Johnny Boursiquot[笑]
Ian Lopshire我得赶紧记些笔记可能需要检查几件事……
Johnny Boursiquot就像“为什么这个东西需要联系什么随机服务器”不过这又是一个权衡因为工程师们确实喜欢直接引入依赖……他们会说“哦我得做这件事不要挡着我我得赶紧完成。让我引入这个依赖它能干这件事。我们要用这个新服务。”然后你问“你调查过这个服务吗你确定它可靠吗”他们会回答“没有我们得赶紧完成任务把它上线。”我听过很多这样的借口。
Johnny Boursiquot你会问“你正在导入的这个包是什么它为什么用一个空标识符它到底在做什么” [笑]
Kris Brandow是的……
Ian Lopshire回到我们刚才讨论的在 Go 中如何在明面上隐藏恶意代码……我实在想不出如何在 Go 中写出一个发 POST 请求的代码而不让它看起来是在发 POST 请求。至少看起来会很可疑“你在这儿做了一些奇怪的事情。” 没有太多办法可以隐藏这种东西。
Kris Brandow嗯如果你足够聪明……
Ian Lopshire我肯定有办法但我现在想不出来。
Johnny Boursiquot我的第一步---在我的验证工作流中包括查看 pkg.go.dev 以及它的元数据如果我深入挖掘的话当我查看某些依赖项的仓库时无论是直接依赖还是间接依赖我通常会在仓库里快速搜索一下是否有 HTTP 包。如果我找到……[笑] 那么我会对这个包非常感兴趣。如果这个包只是用来比如说反转字符之类的东西……那为什么这里会有 HTTP 包你就得开始质疑了。“这个包应该只做这件事为什么它还要进行网络请求发生了什么” 这些事情应该是明显的警示提示你需要深入调查。这就是我所说的我们不可能抓住所有问题。无论我们的流程多么严格我们认为自己已经跳过了很多环节以避免漏洞但安全始终是一个减轻风险和设置防护措施的游戏它不是你可以百分百做到的事情。因此作为开发人员你实际上是第一道防线你应该对这些事情保持批判态度。我正在导入这个包它应该做这件事……为什么它还要做别的事
Kris Brandow 是的。不过如果我们重新从攻击的角度思考如果我要建立某种漏洞我不会用 HTTP 包。我可能会用 OS 包做一些系统调用设置一个套接字……
Ian Lopshire系统调用……[笑] 是的正如你所说的……我看到这个就会觉得“这看起来很奇怪为什么这个字符翻转工具需要进行系统调用”
Kris Brandow或者你说“哦这个字符翻转需要非常快所以我们用汇编语言写它”然后你在汇编代码中做所有系统调用的事情。你能看出区别吗你能分辨出是字符翻转还是在汇编中设置套接字吗
Ian Lopshire我觉得我能分辨出来。我真的觉得我能。
Kris Brandow也许吧也许吧。
Johnny Boursiquot你简直就是个巨人Ian。 [笑]
Ian Lopshire我觉得汇编代码的长度至少从这一点上来说应该会有明显的区别。但我是谁来下这个判断呢……
Kris Brandow嗯这取决于情况。也许你在其他地方有某个文本块它是一些混淆的代码实际上展开成更多的汇编代码来做一些事情……你可以做一些深层的嵌套真的可以尝试欺骗一些人如果你真的想这么做的话。但说实话这是一项庞大的工作与其这么麻烦你还不如直接用扳手来解决问题……还有其他方法可以利用人类的弱点。
Johnny Boursiquot没错。这些显而易见的事情……有些事情……如果某个人足够有动机你真的很难找到所有漏洞。那些简单的东西比如脚本小子script kiddies常用的东西。简易的漏洞“让我用 HTTP 包把这些数据发送到我地下室的服务器。” 这些简单的东西你至少应该能快速识别出来。
不过我相信一定有一些公司专门从事这种事情比如安全公司。他们可以扫描你的二进制文件我相信也会有一些解决方案可以引入。如果你真的想要额外的安全保障你可以请第三方来做这件事。
Kris Brandow是的因为到了一定程度你可能会发现“哦我不能直接攻击代码。哦你现在用的是 Kubernetes。也许我可以通过攻击 Kubernetes 来入侵。” 所以一旦你把一个部分防护得足够好攻击者会转向另一个部分进行入侵造成破坏。
我认为在某种程度上很多都是关于威慑像在你的系统里到处设置威慑机制让它变得越来越难攻破这样攻击者最终会去攻击其他目标因为你太难对付不值得花时间。希望我们都开始这样做最终大家都处在一个更好的位置但这并不一定会发生。你不可能一下子就修复整个行业。不过在我们进入下一个话题之前关于依赖项和漏洞的讨论还有什么最后想说的吗
Johnny Boursiquot一点点复制总比引入一点点依赖要好……[笑]
Kris Brandow对。
Ian Lopshire我只是想说Go 的安全数据平面和漏洞数据库做得非常好而且有很好的机器人可以扫描这些漏洞……所以如果你只是想迈出第一步只需把这些工具集成到你的 CI 系统里然后按照提示更新依赖项。我觉得这能起很大的作用。
Kris Brandow听起来不错。现在到了我们节目中最喜欢的小环节---不受欢迎的观点时间。
Kris Brandow好了谁有不受欢迎的观点
Johnny Boursiquot我再重复一次我之前的观点。我认为总的来说后端开发人员比前端开发人员更注重安全。原因有很多---我们刚才讨论了很多但纯粹从 npm 世界不断冒出来的漏洞数量来看……我觉得这很明显。再说一次我在这里是泛泛而谈但在我看来似乎前端开发人员更容易仅仅复制粘贴代码片段然后就假设一切都已经照顾好了。某个 CDN 上的某个库或者某个从 CDN 引入的库……当然了这是我们社区里经常做的事情。很多假设是“哦是的所有东西默认都是安全的我不需要特别关注它。” 很少听到前端开发人员对这些问题感到担忧。当然这并不是说前端社区里没有人会关心这些问题……我只是说在过去几年里无论我在哪个后端社区总有一些人会特别关注依赖项和安全性等问题。而我在前端社区里感受到的这种关注相对较少。
Kris Brandow嗯我不确定。我确实觉得后端人员……是的我觉得因为后端需要做很多安全工作要确保它的安全性而且它是一个很大的攻击目标所以我认为后端人员确实会更关注这些问题而不太会关注其他方面。相比之下前端开发人员主要关注的是让前端工作起来还要应对不同浏览器之间的差异以及这些浏览器之间发生的各种奇怪现象。
我觉得这也是控制权的问题你在后端有更多的控制权而在前端则没有。归根结底你的代码是在别人的电脑上运行的运行在某个浏览器之上……你没有办法完全控制这一堆东西而在后端你对自己的技术栈有更多的控制权也能更好地掌控发生的事情。
Ian Lopshire我确实认为后端开发人员应该更加注重安全。想想其中的风险……一个后端漏洞可能会泄露整个数据库。前端出问题可能只是影响一个用户。
Johnny Boursiquot我试图访问 JSTOR结果它把我重定向到了 casino.com或者别的什么地方。 [笑] 这也不是无关紧要的……
Ian Lopshire对这确实不是无关紧要的。而且我确实认为两者都应该关注安全问题……但如果我必须选择让一个用户受到攻击我宁愿它是单个用户而不是我的整个数据库。
Kris Brandow我觉得这也部分源于后端代码是在你的安全域内而前端代码不在所以你得把前端代码当作潜在的敌对代码来处理。所以在某些情况下这也降低了对前端安全的需求。大多数时候很多前端漏洞比如跨站脚本攻击XSS也可以通过后端来阻止或预防。不过我确实觉得前端开发人员缺乏安全意识尤其是缺乏加密技术的意识这确实在某些方面有所妨碍。我注意到浏览器中的加密 API 并不多见而实际上这可以成为一种更好的身份验证和授权方式。浏览器已经有了这些 API 好几年了你可以在浏览器中创建一个公私钥对其他脚本甚至在你的子域上都无法提取这个密钥。这可以让你以一种加密安全的方式唯一标识这个浏览器你不需要传递可以被窃取的令牌而无论如何某人都可能在你的网站上运行一些 JavaScript 代码。
是的通过跨站脚本攻击你可以做一些 API 请求但你不能窃取那个密钥并发送到服务器然后开始大量请求或者做任何那样的事情。相比之下你可以用 [无法听清 00:46:18.05] 令牌做到这一点。我觉得这种情况出现的部分原因是前端社区对这些工具和理念不太熟悉所以对这类东西的支持不多。虽然我们已经开始有了像 passkey 这样的东西但相比于我们本可以更早开始做的事情来说这确实是太晚了。
Johnny Boursiquot这可不算是不受欢迎的观点。我都不知道 passkey 是怎么工作的。我最近访问的每个网站都在提示我使用 passkey我就想“哦。” 我好像曾经读过微软的某些东西……
Kris Brandow简单来说它就是我刚才描述的。它是非对称加密。也就是公私钥对公钥注册到了服务器上当你登录时它会签署某个东西并发送到服务器。这个过程就是为了确认你确实持有这个 passkey。
当然还有很多其他事情需要处理像是共享 passkey 之类的东西来实际实现它们在不同地方之间的移动……但最简单来说它就是将公钥加密应用于认证过程。
所以是的这很像我们用 SSH 时做的事情或者很多其他东西或者 TLS。当你使用双向 TLS 时它做的也是同样的事情。所以这只是把它应用到浏览器上。Passkey 很棒我很喜欢 passkey。
Johnny Boursiquot很棒除了没人知道怎么用它。我经历过几次设置过程……但我说不清楚设置过程中发生了什么。而且当我为 Google 设置时和 Apple 的设置稍有不同微软的设置也不太一样……它们似乎有些微小的差异至少它们帮助我设置 passkey 的体验略有不同。有时用手机有时用笔记本……老实说我不知道它是如何工作的。也许几年后……
Kris Brandow我用的是 1Password。所以这些都集成在一起了。
Johnny Boursiquot我也是没错。
Kris Brandow: 所以 1Password 就像是“你可以设置一个 passkey。” 但本质上这和我们用 Yubikeys 做的事情是一样的。我认为设置 Yubikey 的流程和设置 passkey 的流程是一样的。它们实际上是一样的。但确实不同的平台上略有不同但本质上做的事情是一样的“这是一个公钥它标识了我是谁。好的太棒了。” 显然里面有很多细节和微妙之处但基本上就是这么回事。你给他们一个公钥证明你是谁然后他们稍后会要求你证明这一点。但我很高兴我们正在尝试淘汰密码这让我非常开心。不过它们---
Johnny Boursiquot: 听着密码会成为科技界的传真机。它们永远不会消失永远不会。
Kris Brandow: [笑] 是的……
Johnny Boursiquot: 某处的某个人---就像你老派的牙医诊所或者其他地方你需要发送一些保险证明等等……他们会说“你能传真给我们吗”我就像“什么你什么意思”
Kris Brandow: 就像我们能不能---
Johnny Boursiquot: “你觉得我家里还有传真机吗” [笑]
Kris Brandow: 我确实不得不给政府传真了一些东西我当时就想“传真传真……好吧……”密码永远不会完全消失但它们可以在绝大多数情况下被有效淘汰。我们已经有社交登录很长时间了。现在我们有了 passkey。而且你现在也有了密码管理器---去用一个吧。
Johnny Boursiquot: 现在普通的非技术人员才开始理解它们是什么以及为什么要使用它们。我不指望我七十多岁的母亲天佑她的灵魂知道如何使用密码管理器。你在开玩笑吗我得手把手教她多少东西啊……
基本上我必须告诉她“看每个网站都用一个随机密码。是的我知道这很痛苦但把那些密码安全地保存在手机上记在笔记本里或者别的地方……然后不要在每个地方使用相同的密码而且要非常小心。如果有人在任何时候要求你发送密码立刻给我打电话。” 这些是我为她设的安全措施因为我不能指望她使用密码管理器。这太复杂了。
Kris Brandow: 也许这是个不受欢迎的观点但我认为任何能用电脑的人都可以学会这些东西。我认为我们引入它们的时间太晚了。如果我们从 20 年前就开始推行这场 passkey 革命就像我们本可以做的那样我认为每个人都会习惯它……就像“哦你还在用密码吗这太奇怪了你应该用我们有的其他东西。” 但我们只是没有建立起相应的基础设施。
我认为推动 passkey 向前发展的东西是我们手机和电脑上的生物识别技术现在你可以真正确认坐在电脑前的人就是你认为的那个人达到一定程度的确定性。但我认为很多这类问题之所以难以理解是因为我们解释得太差而不是因为人们从根本上无法理解。我敢肯定你妈妈不记得每个人的电话号码但我打赌她已经学会如何使用手机上的通讯录应用把所有号码都放进去然后说“哦我要给这个人打电话。让我点一下通讯录里他们的名字。”
Ian Lopshire: 我不同意这一点。 [笑声]
Johnny Boursiquot: 你妈妈能记住---她能记住她遇到的每个人的电话号码吗
Ian Lopshire: 不她只是有一堆随机的号码在她的短信里像“我不知道这是谁但我跟他们聊过。” [笑声]
Johnny Boursiquot: 哦天啊……
Kris Brandow: 我的意思是总会有一些人---
Ian Lopshire: 我脑子里并不是想着我母亲但我确实有一个特定的人在想。
Kris Brandow: 总会有一些人会做一些奇怪的事情像“哦这是某人的号码但我不知道是谁的……” 但我会说绝大多数人都懂得如何使用他们手机上的通讯录……这实际上是非常相似的事情。就像“哦去你的通讯录里查一下。好的去你的密码管理器里查一下点这个点那个。” 好吧这是个跑题了。
Ian你有什么不受欢迎的观点吗
Ian Lopshire: 是的这个观点可能会非常不受欢迎……它与我们刚才讨论的内容有关。我认为你不需要更新依赖项除非你有理由这么做。
Johnny Boursiquot: 嗯是的。这是公平的观点。
Kris Brandow: 我觉得这是……字面意思是你只需要---我不知道这怎么会是不受欢迎的观点。你什么意思你认为我们会无缘无故地更新依赖项吗
Ian Lopshire: 我的意思是是的。
Johnny Boursiquot: 的确有人这么做。是的。
Ian Lopshire: 有人会这么做。有人每月都会更新所有依赖项。
Johnny Boursiquot: 是的。
Ian Lopshire: 我觉得这是浪费时间。除非有理由比如有漏洞、已知漏洞否则我不认为有必要主动更新依赖项。
Kris Brandow: 除非是 API 发生了变化或者你需要某个新功能……但如果你只是为了保持所有东西都更新而去更新……公平地说也许作为反驳我会说我更希望企业这么做而不是他们现在做的事情---从不更新任何东西然后当有漏洞时他们也不更新最后被黑客攻击。所以我宁愿他们有一个流程始终更新所有东西这样当有漏洞时他们至少知道如何更新。因为如果你不经常更新可能就会在需要更新时不知道该怎么做。
我们进行火灾演习的原因是你需要让人们知道在真正的紧急情况下该怎么做而不是在紧急情况发生时才去搞清楚。
Ian Lopshire: 我在其他语言中并不持这种观点。比如如果我在做 JavaScript 项目我会想“是的我可能应该时不时更新这些东西”因为我不知道你有没有不更新 React 五个版本然后 [无法听清 00:54:26.25] [笑声]
Kris Brandow: 还不如直接把整个项目扔掉重新开始。
Johnny Boursiquot: 是的重新开始。
Ian Lopshire: 让我具体说一下……对于 Go 项目我不认为你需要主动更新依赖项除非有已知漏洞或者你需要新功能。
Johnny Boursiquot: 是的很多这类问题取决于你所依赖的项目维护者的纪律性。我遇到过这种情况某个依赖项的安全补丁被添加到我未使用的升级版本中……这意味着如果我想要这个补丁我必须升级并获得补丁。所以如果他们没有足够的纪律性或者坦白说没有足够资源或时间为每个版本打上这个补丁---这确实是个劳动密集型的工作---那么你最好的选择可能是强制升级这可能会在你实际获得补丁之前引入一些可能破坏你项目的变更。所以你并不总是有选择的余地。你依赖你的依赖项这也是为什么我不喜欢有太多依赖项。
Ian Lopshire: 这也是因为我在我工作的项目中几乎没有什么依赖项所以我可能有点偏见。
Johnny Boursiquot: 祝贺你。 [笑] 你真是幸运。
Kris Brandow: 好的。我的不受欢迎的观点---我觉得这可能会非常不受欢迎……但我认为每个人都应该学习 C。也许不是所有东西都用 C 来编写或者用 C 写很多东西但我认为每个人都需要学习 C。我认为这是我们这个行业需要做的事情。因为我觉得人们对这些东西的理解远远不够。我认为太多语言做得太好把所有东西都隐藏起来了。
Johnny Boursiquot: 为什么是 C 呢---是为了让人们自己管理内存吗你希望他们从中学到什么
Kris Brandow: 是的我认为 C 是为数不多的基本上接触到硬件的语言之一。它几乎是最底层的。你能去的最低层是汇编语言……除非你出于某种原因想手动编写机器码。但有汇编语言然后紧接着就是 C 语言。所以你在 C 中能得到很多其他语言中的高级设施但你必须了解机器的工作原理才能写 C或者甚至学会 C。如果你想写好 C 或者其他没有这种过程式层次的语言比如那些更面向对象、抽象程度更高的语言你至少需要在某种程度上理解你的指令是如何流动的。
Johnny Boursiquot: 对我个人来说自从我开始用 Go 编程以来我不再想念面向对象编程了。有些人会说“哦Go 也是面向对象的。” 这是一个争论已久的话题……但我觉得写 Go 给我的感觉更像是在写 C而不是其他语言。所以我会说如果你从未接触过 C而你想知道这是什么感觉或者一些人仍在写 C 代码的感觉是什么样的那你应该去看看。至少写个 Hello World或者比这更复杂一点的东西来感受一下。看看自己分配内存和释放内存的感觉。你会感受到你从现代语言中获得的好处。
至于面向对象编程、多个抽象层次、抽象类型以及所有这些东西……我并不怀念这些东西……在我的 Go 程序中我最想要的抽象就是使用接口。这是我在 Go 中想要的所有面向对象或抽象的极限。
Ian Lopshire: 我本来要说我不确定是否每个人都应该学习 C但每个人都应该尝试类似 C 风格的语言比如 Go、C类似的东西。我这么说是因为---作为一个在职业生涯的头几年里写 PHP 和 JavaScript 的人我完全不知道 HTTP 请求其实就是通过字节传输的。在 JavaScript 中你有对象在 PHP 中你有这些大的关联数组我当时---我完全不了解它们是如何在彼此之间转换的。对象就是它们本来的样子我根本没有概念一切都是字节。当你没有这个核心概念时你会犯很多愚蠢的错误。所以在较低级别做一些事情确实很重要即使你只是在那些更高级、抽象程度更高的语言中工作。
Kris Brandow: 是的。我之所以特别强调 C首先C 是所有系统的通用语言。如果你想让两种语言之间进行交互最终你是通过 C 来实现的。但我也认为也许我们还有其他语言可以展示更多机器工作原理的基本知识这也会很有帮助。因为我认为 C 的一个特点就是它没有任何东西---不像在 Go 中你可以在函数前面加上 go它就会启动一个 goroutine。“太棒了并发。” 在 C 中你得弄清楚你要做的事情是如何工作的还有多线程是如何工作的……但你也需要了解缓存行是什么、我的 CPU 是如何工作的、所有这些东西是如何运作的。我认为现在有很多人不了解这些东西结果我们写出了很多糟糕的软件。
Johnny Boursiquot: 因为我们被告知我们有无限的内存、无限的磁盘空间、无限的 CPU……只要再加一个虚拟 CPU 就行了……我们被训练成这样去思考“哦是的不用担心这些问题。我们会投更多硬件进去解决。” 而在过去我们没有这样的奢侈对吧
Kris Brandow: 人们对---我们提到了内存管理但对垃圾回收也是这样。总有人说“哦我们有垃圾回收问题。” 其实你没有垃圾回收问题你有垃圾问题因为你创造了太多垃圾导致垃圾回收器跟不上。你只是制造了太多东西然后把它们丢掉了。
我觉得现在仍然有一种持续的误解认为在不需要手动管理内存的语言中你就不需要做内存管理。其实不然你仍然需要做内存管理你仍然需要思考你的内存分布方式你在做什么你有多少内存特别是在设计应用程序时。但我认为通过深入研究 C你可以学到很多东西并对更高级的语言有足够的熟悉度来更好地使用它们。
Johnny Boursiquot: 我不反对。
Kris Brandow: 好吧。今天的节目就到这里了感谢大家的收听确保你的依赖项都没问题。不要让你的代码里有任何漏洞代码拜托了。拜托了。
Johnny Boursiquot: 赶紧检查一下你所有的前端代码。如果你发现了 polyfill.io……
Ian Lopshire: 赶紧删掉赶紧清理掉。
Johnny Boursiquot: 别走跑跑去你最近的版本控制系统。 [笑]
Kris Brandow: 甚至周五也可以做。这是一个周五部署的理由。无论如何感谢你们Ian 和 Johnny今天的节目很愉快。也感谢听众朋友们。下次再见。
Johnny Boursiquot: 再见大家。
