教程:使用govulncheck发现和修复有安全问题的依赖项

本文翻译自《Tutorial: Find and fix vulnerable dependencies with govulncheck》。

Govulncheck是一个低噪音的工具,可以帮助你发现并修复Go项目中易受攻击的依赖项。它通过扫描项目的依赖项以查找已知的漏洞,并识别出对这些漏洞的任何直接或间接调用的项目代码。

在本教程中,你将学习如何使用govulcheck扫描一个简单的程序以查找漏洞,如何对漏洞进行优先级排序和评估,以便首先集中精力修复最重要的漏洞。

要了解更多关于govulcheck的信息,请参阅govulceck文档和这篇关于Go漏洞管理的博客文章。我们也很乐意听取你的反馈。

先决条件

  • 使用Go 1.18或更高版本。Govulncheck旨在与Go 1.18及以后的版本配合使用。我们建议使用最新版本的Go来遵循本教程。(有关安装Go的说明,请参阅安装Go。)
  • 一个代码编辑器。任何文本编辑都可以很好地工作。
  • 一个命令终端。Go在Linux和Mac的终端程序,以及Windows中的PowerShell或cmd上都能很好地工作。

本教程将带你完成以下步骤:

1 创建一个Go模块示例,它的某个依赖项有漏洞

2 安装并运行govulcheck

3 评估漏洞 4 升级并修复有漏洞的依赖项

创建一个Go模块示例

步骤1,首先,创建一个名为vulntutorial的新文件夹并初始化Go模块。例如,从当前目录运行以下命令:

$ mkdir vuln-tutorial
$ cd vuln-tutorial
$ go mod init vuln.tutorial

步骤2,在vuln-tutorial文件夹中创建一个名为main.go的文件,并将以下代码复制到其中:

package main

import (
        "fmt"
        "os"

        "golang.org/x/text/language"
)

func main() {
        for _, arg := range os.Args[1:] {
                tag, err := language.Parse(arg)
                if err != nil {
                        fmt.Printf("%s: error: %v\n", arg, err)
                } else if tag == language.Und {
                        fmt.Printf("%s: undefined\n", arg)
                } else {
                        fmt.Printf("%s: tag %s\n", arg, tag)
                }
        }
}

此示例程序将语言标签的一个列表作为命令行参数,并为每个标签打印一条消息,指示标签是否解析成功、是否未定义或者解析标签时是否出错。

步骤3,运行go mod tidy命令,把main.go的代码所需的所有依赖项记录到go.mod文件。在vuln-tutorial文件夹所在目录,运行以下命令:

$ go mod tidy

你应该能看到类似如下输出:

go: finding module for package golang.org/x/text/language
go: downloading golang.org/x/text v0.9.0
go: found golang.org/x/text/language in golang.org/x/text v0.9.0

第4步,打开go.mod文件,它的内容应该如下所示:

module vuln.tutorial

go 1.20

require golang.org/x/text v0.9.0

第5步,降级golang.org/x/text依赖项的版本到v0.3.5,这个版本包含一个众所周知的安全漏洞:

$ go get golang.org/x/[email protected]

你应该能看到类似如下输出:

go: downgraded golang.org/x/text v0.9.0 => v0.3.5

打开go.mod文件,它的内容应该如下所示:

module vuln.tutorial

go 1.20

require golang.org/x/text v0.3.5

接下来我们使用govulncheck来发现vuln-tutorial项目中的安全漏洞。

安装并运行govulncheck

第6步,使用go install命令安装govulncheck:

$ go install golang.org/x/vuln/cmd/govulncheck@latest

第7步,在vuln-tutorial目录里运行govulncheck来分析vuln-tutorial项目中的安全漏洞:

$ govulncheck ./...

你应该会看到如下输出:

govulncheck is an experimental tool. Share feedback at https://go.dev/s/govulncheck-feedback.

Using go1.20.3 and [email protected] with
vulnerability data from https://vuln.go.dev (last modified 2023-04-18 21:32:26 +0000 UTC).

Scanning your code and 46 packages across 1 dependent module for known vulnerabilities...
Your code is affected by 1 vulnerability from 1 module.

Vulnerability #1: GO-2021-0113
  Due to improper index calculation, an incorrectly formatted
  language tag can cause Parse to panic via an out of bounds read.
  If Parse is used to process untrusted user inputs, this may be
  used as a vector for a denial of service attack.

  More info: https://pkg.go.dev/vuln/GO-2021-0113

  Module: golang.org/x/text
    Found in: golang.org/x/[email protected]
    Fixed in: golang.org/x/[email protected]

    Call stacks in your code:
      main.go:12:29: vuln.tutorial.main calls golang.org/x/text/language.Parse

=== Informational ===

Found 1 vulnerability in packages that you import, but there are no call
stacks leading to the use of this vulnerability. You may not need to
take any action. See https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck
for details.

Vulnerability #1: GO-2022-1059
  An attacker may cause a denial of service by crafting an
  Accept-Language header which ParseAcceptLanguage will take
  significant time to parse.
  More info: https://pkg.go.dev/vuln/GO-2022-1059
  Found in: golang.org/x/[email protected]
  Fixed in: golang.org/x/[email protected]

