有邪恶的球体吗？

Question

我读过有关 Evil RegExp 的信息，并且在处理有关 RegExp 的用户输入时通常会确保基本的安全级别到位。

我不确定这个问题是否也存在于 Glob 中。我想这将归结为 Glob'ing' 的各个实现，在我的特定实例中，我使用 https://github.com/gobwas/glob/

对于如何测试此问题以及可能如何缓解此问题的任何建议，我将不胜感激。

Answer 1

"evil regex" 我假设你的意思是一个成为灾难性回溯受害者的正则表达式。

根据您的描述，您似乎正在使用 glob 库来避免这些 "evil regexes"。 Globs 本质上是正则表达式的弱化版本。

您在这里遗漏的事实是正则表达式不一定是邪恶的。这可以在没有外部库的普通 Go 中证明。

尝试运行这个 Go 程序：

package main

import (
    "fmt"; "regexp"
)

func main() {
    reg := regexp.MustCompile(`^([^z]*?,){11}P`)

    txt := `1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18zP`

    fmt.Println(reg.ReplaceAllString(txt, ""))
}

您可能想知道为什么这段代码不测量执行所花费的时间。因为不需要（也因为我不太懂Go）

正则表达式几乎适用于所有正则表达式风格。您可以尝试运行 Java、Perl 或其他类似风格（我喜欢在 https://regex101.com/#pcre 上使用 PCRE），但结果将是两件事：

超时
你受够了它需要多长时间并停止程序

是的，这种组合会导致大多数正则表达式出现灾难性的回溯。但是不去。为什么？

Go 的正则表达式根本不使用回溯，所以这甚至是不可能的。根据this site:

In Go, we find an optimized regular expression engine. This runs in linear time, making complex patterns faster. It is located in the regexp package.

详细了解回溯和非回溯引擎之间的差异 here。

考虑到 glob 库（根据 GitHub link）似乎比 Go 的正则表达式更快，性能应该不是问题。

有邪恶的球体吗？

Are there evil globs?

regex

security

glob

go