解释一下上述输出

注意,不同Go版本,上述输出可能不同。

我们的代码受到漏洞GO-2021-0113的影响,因为它直接调用golang.org/x/text/language的Parse函数,而这个函数在v0.3.5版本存在安全漏洞。

golang.org/x/text模块v0.3.5中存在另一个漏洞GO-2022-1059。然而,它被报告为“Informational”,因为我们的代码没有(直接或间接)调用这个安全漏洞相关的函数。

现在,让我们评估vuln-tutorial项目中的漏洞并确定要采取的行动。

评估漏洞

a.评估漏洞

首先,阅读漏洞的描述信息,并确定它是否真的适用于你的代码和用例。如果你需要更多信息,请访问“More info”链接。

根据描述,漏洞GO-2021-0113在使用Parse函数处理不受信任的用户输入时可能会引发panic。假设我们打算让我们的程序承受不受信任的输入,那么该漏洞可能就会被利用。

漏洞GO-2022-1059不会影响我们的代码,因为我们的代码没有从该依赖项中调用任何有安全漏洞的函数。

b.决定采取什么行动

为了解决GO-2021-0113漏洞问题,我们有以下几个选择:

选项1:升级到修复后的版本。如果有可用的修复,我们可以通过升级到该模块的修复版本来删除安全漏洞。

选项2:停止使用有安全漏洞的标识符。我们可以删除代码中对有安全漏洞的函数的所有调用。但我们需要找到一个替代方案,或者自己实现相关函数。

在本例情况下,我们可以使用修复后的版本,Parse函数是我们程序不可或缺的一部分。让我们将依赖项升级到“fixed in”版本v0.3.7。

漏洞GO-2022-1059与漏洞GO-2021-0113在同一模块中,而且它的修复版本是v0.3.8,所以我们可以通过升级到v0.3.8轻松地同时删除这两个漏洞。

升级并修复有安全漏洞的依赖项

幸运的是,升级并修复有安全漏洞的依赖项非常简单。

第8步,升级golang.org/x/text至v0.3.8版本:

$ go get golang.org/x/[email protected]

你应该能看到如下输出:

go: upgraded golang.org/x/text v0.3.5 => v0.3.8

请注意,我们也可以选择升级到最新版本,或v0.3.8之后的任何其他版本。

第9步,现在再次运行govulcheck:

$ govulncheck ./...

你现在会看到如下输出:

govulncheck is an experimental tool. Share feedback at https://go.dev/s/govulncheck-feedback.

Using go1.20.3 and [email protected] with
vulnerability data from https://vuln.go.dev (last modified 2023-04-06 19:19:26 +0000 UTC).

Scanning your code and 46 packages across 1 dependent module for known vulnerabilities...
No vulnerabilities found.

govuncheck确认没有发现漏洞。

使用命令govulcheck定期扫描依赖项,你可以识别、排序和解决安全漏洞来保护你的项目代码。

Go安全政策

本文翻译自《Go Security Policy》。

概述

本文档介绍Go Security团队处理报告的问题的流程以及预期的回复。

报告一个安全漏洞

Go发行版中的所有安全漏洞都应通过电子邮件报告给[email protected]。此邮件会发送给Go Security团队。

为了确保你的报告不被标记为垃圾邮件,请在电子邮件中的任何位置包含“vulnerability”一词。请在电子邮件中使用一行描述主题。

你的电子邮件将在7天内得到确认,在解决问题之前,你将了解最新进展。你的问题将在90天内解决或公开。

如果你在7天内没有收到电子邮件回复,请再次与Go安全团队联系,地址为[email protected]。请确保你的电子邮件中包含“vulnerability”一词。

如果再过3天,你仍未收到对报告的确认,则你的电子邮件可能已被标记为垃圾邮件。在这种情况下,请在此处提交问题。选择“我想报告谷歌产品(SQLi、XSS等)中的技术安全或滥用风险相关的错误”,并选中“Go”为受影响的产品。

跟踪问题

根据问题的性质,Go安全团队会将其归类为PUBLIC、PRIVATE或URGENT问题。所有安全问题都将被分配一个CVE编号。

PUBLIC

PUBLIC的问题影响非常有限,或者已经广为人知。

PUBLIC的问题被标记为“Proposal-Security”,通过公开的Go提案审查过程进行讨论,并返回到下一个计划的次要发布(minor releases)(每月发布一次)。发布公告包括这些问题的详细信息,但不会预先发布。

以下是过去发布的PUBLIC的问题的例子:

  • #44916:archive/zip:调用Reader.Open时可能会引发panic
  • #44913:encoding/xml:把自定义TokenReader传给xml.NewTokenDecoder时会引发无限循环
  • #40928: net/http/cgi,net/http/fcgi:但没有指定Content-Type时存在Cross-Site Scripting (XSS)攻击风险
  • #40618: encoding/binary: ReadUvarint和ReadVarint可以从非法输入中读取无限个字节
  • #36834: crypto/x509:Windows 10可以绕过证书验证

PRIVATE

PRIVATE中的问题违反了已提交的安全属性。

PRIVATE问题在下一个计划发布的次要版本中得到修复,并在此之前保持私有状态。

发布前三到七天,将发布预公告,宣布即将发布的版本中存在一个或多个安全修复程序,以及这些问题是否会影响标准库或(和)工具链,以及每个修复程序的CVE ID号码。

以下是过去发布的RIVATE的问题的例子:

  • #53416: path/filepath: Glob包会导致栈空间耗尽
  • #53616: go/parser:所有Parse*函数都存在栈空间耗尽的问题
  • #54658: net/http:GOAWAY发送GOAWAY给服务器后引发错误
  • #56284: syscall, os/exec:在环境变量中没有清除NUL

URGENT

URGENT问题对Go的生态系统的完整性构成威胁,或者正在被黑客积极利用,导致严重破坏。虽然最近没有这方面的例子,但它们可能包括net/http中的远程代码执行,或crypto/tls中的密钥恢复等。

URGENT问题是私下解决的,并会立即进行安全版本的发布,可能不会有预公告。

发送安全相关问题

如果你认为现有的某个问题与安全相关,我们请求你发送电子邮件至[email protected]。电子邮件应包括问题ID和为什么应根据此安全策略进行处理的简短描述。

披露和处理一个安全漏洞的流程

Go使用以下流程来披露和处理一个安全漏洞的流程:

  • 一旦收到一个安全报告,就会为其分配一个主处理流程。有个人负责协调整个修复和发布过程。
  • 问题已得到确认,并确定了受影响软件的列表。
  • 对代码进行审计,以发现任何潜在的类似问题。
  • 如果在与提交者协商后确定需要CVE编号,则主处理流程将获得一个。
  • 为最近的两个主版本号和head/master分支准备好修复程序。修复程序是为最近的两个主版本号准备的,并合并到head/master分支中。
  • 在应用修复程序的当天,会有公告发送到golang-announcement、golang-dev和golang-nuts。

这个过程可能需要一些时间,尤其是当需要与其他项目的维护人员进行协调时。我们将尽一切努力及时处理漏洞,但重要的是,我们要遵循上述流程,确保披露的漏洞得到一致的处理过程。

对于包括分配CVE号码在内的安全问题,该问题会在CVE详细信息网站国家漏洞披露网站的“Golang”产品下公开列出。

接收安全更新

接收安全公告的最佳方式是订阅golang-announce邮件列表。任何与安全问题有关的消息都将以[security]作为前缀。

对此政策的评论

如果你对改进此Go安全政策有任何建议,请提交一个问题进行讨论。

NPM今天应该做些什么才能阻止未来可能还会发生的类似于colors包故意破坏式更新这样的攻击

本文翻译自《What NPM Should Do Today To Stop A New Colors Attack Tomorrow》。

2022/01/10

周末,一位名叫Marak Squires的开发者故意破坏了他流行的NPM包colors和不太流行的包faker。在我写这篇文章的时候,NPM声称有18971个包直接依赖colors和2751个包直接依赖faker。据Open Source Insights统计,间接依赖colors的包至少有42000个。许多流行的NPM包都依赖于这些包。

NPM设计中的一个错误之处意味着,一旦最新版本的colors发布,新安装的基于colors的命令行工具就会立即开始使用它,而没有测试它是否与每个工具兼容。(剧透提醒:事实并非如此!)

具体的错误之处在于,当你使用NPM安装软件包(包括命令行工具)时,NPM会根据package.json文件中列出的需求以及当时的世界状态来选择依赖项版本,并且优先安装每个依赖项的最新版本。这意味着,从Marak更新colors包的那一刻起,aws-cdk和其他工具的安装就被中断,错误报告开始滚滚而来,就像下面这个那样

相关错误也出现在apostrophecdk8scompodocforeversdhexohighchartsjestnetlifyoclif等包里。

今天,NPM用户可能会对Marak感到沮丧,但Marak搞的破坏只是在终端上输出一些垃圾信息。情况其实可以更糟。即使忽略了这种故意破坏,非故意的错误也总是发生。从本质上讲,每一个开源软件许可证都指出,代码是在没有任何保证的情况下提供的。现代软件包管理器的设计需要预见并减轻这种风险。

任何运行现代生产系统的人都知道测试,然后是逐步或分阶段的部署,即在很长一段时间内逐步部署对运行中的系统的更改,以减少意外地同时删除所有内容的可能性。例如,上次我需要更改谷歌的核心DNS区域文件时,对该更改进行了多次回归测试,然后在24小时内一次一个地部署到谷歌的四个名称服务器中的每一个。回归测试检查了不该出现的意外情况,然后给了自动化系统和可靠性工程师足够的时间来逐步部署。

NPM的设计选择恰恰相反。最新版本的colors在所有人有机会测试它之前就被推广到了所有依赖它的包中,而且没有任何逐步升级的方法。用户现在可以通过固定其所有依赖项的确切版本来禁用这种行为。例如,这里是对aws-cdk的修复。这不是一个好答案,但至少这是能用的。

对于NPM和类似的包管理器来说,正确的前进道路是在安装新包时不要再优先安装所有依赖项的最新版本。相反,它们应该优先安装实际测试过的依赖项,或者尽可能接近这些版本的版本。我称之为高保真构建。相比之下,在周末安装aws-cdk和其他包的人得到了低保真度的构建:NPM插入了开发者从未测试过的新版本的colors包。用户在周末测试自己的项目时,测试失败了。

高保真度构建解决了测试问题和如何逐步升级问题。在aws-cdk作者有机会测试并在新版本的aws-cdk中引入之前,新版本的colors不会被aws-cdk包所接受。在那之后,所有新的aws-cdk包都会引入新的colors包,但所有其他包仍然不会受到影响,直到它们也测试并正式引入了新版本的colors包。

有许多方法可以生成高保真度构建。在Go中,一个包声明每个依赖项所需的最低版本,这就是构建项目时所使用的依赖项的版本,除非同一个项目里有某个依赖项依赖其中某个依赖项的更新的版本。然后,它只使用这个特定的更新版本,而不是刚刚在周末发布的、完全未经任何人测试的版本。有关这种方法的更多信息,请参阅“Go中的版本控制原则”。

NPM还有一个npm shrinkwrap命令和一个npm ci命令,这两个命令似乎都可以在某些有限的情况下解决这个问题。大多数受colors包影响的命令的作者和用户今天应该仔细研究这些命令。感谢NPM提供了这些命令,但他们不应该总是依赖这些命令。下一步应该是NPM安排这种保护默认发生。然后,当为依赖项安装新的包时,需要同样的保护,而不仅仅是在安装命令时。所有这些都需要更多的工作。

其他语言的包管理者也应该注意到这个问题。大多数包管理者在没有任何类型的测试的情况下自动采用新依赖项,也没有提供逐步升级软件包的方法,Marak的行为强调了这个问题,这给我们所有人带来了巨大的帮助。早就该解决这些问题了,否则下一次只会更糟。

Go开发人员应该知道的Go项目安全最佳实践

本文翻译自《Security Best Practices for Go Developers》。

点此回到《Go安全》。

此页面为Go开发人员提供了优先考虑项目安全的最佳实践。从使用自动化的模糊测试到轻松检查竞态条件(race condition),这些技巧可以帮助你的代码库更加安全可靠。

扫描源代码和二进制文件中的漏洞

定期扫描代码和二进制文件中的漏洞有助于及早发现潜在的安全风险。你可以使用由Go漏洞数据库支持的govulcheck来扫描代码中的漏洞,并分析哪些漏洞会真正影响到你。开始学习govuncheck教程

Govulncheck也可以集成到CI/CD工作流中。Go团队在GitHub Marketplace上为Govulcheck提供了一个GitHub动作( GitHub Action)。Govulncheck还支持-json标志,以帮助开发人员将漏洞扫描功能与其他CI/CD系统集成。

你还可以使用VS Code的Go扩展直接在编辑器中扫描漏洞。见本教程

使你的Go版本和依赖项保持最新

让你的Go版本保持最新,你就可以使用最新的语言功能、性能改进和已知安全漏洞的修补程序。更新的Go版本还确保了与新版本的依赖项的兼容性,有助于避免潜在的集成问题。查看Go版本的历史发布记录,查看在不同版本之间对Go进行了哪些更改。Go团队在整个发布周期中按照安全问题的议点发布,以解决安全漏洞。请确保更新到最新的Go的小版本号,以确保你拥有最新的安全修复程序。

维护最新的第三方依赖项对于Go生态系统中的软件的安全性、性能和遵守最新标准都至关重要。然而,在没有彻底审查的情况下更新到最新版本也可能存在风险,可能会引入新的Bug、不兼容的更改,甚至恶意代码。因此,虽然更新到最新的安全补丁和改进的依赖项至关重要,但每次更新都应该仔细审查和测试。

使用模糊测试来发现代码的边界漏洞

模糊测试是一种自动测试,它使用覆盖率导向(coverage guidance)来操纵随机输入并遍历代码,以发现和报告潜在的漏洞,例如SQL注入、缓冲区溢出、拒绝服务以及跨站点脚本攻击。模糊测试经常会触及程序员错过的边界测试用例,或者认为不太可能出错的边界测试用例。见本教程

使用Go的竞态检测器检查竞态情况

当两个或多个goroutine同时访问同一资源,并且其中至少有一个访问是写操作时,就会出现竞态情况。这可能会导致软件中出现不可预测、难以诊断的问题。使用内置的竞态检测器在Go代码中识别潜在的竞态情况,这可以帮助你确保并发程序的安全性和可靠性。不过,竞态检测器只会查找运行时发生的争用,没法在未执行的代码中查找。

要使用内置的竞态检测器,请在运行测试或构建应用程序时添加-race标志,例如go test -race。这将在启用竞态检测器的情况下编译代码,并报告它在运行时检测到的任何竞态情况。当竞态检测器在程序中发现数据冲突时,它将打印一份报告,其中包含冲突访问的堆栈跟踪,以及创建相关goroutine的堆栈。

使用Vet检查可疑的代码结构

Go的vet命令旨在分析源代码,并标记不一定是语法错误,但可能在运行时导致问题的潜在代码,例如无法访问到的代码、未使用的变量以及goroutine中常见的错误。在开发过程的早期发现这些问题,有助于保持代码质量,减少调试时间,并提高软件的整体可靠性。要为指定项目运行go vet,请运行:

go vet ./...

译者注:Goland这种IDE已经集成并会自动使用vet命令了。

订阅golang公告以获取安全相关发布的通知

包含安全修复程序的Go版本已预先发布到[email protected]邮件列表中。如果你想知道Go本身的安全修复何时开始,请订阅。

Go CNA政策

本文翻译自《Go CNA Policy》。

点此回到《Go安全》。

概述

Go CNA是一个CVE编号机构,负责发布CVE ID并发布Go生态系统中公开漏洞的CVE记录。它是Google CNA的子CNA。

范围

Go CNA涵盖Go项目(Go标准库子存储库)中的漏洞,以及其他CNA尚未涵盖的可导入的Go模块中的公开漏洞。

此范围旨在明确排除Go中编写的应用程序或不可导入的包中的漏洞(例如main中的任何包)。更多信息,请参阅go.dev/security/vuln/database#excluded-reports。

要报告Go项目中潜在的新漏洞,请参阅Go.dev/security/policy。

为一个公开漏洞请求一个CVE ID

重要提示:下面链接的表单在议题跟踪器上创建了一个公开议题,因此不得用于报告Go中未公开的漏洞(有关报告未公开问题的说明,请参阅我们的安全政策)。

要为Go生态系统中现有PUBLIC漏洞请求一个CVE ID,请通过此表单提交请求

如果漏洞已经公开披露,或者存在于你维护的包中,并且你准备公开披露,则该漏洞被视为公开漏洞。

Go漏洞管理

本文翻译自《Go Vulnerability Management》。

点此回到《Go安全》

概述

Go可以帮助开发人员检测、评估和解决有可能被攻击者利用的代码Bug或弱点。在幕后,Go团队运行一个管道来策划有关漏洞的报告,这些报告存储在Go漏洞数据库中。可以阅读和分析各种库和工具的这些报告,以了解特定用户项目可能受到的影响。此功能已集成到Go软件包发现站点和新的CLI工具govulcheck中。

该项目正在推进中,正在积极开发中。我们欢迎你的反馈,帮助我们改进!

注意:要报告Go项目中的漏洞,请参阅Go安全策略

架构

Go中的漏洞管理由以下高级部分组成:

资源

Go漏洞数据库

Go漏洞数据库包含来自许多现有来源的信息,此外还有Go包的维护人员直接向Go安全团队的报告。数据库中的每个条目都会被审查,以确保漏洞的描述、包和符号的信息以及版本的详细信息是准确的。

有关go漏洞数据库的更多信息,请参阅go.dev/security/vuln/database,在浏览器中查看数据库中的漏洞信息,请参阅pkg.go.dev/vuln

我们鼓励包的维护人员在自己的项目中提供有关漏洞的信息,并向我们发送如何减少该漏洞造成的影响的建议

Go漏洞检测

Go的漏洞检测旨在为Go用户提供一种低噪声、可靠的方式来了解可能影响其项目的已知漏洞。漏洞检测集成到Go的工具和服务中,包括一个新的命令行工具govulcheckGo包发现网站主流的编辑器,例如带有Go扩展的VS Code。

要开始使用govulcheck,请在项目中运行以下命令语句:

$ go install golang.org/x/vuln/cmd/govulncheck@latest
$ govulncheck ./...

要在编辑器中启用漏洞检测,请参阅编辑器集成漏洞检测插件页面中的说明。

Go CNA

Go安全团队是一个CVE编号机构(CVE Numbering Authority)。有关更多信息,请参阅go.dev/security/vuln/cna

反馈

我们希望你在以下方面做出贡献并帮助我们改进:

FAQ

如何报告Go项目中的漏洞?

通过电子邮件向[email protected]报告Go项目中的所有安全漏洞。有关我们流程的更多信息,请阅读Go的安全政策

如何将公共漏洞添加到Go漏洞数据库?

要将公共漏洞添加到Go漏洞数据库,请填写此表单

如果漏洞已经公开披露,或者存在于你维护的包中(并且你已准备好披露),则该漏洞被视为公开漏洞。该表单仅适用于不由Go团队维护的可导入的Go包中的公共漏洞(Go标准库、Go工具链和golang.org模块之外的任何包)。

该表单也可用于申请新的CVE ID。点击此处了解更多关于Go CVE编号机构的信息。

如何提议对漏洞进行编辑?

提议编辑Go漏洞数据库中的现有报告,请填写此处的表单

我如何报告问题或提供有关govulcheck的反馈?

Go问题跟踪器上提交你的问题或反馈。

我在另一个数据库中发现了此漏洞,为什么它不在Go漏洞数据库中?

由于各种原因,报告可能会被排除在Go漏洞数据库之外,包括相关漏洞不存在于Go包中,存在于可安装命令而非可导入包中,或者该漏洞被数据库中已存在的另一个漏洞所包含。你可以在此处了解更多关于Go Security团队排除报告的原因。如果你认为某个报告被错误地排除在vuln.gov之外,请告诉我们

为什么Go漏洞数据库不使用严重级别标签?

大多数漏洞报告格式使用严重性标签,如“LOW”、“MEDIUM”和“CRITICAL”,以指示不同漏洞造成的影响程度,并帮助开发人员确定安全问题的优先处理级别。然而,由于几个原因,Go避免使用此类标签。

漏洞的影响很少是普遍的,这意味着严重性指标往往具有欺骗性。例如,如果解析器用于解析用户提供的输入,并且可以被DoS攻击利用,那么解析器中的漏洞可能是一个严重的问题,但如果解析器只是用于分析本地配置文件,即使将严重性称为“低”也可能言过其实。

严重程度也必然是主观的。即使对于CVE程序也是如此,该程序假定了一个公式来分解漏洞的相关方面,如攻击向量、复杂性和可利用性。然而,所有这些都需要主观评价。

我们认为,对漏洞的良好描述比严重性指标更有用。一个好的描述可以分解什么是问题,如何触发问题,以及用户在确定对自己软件的影响时应该考虑什么。

如果你想与我们分享你对此主题的想法,请随时提交一个议题

使用IDE扫描Go依赖项的漏洞

本文翻译自《Vulnerability Scanning in IDE》。

点此回到《Go安全》

Go语言服务器集成的编辑器,例如装有Go扩展的VS Code,可以检测依赖项中的漏洞。

检测依赖关系中的漏洞有两种模式。两者都由Go漏洞数据库支持,并相互补充。

  • 基于导入的分析:在这种模式下,编辑器通过扫描工作区中导入的一组包来报告漏洞,并在go.mod文件中显示诊断结果。这很快,但如果你的代码导入了有漏洞的包,但并没有实际调用具有该漏洞的函数,则可能会误报。此模式可以通过“vulncheck”: “Imports”设置启用。
  • Govulncheck分析:这是基于gopls中嵌入的govulnchick命令行工具。这提供了一种低噪声、可靠的方法来确认代码是否真的调用了易受攻击的函数。由于此分析的计算成本可能很高,因此必须与基于导入的分析中的诊断报告相关的“Run govuncheck to verify”代码操作或使用go.mod文件上的“codelens.Run_govulcheck”代码操作手动触发。

切换Vulncheck (vulncheck.mp4)

这些功能在gopls v0.11.0或更新版本中可用。请在https://go.dev/s/vsc-vulncheck-feedback上分享你的反馈。

编辑器相关指导

VS Code

Go扩展提供了与gopls的集成。需要以下设置才能启用漏洞扫描功能:

"go.diagnostic.vulncheck": "Imports", // 默认启用基于导入的Govulncheck分析
"gopls": {
  "ui.codelenses": {
    "run_govulncheck": true  // 在go.mod文件里,鼠标移到依赖项上时显示"Run govulncheck"菜单选项
  }
}

Go Toggle Vulcheck”命令可用于打开和关闭当前工作空间的基于导入的分析。

Vim/NeoVim

使用coc.nvim插件时,以下设置将启用基于导入的分析。

{
    "codeLens.enable": true,
    "languageserver": {
        "go": {
            "command": "gopls",
            ...
            "initializationOptions": {
                "vulncheck": "Imports",
            }
        }
    }
}

注意事项和警告

  • 该扩展不扫描私有包,也不发送任何有关私有模块的信息。所有分析都是通过从Go漏洞数据库中提取已知有漏洞风险的模块的列表,然后在本地计算交集来完成的。
  • 基于导入的分析使用工作区(workspace)模块中的包列表,如果使用了go.work文件或replace/exclude指令,则该列表可能与你在go.mod文件中看到的不同。
  • 在修改代码或更新Go漏洞数据库后,govulcheck分析结果可能会变得过时。要手动使分析结果失效,请使用go.mod文件顶部显示的“Reset go.mod diagnostics”选项。否则,结果将在一小时后自动失效。
  • 这些功能目前不会报告标准库或工具链中的漏洞。我们仍在调查用户体验,了解在哪里显示这些发现比较合适,以及如何帮助用户处理这些问题。

_seq_no和_primary_term这两个字段在Elasticsearch里的作用是什么?

它们用来实现基于乐观锁的版本控制。

Elasticsearch跟踪上次操作的序列号(sequence number)和主项(primary term),以更改它存储的每个文档。通过GET API响应信息中的_seq_no和_primary_term字段返回序列号和主项。

_primary_term

在故障转移期间,每当不同的分片成为主分片时,primary term的值就会增加。这有助于解决重新联机的旧的主分片上发生的更改,与新的主分片上发生的更改的冲突问题,一般新的主分片会获胜。

这里我们要先理解Elasticsearch的高性能和高可用机制:一个索引的数据可以存储到多个分片上,以均衡负载,提升读写性能;而每个分片(主分片)又可以有多个副本(副分片),在主分片脱机后Elasticsearch可以快速把其中一个副分片推举为新的主分片,保障Elasticsearch集群的高可用性。

副分片的primary term只是主分片更改次数的计数器。

这些primary term是递增的,并且在主分片升级时会发生变化。它们作为集群状态的一部分被持久化,因此代表了集群所在的主分片的一种“版本号”或“年代(generation)”。

为了确保文档的旧版本不会覆盖新版本,对文档执行的每个操作都由对应更改的主分片分配一个序列号。

假设你的索引由5个主分片组成(在Elasticsearch 7之前是默认的)。索引(新增文档)和更新的请求是针对主分片执行的。如果你有多个主分片,Elasticsearch能够将传入请求(例如,巨大的批量插入文档的请求)并行化/分发到多个分片,以提高性能。

因此,_primary_term字段提供了关于执行或协调更改主分片(本例中为#1、#2、#3、#4或#5)的信息。

_seq_no

序列号在Elasticsearch 6.0.0中引入。

一旦我们对primary term进行了保护,我们就添加了一个简单的计数器,并开始向每个操作发出该计数器的序列号。因此,这些序列号使我们能够理解发生在主分片上的对索引的操作。

_version字段存储了一个序列号,用于统计文档更新的次数。_seq_no字段也是一个序列号,用于统计索引上发生的操作次数。因此,如果你创建第二个文档,你将看到该文档的_seq_no和第一个文档的_seq_no有所不同。

实例

创建多个文档:

POST test/_doc/_bulk
{"index": {}}
{"test": 1}
{"index": {}}
{"test": 2}
{"index": {}}
{"test": 3}

返回响应信息:

{
  "took" : 166,
  "errors" : false,
  "items" : [
    {
      "index" : {
        "_index" : "test",
        "_type" : "_doc",
        "_id" : "d2zbSW4BJvP7VWZfYMwQ",
        "_version" : 1,
        "result" : "created",
        "_shards" : {
          "total" : 2,
          "successful" : 1,
          "failed" : 0
        },
        "_seq_no" : 0,
        "_primary_term" : 1,
        "status" : 201
      }
    },
    {
      "index" : {
        "_index" : "test",
        "_type" : "_doc",
        "_id" : "eGzbSW4BJvP7VWZfYMwQ",
        "_version" : 1,
        "result" : "created",
        "_shards" : {
          "total" : 2,
          "successful" : 1,
          "failed" : 0
        },
        "_seq_no" : 1,
        "_primary_term" : 1,
        "status" : 201
      }
    },
    {
      "index" : {
        "_index" : "test",
        "_type" : "_doc",
        "_id" : "eWzbSW4BJvP7VWZfYMwQ",
        "_version" : 1,
        "result" : "created",
        "_shards" : {
          "total" : 2,
          "successful" : 1,
          "failed" : 0
        },
        "_seq_no" : 2,
        "_primary_term" : 1,
        "status" : 201
      }
    }
  ]
}

正如你所看到的:

  • 对于所有文档,版本号_version为1;
  • 对于文档1,_seq_no为0(第一次索引操作);
  • 对于文档2,_seq_no为1(第二次索引操作);
  • 对于文档3,_seq_no为2(第三次索引操作)。

教程:使用VS Code Go插件查找和修复可能有安全风险的依赖项

本文翻译自《Tutorial: Find and fix vulnerable dependencies with VS Code Go》。

点此回到《Go安全》

目录

先决条件

如何使用VS Code Go扫描漏洞

其他资源

你可以使用Visual Studio Code编辑器的Go插件直接在编辑器中扫描代码中的漏洞。

注意:有关以下图像中包含的漏洞修复相关的教程,请参阅govulcheck教程

先决条件

  • Go 1.18或更高版本。Govulncheck旨在与Go 1.18及以后的版本配合使用。有关安装说明,请参阅安装Go。我们建议你使用最新版本的Go来学习本教程。
  • VS Code编辑器,更新到最新版本。请在此处下载。你也可以使用Vim(有关详细信息,请参阅此处),但本教程的重点是VS Code Go插件。
  • VS Code Go插件,可以在这里下载。
  • VS Code编辑器特定设置更改。你需要根据这些规范修改VS Code的设置,然后才能复制下文的代码示例,运行后得到相应的结果。

如何使用VS Code Go扫描漏洞

第一步,运行“Go: Toggle Vulncheck”

Toggle Vulcheck命令显示在你的模块中列出的所有依赖项的漏洞分析。要使用此命令,请打开IDE中的命令面板(在Linux/Windows上的快捷键为Ctrl+Shift+P,在Mac OS上的快捷键为Cmd+Shift+P),然后运行“Go:Thoggle Vulcheck”。在Go.mod文件中,你将看到代码中可能会被直接和间接攻击的依赖项的诊断。

注意:要在自己的编辑器上重现本教程,请将下面的代码复制到main.go文件中。

// 这个程序从命令行获取一个或多个“语言标签(language tag)”参数,然后解析它们
package main

import (
  "fmt"
  "os"

  "golang.org/x/text/language"
)

func main() {
  for _, arg := range os.Args[1:] {
    tag, err := language.Parse(arg)
    if err != nil {
      fmt.Printf("%s: error: %v\n", arg, err)
    } else if tag == language.Und {
      fmt.Printf("%s: undefined\n", arg)
    } else {
      fmt.Printf("%s: tag %s\n", arg, tag)
    }
  }
}

然后,确保程序的go.mod文件的内容如下所示:

module module1

go 1.18

require golang.org/x/text v0.3.5

运行go mod tidy命令以确保你的go.sum文件已更新。

第二步,运行govulcheck。

使用代码操作(code action)运行govulcheck可以让你专注于代码中实际调用的依赖项。VS Code中的代码操作由灯泡图标标记;将鼠标悬停在相关依赖项上以查看有关该漏洞的信息,然后选择“快速修复(Quick Fix)”以显示选项菜单。再选择“运行govulcheck进行验证(run govulncheck to verify)”。这将在你的终端中返回相关的govulceck输出。

第三步,将鼠标悬停在go.mod文件中列出的依赖项上。

将鼠标悬停在go.mod文件中的依赖项上,也可以找到关于此依赖项的govulcheck输出。为了快速查看依赖项相关信息,这种方式甚至比使用代码操作更高效。

第四步,把你的依赖项升级到修复后的版本。

代码操作还可以用于快速升级到修复漏洞后的依赖项的版本。通过在代码操作的下拉菜单中选择“升级”选项来完成此操作。

其他资源

  • 有关IDE中漏洞扫描的详细信息,请参阅此页。特别是“注意和警告”小节讨论了漏洞扫描可能比上例中更复杂的特殊情况。
  • Go漏洞数据库包含来自许多现有源代码的信息,此外还有Go包维护人员向Go安全团队的直接报告。
  • 请参阅Go漏洞管理页面,该页面提供了Go用于检测、报告和管理漏洞的体系结构的高级视图。

字符集,编码、显码和存码,ANSI,GB2312,GBK,Unicode,UTF-8名词解释

ANSI是美国国家标准协会,系统预设的标准文字储存格式。

简体中文编码GB2312,实际上它是ANSI的一个代码页936

一种代码页就是一种字符集。

例如代码页936(Codepage 936)是Microsoft的简体中文字符集标准,是东亚语文的四种双字节字符集(DBCS)之一。其最初版本和GB 2312一模一样,但在Windows 95时扩展成GBK。现时中国大陆强制要求所有软件皆要支持GB 18030(Microsoft称之为代码页54936)。

根据微软资料,GBK(汉字内码扩展规范)是对GB2312-80的扩展,也就是CP936字码表(Code Page 936)的扩展(之前CP936和GB 2312-80一模一样),最早实现于Windows 95简体中文版。虽然GBK收录GB 13000.1-93的全部字符,但GBK也是一种编码方式并向下兼容GB2312;而GB 13000.1-93等同于Unicode 1.1是一种字符集,它的几种编码方式如UTF8、UTF16LE等,与GBK完全不兼容。

UTF-8是一种通用的字符集编码格式,这是为传输而设计的编码,2进制,以8位为一个单元对Unicode进行编码。

在UTF-8里,英文字符的编码仍然跟ASCII编码一样,因此原先的函数库可以继续使用。而中文的编码范围在0080-07FF之间,因此是2个字节表示(但这两个字节和GB编码的两个字节是不同的),用专门的Unicode处理程序可以对UTF-8编码进行处理。”

GBK、GB2312是ANSI字符集的扩展字符集,UTF-8是Unicode字符集的一种编码方案,在编码层面,它们对ASCII字符的编码是一样的,但是对中文字符的编码就不一样了、不兼容了!

Unicode狭义来说只是一个字符集,而UTF-8是其一种编码规则(编码方式),Unicode有多种编码方式,还有ucs-2(utf-16)等。

字符集在计算机系统里的实现技术,分为存码技术和显码技术,编码规则属于存码技术,字体属于显码技术。一个字符可以有多种编码方式,例如GBK、UTF-8等,编码方式告诉计算机如何用二进制编码(此处“编码”是动词)和存储一个字符;一个字符也可以有多种显示方式,例如使用不同的字体,将在屏幕上显示不同的字形。一种字体就是一种显码。

参考

https://blog.csdn.net/l1028386804/article/details/46583279

https://zh.wikipedia.org/wiki/%E4%BB%A3%E7%A2%BC%E9%A0%81936

https://zh.wikipedia.org/wiki/%E6%B1%89%E5%AD%97%E5%86%85%E7%A0%81%E6%89%A9%E5%B1%95%E8%A7%84%E8%8C%83